It’s a term that you can’t seem to get away from in product development since Frank Robinson introduced the methodology in 2001, and then Eric Ries popularised its meaning in 2009 as part of his larger thinking around Lean Startups.

Everyone seems to love the idea of an MVP - a Minimum Viable Product - but in practice it’s often used to describe something that’s not really minimal, and sometimes not all that viable.

Maximum focus on the minimum

Over the years as MVP became more widely known, and the term resonates with teams outside of Product Development, the core meaning behind it has become a little diluted. It might be misunderstood as simply the smallest piece of functionality that can be delivered. Sometimes it might be seen as the ability to cut corners to deliver something.

MVP often has too much stress placed on the minimum part, skipping over the also important viable piece of the entire strategy. Make something that is so minimum it lacks the quality of an actual product, and you’ll likely miss out on (accurately) assessing whether customers will use, enjoy using, and value the end product.

The point of an MVP is to understand your users’ interests, and prove the business viability, and do it in such a way that it uses the minimum amount of resources to achieve that insight. It’s the smallest version of a product you can use to start the process of learning from customers. It allows you to start that learning process without a huge amount of time and effort.

An MVP is a product delivered with the most essential features, attempting to satisfy the needs of your smallest audience or user subset.

It doesn’t work without iteration

While an MVP starts at a point of having just enough features to satisfy early users, test your assumptions and receive user feedback, you’re not done yet. Like all iterative-based development, multiple versions of an MVP can and should be tested.

You build upon your foundations - that’s why it’s important the MVP is functional and focuses on being usable. It should be essentially market ready. Your goal from the first version and through each iteration is to gain an understanding about the interests and experiences of your users, without bloating your MVP with features you think would be really great.

With each iteration, you observe the feedback. Interrogate the value it brings your users, and your business. Did you add value, or stifle it? Identify assumptions you want to test in the next version, and how you’re going to prove you can continue to bring value to its users.

Then build the next version. Observe. Learn. Repeat.

You might fail

An MVP is ultimately a strategy to learn quickly, and “fail fast” if necessary. You’ll hear this almost counterintuitive term a lot in product development. It isn’t that we want to fail, but a recognition that failure can happen.

The problem is, we don’t know if or when we’re going to fail. Can we entirely avoid failure? No, but we can certainly reduce the risk of failure, and we can mitigate the damage caused by it.

That’s what makes MVPs, and other validated learning approaches, a process in which we are learning fast while controlling the effort and resources we put behind them. We are de-risking as we go.

So what happens if you do fail? If we find that our assumptions were incorrect, or we aren’t creating value for users or our business, we can down tools and walk away without having lost too much. Or, we can take the learnings and apply them elsewhere. We can even pivot our approach based on the feedback we uncovered from users that we wouldn’t have uncovered otherwise. Failure can be an opportunity.

It’s not the only strategy out there

Like all strategies or frameworks, you can (and should) adapt it to what works for you, so long as you don’t lose sight of the core objective of the strategy. In fact, many have already tried the Minimum Viable Product approach and posited their own approaches.

• Written by the wonderful Meg Kurdziolek, the Minimum Viable Experiment (MVE) suggests that, rather than putting any focus on building a “thing”, you test the central premise of your business idea without building a damn thing.
• Jason Cohen passionately argues that “MVPs are too M and almost never V. Customers see that, and hate it.” and instead suggests the Simple, Lovable, Complete (SLC) approach
• Keeping on the love theme, Laurence McCahill talks about the Minimum Lovable Product (MLP), a focus on building something that your earliest adopters will actually enjoy using

These approaches share one thing in common: focus on building something viable for your target audience and your business.

While I don’t think MVP necessarily discards a focus on user experience, I do think the modern interpretation of it often forgets that a good, likeable, usable product is all a part of viability too.

So give MVP, MVE, SLC or MLP a go. Worst case scenario, you’ll learn something you didn’t know before.

MVPs at Potato

We’re a lean digital product studio. MVPs are a critical part of the Agile product development process. We use Agile sprints to create and iterate on MVPs, allowing us to gather and incorporate user feedback to improve those products in an efficient and cost effective way.

We take a validated learning approach - a process of interactive and continuous definition, creating, testing and feedback. Working in this way, we are able to constantly assess the position of your products in the market whilst staying perfectly aligned with your customer needs.

If you’re interested in hearing more about our approach to MVP, contact us via our website.