How to define Minimum Viable Products (MVP)
Why MVP (minimum viable product) can be confusing
MVP is one of the terms that seems to generate a lot of traction during an Agile transformation. It seems people are happy about trying to do ‘just enough’ to accomplish a goal. But, for companies with a fixed mindset the term can get quickly abused. For those companies, the focus is typically on delivering ‘what was promised’ rather than building up a deeper understanding of how to compete.
In these environments, MVPs can often be used to justify a reduction (and maybe even lack) in scope. They’re normally just about setting a language of minimalism so ’The Business’ get something they’re desperately looking for, and ‘IT’ have some modicum of scope control. With a single definition of an MVP things become too fixed. The result is that the customer is reduced to being an after-thought with the focus on delivering what is ‘agreed’ upfront rather than what is truly required.
To add to the confusion, over the years there have been many different definitions of Minimum Functional/Viable/Marketable/Acceptable features/products/releases. The thing that seems to be agreeable is to do the minimum. The problem, however, is that that there are no real policies set inside companies to define how MVPs might be used to greater effect in a framework that helps manage and govern risk.
To truly work out what the minimum thing required is, we need to go on a journey of discovery and learning.
MVPs are about learning
The definition of an MVP should really always be related to an outcome – “This MVP is designed to achieve x”. There is no singular definition of an MVP. For instance, we might create an MVP to see if our product solves a specific issue for a specific customer. Or, we might create the smallest possible product to launch a global phenomenon. These two things are completely different and require very different strategies to achieve the goal – and probably a different management and governance approach.
What we do know is that there are some common things that organizations are trying to achieve, so we can put some structure around the language of learning and discovery.
Phases of an agile project – DABL
The UK Government’s Digital Services Team (GDS) wrote an excellent framework for how Government Services should be designed and built – you can see it here. This framework was specifically designed for UK government services and creating solutions for citizens that were based on learning the users real needs and deploying solutions that better served users.
A similar framework works equally well in a Product Management or Change Management environment. We can look at it alongside Steve Blank’s Customer Discovery approach to product and business development which is ultimately about finding Product/Market fit and building a scalable business model.
This model is designed to discover, validate and create new customers, and then lead you into Company Building once you’re sure you have Product Market fit.
The goal of the framework is to develop understanding and learn by designing increments that help answer specific questions.
Discovery
Discovery is all about developing an understanding of your customer and the tools, products and services they use today to achieve their goals. If you believe you have something that better solves their problem you need to do a couple of things:
- Frame a problem statement that you’re solving for, and get clarity as to whether this is a valuable problem to solve
- Describe options on how you might solve the problem
- Explore the market for what exists today to achieve the goal – figure out what your competitors are doing already.
- See step 1. Framing a really good problem statement is the most critical item before moving on.
You might need to build something here in order to help frame the problem well. Whatever you do, don’t build too much. Keep things very light, very quick and only build things that will help develop a shared understanding between you and potential customers about the problem-space.
Alpha
Alpha is all about designing something that achieves Problem-Solution Fit. So you have a well-defined problem statement. And some ideas on how to solve it. You understand what others do in the market. You suspect that there is value in working on a solution and there is a market of people who will spend some money. As you build your solution (or solutions because it’s okay to build many prototypes in parallel or serially) you need to keep focused on answering some key questions:
- Do you believe your potential solution actually solves the problem you’ve defined (and your customer has described as valuable)?
- Do you have any customer validation – have any customers told you that your proposed solution helps them solve the problem they have?
- Are your users to-date prepared to pay for your solution? At this stage, do you think it might become a viable business?
- Is your solution different to your competitors? Is it clear to others that it’s differentiated?
- And before moving on, does it really solve the problem? It really does need to before you spend money on acquiring customers and users.
Beta
At this stage, you have validated your solution with real customers. They should have been people who really represent the personas you’re looking to serve. You know your idea works – at least for a small population. But, is it easy to market, find and acquire customers and serve a more diverse group. Beta is all about finding Product-Market Fit. The questions that are helpful for you to build solutions to at this stage are:
- Does your solution scale to meet the needs of the many? How might you solve the problem in a way that is economically viable?
- How do you position and market your viable Value Proposition?
- What channels might be best for acquiring and serving your target market?
- How do you create the best experience (from a sales and delivery perspective)?
- What other features might be needed to have people evangelise about your product?
- What’s the right mix of acquisition, referral and retention investment?
- How do I best structure teams and operations to serve a launch?
- What are my key indicators of growth? How might I know if the product isn’t doing as well as I want? Or, how do I know there is something new that competes with my Value Proposition?
Live
Great! So you’ve created a number of Minimum Viable Products. You’ve learned lots. You’ve probably iterated your way through Discovery, Alpha and Beta, and you’re ready to make your product a global phenomenon (or whatever your aim is). You are now looking for the Viable Business Model coming to life. At this stage, it’s about continuous improvement of everything you do. New features, improved delivery models, increased customer base. It’s about more of the same – but continuously improved.
Retire
Now, hopefully during Beta and Live you’ve figured out the key metrics to help you work out if you’re being disrupted by something else in the market place. These should include some leading indicators that aren’t just about revenue and profit. Hopefully, they will give you signals that the product is still performing or needs attention. Some of your competition will be able to be dealt with by continuous improvement – that is probable if you really did have Product/Market Fit. But sometimes a new thing comes along to knock you off your perch. At the point you now need to consider retiring and starting the process again. It’s back to Discovery to re-serve your customers and users, and on to Retire for the solution that you so lovingly grew.
Framing good MVPs
So, to cap this off it’s worth saying a couple of other things. You can (and maybe certainly should and will) have many iterations of MVPs in each stage of the learning process. The important thing is to learn, get answers to your questions and figure out when best to move to the next level of scale. At any point you can ask the question whether you should persevere with your idea, pivot to something completely new or scrap the whole idea. Typically, if the problem statement was well framed at the beginning there will be value to go after regardless of how well solutions work, but it’s not always the case.
Be vary wary of jumping straight to a later stage without answering earlier questions. Always aim to build evidence and get validation. And, be mindful not to skip to the default answer of ‘only a product with every feature will be needed for our MVP so we can scale to our Enterprises need’. It’s probably the biggest mistake using MVPs in large companies.
Remember an MVP is a vehicle for learning. It’s part of a process of discovery and a way for you to develop deeper insights into the problem you’re solving for. It helps you build the most desirable, viable and feasible product possible. Think about it in terms of ways to frame a goal that is a subset of the biggest goal. Even when you’re in a large enterprise, there are always ways to break things down to build, learn and test.
Additional Insights
The art of feedback
Process mining for customer journey mapping
The importance of owning your transformation
