If your company develops products then you face the challenge of making sure you build something your customers want and at the same time minimizing the risks if you get it wrong.
There’s a temptation to pack in as much as you can so you spread your bets and appeal to as many customers as possible. However, from the world of lean start-ups, the Minimum Viable Product (MVP) strategy recommends the exact opposite!
This approach addresses two issues. With new products or markets, customers often don’t know what they want until they get it in their hands. And the only true way to know if customers value something is if they part with their hard-earned cash.
If the market is uncertain it makes sense to build the bare minimum that customers will buy. The less you build the faster you can launch. The sooner you can win customers, generate revenue and learn from the market. And, if you fail you waste less time and money.
Once you have feedback from real paying customers it’s much easier to justify the next version. Each release builds quickly on the last, letting you test out new elements in the proposition.
MVP is most closely associated with companies using Agile but can work in companies using Waterfall or a hybrid of the two.
The issues it addresses really matter to most business so why isn’t everyone doing it?
Well, using a Minimum Viable Product (MVP) release strategy relies on assumptions that are challenging for many businesses. These are that:
It’s easy for customers to buy and use our MVP. Some products can be bought cheaply, accessed through a browser and delivered through the cloud – there’s low impact on the customer. But if a customer has to pay a high price or if they need to adapt their technology or processes the purchasing decision becomes more complex and slow creating a barrier to uptake.
It’s quick and cheap to release. Internet start-ups might be forgiven for delivering buggy-software that doesn’t work reliably. But, many of us have a demanding customer base or a hard-won reputation to protect. We need to validate the quality of any release and so have a costly and time-consuming release process of testing, trials, internal training and documentation.
We can quickly deliver the next version to address any shortcomings. Small businesses can make rapid decisions to iterate their products and quickly fix any problems. For bigger companies, internal processes and inertia can mean it takes months (or years) to get funding and build the next version
These are significant challenges and it means that any product release has to deliver enough value to customers and enough money to us to justify the expense and hassle.
Many of us work in fast-moving markets and it would be great to deliver faster and more often. If we’re not already doing it, Agile development is one route to achieve this. But that’s not enough. We also need to work on reducing the impact on customers of taking-on our products. And we need to make our release process as lightweight as possible while still protecting our reputation.
Whilst there are challenges, the MVP approach is a good idea for most companies.
Will it work for you?
Andrew Dickenson
Director, Product Focus
Join the conversation - 1 reply
I wholly agree with this blog post, although it raises a question that i have faced in past product development scenarios – “Why do we not discuss the MVS (minimum viable customer segment) as much as the MVP?”
As highlighted by the article, the MVP raises a number of tensions for larger organisations that are not working from a blank sheet of paper. I wonder whether the introduction of a complementary MVS strategy could mitigate some of those:
– Introducing customer segmentation allows a company to branch its product strategy and perhaps choose a lower penetrated segment or audience type with a less complex buying decision.
– Introducing an MVS means an even greater focus on product feature/s that are important to a specific audience. I also think that quicker release and iterative development cycles should not necessarily mean lower quality thresholds and the feature set should be one that can be comfortably delivered to agreed/existing levels of quality.
– A MVS strategy can also facilitate the testing and eventual rollout plan to other customer segments (or a no go decision for that matter). Assuming positive feedback/uptake, the business case to roll this out across other customer segments and to build out features should be an easier sell internally vs. the prospect of having to add more features to a MVP that has not been able to win over audiences.