Last week I participated in a panel to chat about product management (at General Assembly in Seattle). It was fun, and also a learning experience for me.
One question stuck out
“How do you define an MVP?”
A very good question that generates lengthy discussions in engineering teams, between PMs and with management.
My first experience with an MVP
When I first was defining my first MVP, our organization was transitioning to agile from a long period of waterfall development process. We used to do plan for milestones of products such that we built pieces of the product at every milestone, and those pieces would converge over a longer time, at around release time, to make the product and then shipped to the customer. It was okay to have partially done features at the end of milestones. Accepted wisdom was that we must have the product ready with full features when we show it to customers first time. There was no time for learning from failures or experimentation.
Our agile transformation coaches suggested us to think for short term, plan cycles with Minimum Viable Products (MVPs). An MVP defined as the minimum product (or business value) that we’d ship to the customer to get feedback. In a very very very short time frame of roughly 3 months.
Obviously it was hard to think about shipping a minimal product, and ask for feedback:
“We need to have X, Y and Z features to ship!”
“We definitely cannot do without that feature, we need to have it in, done!”
As a result we spent almost a quarter to define an MVP…
Let’s change the definition
What if MVP is not “a product” but “an experiment” that involves willing participants to test assumptions of the larger picture (i.e. strategy or a product feature). It does not have to be fully finished or perfect looking. All it has to do is to deliver the question in your mind of what the product might do, and get feedback and answers.
Simple. It’s not about the feature set of the product, it’s about the value delivered to and feedback you’re seeking from willing participants. Part of your customers would definitely be willing to see what’s next and they would be ready to help you out and take the risk of using something new and unfinished.
Assumptions and risk areas will also help define your MVP. For example, pick an area that you’re not sure about and focus your MVP on it to identify gaps or future steps that will require more attention, or explore initial assumptions.
With this approach while you’re moving the needle forward and validating next steps of your larger strategy and product, you would not be losing precious engineering time and create throw-away code. This will increase the speed of learning while shipping and improving quality.
To sum up…
Start your MVP with a question of what you would like to learn from it when it ships to customers. What you want to measure, and how you’ll measure it. Who your customers are, and whether they would be willing to participate in early testing and giving feedback. Deliver value to your customers while seeking feedback and while charting the path to the final product.
At the end of that learning, you might keep the MVP or do course corrections, and repeat the process. MVP is not a one shot finished product. It’s an iterative process which helps you learn and move the needle forward constantly. This keeps the product close and related to the customers. Failures will return as learnings and course corrections that will make your product better too.