Since its original definition in the Lean Startup book, the Minimum Viable Product (MVP) has been placed at the beginning of the build-measure-learn feedback loop and has often been seen as the very first release in a ‘lean’ product development approach. This has led to misunderstandings of the Lean Startup methodology itself and has left a gap between Discovery and MVP, with companies spending up to six months before getting any real user feedback.
Here I want to suggest a way to close the gap with Discovery by adding the concept of ‘early testable products’ as a number of earlier releases, before reaching the MVP.
Background: what is an MVP?
Last week, I was discussing a blog post with a former colleague. It’s a relatively older post from Henrik Kniberg, whose most important and immediately appealing image was the central point of our debate. You can see the image here at the top of this post.
This image summarises most simply and immediately the core idea behind creating an MVP. The concept is straightforward: provide value to your users and stakeholders from the very first iteration of your product.
But despite the agreement on the general idea, I soon discovered that my friend and I had a different definition of what MVP is. The disagreement is around a fundamental question: if we are building a car, is the skateboard in the image the MVP?
By definition, an MVP is the simplest core feature set of your product that allows it to be deployed. However, in practice, the shared understanding is that it represents the earliest version delivering real value to its users and that your company is willing to release.
So, to bring a little clarity, let’s investigate the steps to deliver a successful MVP.
Start with a Comprehensive Product Discovery
Without entering into the discussion of how to execute Product Discovery, this is the stage where you first start testing and validate your main assumptions. Researching your user is probably the central element of this phase. Here is where you must combine ‘quantitative’ with ‘qualitative’, ‘attitudinal’ with ‘behavioural’ research to find the truth.
Back to the original definition and what my colleague also believes: MVP is the ‘minimum’ you can build to test your core assumption that people want your product and are willing to pay for it. I don’t mind the definition, but the typical example brought forward by this concept is a landing page, video or email campaign, showing some elements of the product idea and testing users’ engagement.
To me, this is not the MVP but rather a prototype or a clever strategy to test some of the product assumptions. And as such, it still belongs to Discovery.
I would also argue that this strict definition raises criticism from both product managers and executives, fearful that going public too early would disappoint their potential customers. I’m not going too deep into this debate. I can see some valid and some not so valid objections, but mostly I see that this definition detracts people from understanding and practising the core concepts behind MVP.
The Next Step is to Plan for Your MVP
Following on from the Discovery, it’s time to decide what needs to be included in your minimum viable product and which features can be left for a later release.
There are many Feature Prioritisation frameworks available. Each will help in drafting your roadmap. Choose the one that fits your company environment and context.
The most popular are:
- The Kano Model;
- Value vs. Effort;
- Story mapping.
Here is a comprehensive list of most frameworks for prioritisation. Any one of these frameworks will help you create a static view of the current situation based on your existing knowledge of your users, research and assumptions.
The agile methodology has taught us that software and product development are dynamic. Each hypothesis needs to be continuously validated, tested and re-evaluated based on new learnings. In Eisenhower’s words: “Plans are worthless, but planning is everything.” The planning process demands the thorough exploration of options and contingencies. The knowledge gained during this probing is crucial to learn and discover where to go and how to get there. Importantly, we need to review and adjust the plan based on what we learn along the way.
Closing the Gap
From my experience, I expect most MVPs to take around four to six months of development. Anything longer than that, I would reconsider your MVP definition or its planning. And six months is a long time before you can test with real customers.
How do you fill the time gap between Discovery and MVP?
Referencing the image above, I always recommend building the skateboard in your product: start building something you can test early, then iterate. Henrik Kniberg calls this an ‘early testable product’. And as you can guess, there might be more than one early testable product before you complete your MVP.
Therefore, design your roadmap to building value at every step of your development. You don’t need to go public with your first product iteration; still, every product has opportunities to find early users. Even with a single user, you can still gain meaningful insights.
Consider the different steps in your product roadmap, engage with early users that are willing to use ‘the skateboard’ in your product, create private alpha and beta versions, and connect with a larger audience at every opportunity. By doing so, you will shift the focus from the product to the customer, and I believe you will build a fail-proof MVP (or you will fail earlier and move on).
Follow one of the Agile principles: Do; Learn; Adjust and Repeat. I always stress the importance of the ‘Repeat’ paradigm that we often forget and how we, as product managers, need to iterate continuously and often on every previous assumption.
In using this approach, we have always been able to collect precious feedback from our alpha or beta users before reaching the MVP release. At times, it simply gives us the inputs for improving on a functionality (either the logic or the design). Other times we discover, for example, that a specific feature we have deemed essential is not so important after all and not required for the MVP release.
Consider also testing beyond the functionalities you have just built. Any iteration can give you the chance to engage more directly with your potential users and to test (or re-test) fundamental hypotheses on your product.
Is this ‘continuous discovery’? The continuous discovery process goes beyond the feedback from the product, and it’s aimed at discovering new opportunities beyond the current product proposition. But this approach will support and can be one element in continuous discovery.
Takeaway
It doesn’t matter if the goal is to develop an MVP or redesign your product user interface: don’t wait until you go public. Consider building early testable versions and get continuous user feedback as soon as possible.
Closing the gap brings early insight, innovation and, most importantly, leads to developing a product with the optimum opportunity to succeed.