Top 5 MVP Tips to Avoid a Product Wreck

For too many product managers pressures and influencers wreck the the MVP, by turning it into the first release of a new product or update which is "minimal" enough to keep all stakeholders happy. This puts leadership under a powerful delusion of confidence about the product. The spell is lifted after months of delay, huge overspend, unhappy customers and peer pressure. The outcome is normally a car crash!

The common mistake is forgetting the goal of MVP, which is to learn if the assumptions you have about the users needs are real or fiction. Here are 5 tips to help achieve learnings and position the MVP appropriately. 

1. MVP is an experiment

Following an iterative experimental process can validate your assumption to inform the direction of the product. Organisations that embrace the value of MPV have high paced iteration structures and new MVPs / experiments released every week. These companies have highly motivated teams that improve their customers lives every week.

2. Use data to get close to the user

Measure everything. The more instrumentation of the users behaviour the better. Don't be tempted to use all this data to build massive reports, this is just causes 'analysis paralysis'. When you are looking at your success KPIs for a specific MVP (experiment) ask big questions like "Why is conversion not bigger", drill down using the data to answer questions like "why do users drop off at that stage of funnel?", then dig into it with even more focused questions. Good data will answer the focused questions such as "what acquisition source did customers who drop off come from?". These insights will validate your assumptions, give you more understanding and inspire better simple solutions. 

3. Understand the problem

Many companies have a culture that drives product development based on KPIs that deemed to low or by market sector that is felt under exploited. Knowing there may be an opportunity is the easy part, the hard part is to understand the problem so you can solve it better than anyone else. Too frequently the solution is designed before the problem is defined, there are many assumptions implied about the problem. Take time to understand the assumptions, document them, then design MPVs (experiments) to test the key assumptions. Every MVP (experiment) should give you more learning and understanding of the problem.

4. Be careful what you delegate

Each MVP will collect data which can provide insights and learnings. But for who? Insights are based on perception so invest the time to share the process of data analysis with your triad of functions i.e. commercial, design / content and technical. Discussions following MVP will derive shared learning, better insights and collaborative innovation. 

5. Minimal can be manual

The goal of MVP (experiment) is to validate your assumptions which may not need a lot or any code being written. Many assumptions can bet tested with manual effort. In the book 'Lean Start Up', Eric Ries describes 'concierge MPV' and 'Wizard of Oz MVP' both involve people manually making process work instead of code. These MVP styles have some benefits, leadership cannot confuse it with 'version one', people being in the centre of the process normally discovers more insights and they are typically fast to put in place.  

MVP is a tool to take your product management from lucky wins to repeatable success.