MVP, MLP, MMP, MSP, the plethora of catchy three letter abbreviations that promise to deliver a fool proof product strategy, leave us with nothing more than an unfulfilled promise.
I don’t think there’s anything inherently wrong with the MVP (Minimum Viable Product), just as there is nothing wrong with its predecessor the PDCA cycle (Plan Do Check Act) that was built on the basis of the scientific method. So what went wrong?
We’ve forgotten that the scientific method includes multiple loops, it’s usually visualized as a flow chart with inner loops. We’re looking for the shortcut answer. A three or four step process that guarantees success. So we’re often disillusioned when we try one of these MXPs. We spend our time clarifying what we mean by Viable, Lovable, Marketable, Saleable, and forget that our intent was to learn and adapt. In the process we get stuck in semantics and output.
So here’s a reminder to focus on learning and adapting. The next time you’re planning your product strategy ask yourself these questions about the items or features in your roadmap:
- Why do we want to implement this?
- Does it solve a user problem?
- Does it solve a user problem the user might not even know about?
- Is it a good way for us to verify that we can build the solution?
- What is the best way to learn from what we’re implementing?
- How will we evaluate the results?
The answers to these questions help you rephrase your roadmap as a set of desired outcomes with hypotheses for how to achieve the outcomes, and agreed upon ways to measure success.
What if this is something we need to do, and we’re really not testing an unknown hypothesis?
Don’t make things harder than they should be. If this is routine work, then treat it as such – create delivery timeboxes and get to work. Labeling this work as an MXP gives people the idea that you’re planning on cutting corners and probably won’t ever properly finish the work!
What if the MXP gives us results that show we should stop here or try a different approach?
If you’re at the end of the line, clean up the work you’ve done so far. Remove the MXP feature, and start working on a new hypothesis and new prototype implementation.
What if the MXP results are enough, they’ve met the outcomes we were hoping for?
Clean up your implementation and ensure that it is production quality. You don’t want to have tech debt piling up because you’re leveraging learning and adapting, that’s just going to slow you down in the future. Make sure to close out the experiment by properly implementing it, and keep tracking the outcomes you were interested in over time.
What if the MXP results are heading in the right path, but we’re not quite there yet?
Formulate new hypotheses or refine existing ones and keep working. Once you’ve found the path that leads you to the outcomes that you’re trying to achieve, stop and make sure to take the time to properly implement the feature. If you get stuck evaluate if you should stop this experiment. Focus on learning as fast as possible during the MXP cycle, while minimizing the risk of mistakes to the level that is right for your product.