How do you determine your Minimum Viable Product (MVP)?

I was recently involved with a product where the project team was responsible for delivering the 1st Minimum Viable Product (MVP). Product Plan defines a MVP as a product with enough features to attract early-adopters and validate an idea early in the product development cycle. It should also help the development team to gather additional feedback for future improvement.

Eric Ries states the importance of making sure your MVP aligns with your team’s or your company’s strategic goals. Your MVP should focus on building a product that delivers real value to users.

In our case it seemed like the 1st MVP was the smallest or most basic functionality they could deliver in time. Little attention was given to what the user needed to achieve and the value they required from the new system.

What could we have done differently?

1.   Even though we had several design workshops and documented the complete to-be journeys, functionality was delivered, rather than journeys. This resulted in “working functionality” but not necessarily being able to execute the entire value chain journey. If we took the time to map the entire service blueprint at the beginning, we would have been able to see and track the MVP impact on all stakeholders throughout the journey while at the same timekeeping our eye on the user’s goals or jobs to be done.

2.   We knew that we had very little time to implement a fully functional & tested MVP. Functional testing and user acceptance testing (UAT) was kept to a bare minimum to ensure we make the necessary timelines. This resulted in us going live with a faulty MVP causing users to be negative and bad mouthing the new system. It is most important that you allow sufficient time for functional and UAT testing to ensure users adopt the system and want to be part of the change.

This article was first posted on September 4th, 2019 on linkedin.com