The use of the phrase ‘Minimum Viable Product’ has spread well beyond the start-up community, since it was popularised in Eric Ries’s ‘The Lean Start-up’. However, that doesn’t mean it’s always accepted – there are supporters and critics in companies large and small.
What’s going on with MVP?
From our discussions with hundreds of people on our courses and in our product management reviews we know people have widely different views on what it means.
Proponents of MVP value the intent behind the approach – which is to deliver product as quickly as possible to customers, so you get genuine feedback from them on what they value (as shown by the fact that they use it and maybe they’ll pay you for it) and they get a useful product as quickly as possible.
And we agree, that’s a great intent so why do some people hate the idea of MVP and others love it?
What’s an MVP in your market?
One common issue is that most people focus on the minimum part of the term and neglect the viable part. But aside from this, there are other challenges.
A key challenge on which we’ll focus is that what is considered quick (minimum), valuable and useful (viable) in one market is considered risky, valueless and underwhelming in another. This confusion causes uncertainty over whether companies should aim to deliver MVPs and if they do, how fast can they really get at delivery.
To explain further, let’s contrast two different businesses.
One is a new SaaS business delivering an application that allows consumers to manage personal action lists and reminders. The other is a mature business with a Financial Management application that is normally deployed ‘behind the firewall’ (i.e. on customer premise infrastructure) who are moving to a cloud-based SaaS product.
The consumer SaaS business wants to focus its efforts on rapidly delivering their view of what their minimal application should offer to be valuable to their customers. They deliver it, market it, get feedback and iterate the product through incremental developments. They deliver a product that is pretty reliable. Sure, its functionality is limited but what it does is useful for their customers. The app isn’t critical for their customers so problems with it won’t be too painful for their newly found customers.
The mature business delivering the Financial Management application want to get faster at the delivery of valuable stuff to their customers as well. However, their customers use the product to manage their company finances, to bill their customers and to pay suppliers. Its operation is critical to its operation. Because it’s so important to the operation of their business the customers taking this product have extensive training for their staff. Also, despite demanding a high-quality product that works first time they’re risk-averse and have in the past run extensive tests on every new release to minimize risk to their organization. The supplier has a reputation to protect with these customers so they also value delivery of a high-quality, high-value product.
What kind of release works for you?
What works for these different companies in these different markets is different. This diagram will help think through what’s ‘viable’ for you and for your customers. We ‘ve kept it simple and it highlights just 4 characteristics of your situation:
- the level of product quality needed,
- your release process,
- the customers’ product acceptance process and
- your development approach.
Against each of these, you’ll see a couple of short descriptions of the situation.
If the descriptions on the left-hand side align with your situation then a lightweight MVP will probably work for you. If the descriptions on the right-hand side resonate more for you then a heavyweight MVP is a more realistic thing to aim for.
What we mean by lightweight MVP is that releases can be frequent e.g. every few days or weeks and you can be successful by adding very small incremental functionality.
What we mean by heavyweight MVP is that you’re whilst you’re still getting to market as quickly as possible it may be many months between releases.
Of course, you may disagree that the term Heavyweight MVP is a Minimum Viable Product at all! It’s not aligned with Eric Ries’ vision for quick, incremental releases. But, in some markets what is minimum and viable for you and your customers does require considerable product investment.
If you’re on the left-hand side of the table, then it’s likely your products are going into markets at relatively low cost and that they’re low risk for the customer. For example, one of my (somewhat bizarre) bookmarked sites is ‘Ian’s shoelace site’ that provides guidance on the best knots for different types of shoelaces. The site has limited functionality, is updated frequently and if it breaks the consequences aren’t a big problem.
If you’re lining up on the right-hand side, then it’s likely that failure would be more impactful on you or your customer. This would be the case with products such as those handling people’s money, safety or security. Many of our customers are pharmaceutical companies, banks and Telco’s – if they make mistakes with people’s money, the direct costs and reputational damage would be unacceptable. Typically, customers using these products are more risk-averse.
Is it OK to have a slow release cadence for some products?
Regardless of what MVP currently means for you and your customers, the pressure is on to deliver more value more quickly and that pressure is only set to intensify.
It’s a bit like a quote from Jeff Bezos, the head of Amazon, which I’ve paraphrased as saying “I don’t know what products customers are going to want in 10 years. What I do know is that they’ll want more selection, want it cheaper and want it faster”.
Whilst we (and probably you) don’t have the resources of an Amazon, you need to acknowledge the truth that improving your speed of delivery and your speed of learning from the market are going to be increasingly important and maybe a key differentiator in the future.
Some of the attributes in the table can be changed by internal investment in systems, tools or processes or by working with customers to shift their position.
Insight from the market and working in partnership with your customer is key – they and you need to be on the same journey. This means prototyping to validate functionality. But it’s more than that, it also means talking to them about how it gets delivered and working with them, so you have a delivery model that works for you and for them.
You need to be thinking now about the tools, processes, and approaches that will move you to the left and be working with your customers to keep them engaged on that journey!
Are you facing this challenge and if so, what are you doing about it?
Join the conversation - 3 replies
Good article.
The problem with the term “MVP” is that in some companies and cultures it becomes an excuse for “what’s the worst customer experience that we think we can get away with” – because we want to succeed without risk or spend or because we need to tick some internal milestone tickbox for senior management.
In reality, all product launches are minimum viable products. No one invests in features they deem unnecessary. It just depends on how you decide what is necessary and how you define “minimum viable”. The real question is what exactly you are expecting from your launch and what you are hoping to achieve. Some people will define “minimum viable” as “some core functionality and it doesn’t break/crash”, some others would argue that positive NPS is key and that you shouldn’t launch a product that you consider incapable of gaining at least some momentum, some may be reaching for the stars and hoping to launch on Day 1 the Swiss Army Knife of products.
It is the job of the (good) Product Manager to get the balance right on each occasion.
Important topic these days.
Has anybody tried MVP approach for projects with the aim to refresh the existing legacy product?
How to make legacy product customers accept MVP approach to replacement product which by definition is less functional than the legacy one?
Digital vs physical product is also a big (and maybe even the biggest) factor in making an MVP a realistic endeavor or not. Unfortunately it’s hardly ever mentioned (as is the case in this article as well).
The rise of “lean” and “agile” happened with the boom of SAAS (or frankly, anything-as-a-service) during the past two decades and good old physical product development got buried in a deluge of online content and books on how to develop digital products. To make things worse, the information in these books, nor their titles never even made the distinction between digital and physical, and new development approaches who were quite particularly suited to digital only, got prophesied as a general tactic for designing “products” in general.
Many developers of physical products drank the cool-aid as well, trying to keep up with best practices, and ran into deep trouble, as much of what they learned just wasn’t applicable to their own work. No wonder many of them came to roll their eyes when the concept of the MVP and many of the development concepts emerging from Silicon Valley were mentioned.