It’s not your fault your minimum viable product sucks. Not entirely, anyway.
The pressure on software product managers seems to grow more intense every year to deliver something—anything—to the market as quickly as possible. After that, the thinking goes, your early adopters will let you know how to improve it.
Nor does this pressure come only from internal sources like impatient executives or jittery investors, although you probably feel it there as well. But with lower barriers to entry into the software game, the falling prices of development tools, and the widespread availability of coding talent, the market itself is putting ever more pressure on you to deliver, ASAP.
In practice, this often means scaling your product’s strategic vision down to the bare essentials, developing the scaled-down version as quickly as you can—and ultimately pushing out a minimum viable product.
How Agile Can Worsen the Minimum Viable Product Pitfalls
As if you weren’t already facing enough pressure from within your organization and from those right-on-your-heels competitors, the idea of pushing out stripped-down products as soon as they are “minimally viable” also has the support of today’s most popular software development methodology, agile.
The agile philosophy tells product teams to strip functionality from a product’s early development in favor of being able to release the product sooner.
The plan, according to agile, should be to build a product with the minimum functionality required for early users, release that product as soon as possible, gather feedback from users, iterate based on that feedback, and continually repeat this process to improve the product.
This can be a smart strategy. But for it to work, you must have an accurate and complete understanding of what constitutes a minimum viable product, or MVP.
What Should Your Minimum Viable Product Include?
If you misinterpret the MVP’s true meaning, you risk introducing users to a product that is just short (and sometimes way short) of their expectations. Worse, if you underwhelm or disappoint this early group of users, in many cases they won’t give your product another chance.
Often the misinterpretation comes down to neglecting to include one key ingredient that belongs in every version of your product—even your MVP. We’ll discuss the key ingredient below.
First, let’s define the term. According to Wikipedia, a minimum viable product is “a product with just enough features to satisfy early customers, and to provide feedback for future development.”
The way this often plays itself out is that the product team reviews the major epics and features on the product roadmap. If the team had originally prioritized seven epics as constituting a strategically cohesive and viable product, the product manager identifies, say, three of these epics to pursue her minimum viable product.
But by simply selecting a portion of the functionality on the roadmap to include in what it calls its minimum viable product, this team risks going to market with a product that isn’t truly an MVP at all.
Here are the two fundamental requirements an MVP must meet:
1. The MVP needs to fully address a need or solve a problem for the user.
Even when you are stripping down your product’s planned development to MVP levels, you still need to keep in mind the total user experience, and you need to make sure that whatever functionality you include fully solves a problem for the user.
Tweet This:
“The minimum viable product needs to fully address a need or solve a problem for the user.”
This is why you cannot simply choose three of seven features on your product roadmap and decide that once you’ve built out those three features you will have a minimum viable product to ship.
You must always make sure that your MVP, in at least one area of its promised functionality, provides the user with a complete solution.
This obviously doesn’t mean your MVP needs to do everything you ultimately plan for your product. It means only that you need to be sure you are not simply giving your users three-quarters of the functionality to complete several tasks—but that you’re actually giving them the end-to-end functionality required to perform at least one task.
If your product doesn’t do that, you don’t have an MVP. And if you release it anyway, you run the real risk of disappointing your users and turning them away from your products forever.
2. The MVP needs to delight the user.
This is the key ingredient so many minimum viable products neglect to include. But in our opinion, if you don’t have something in your product that delights the user in some way, you do not have a true MVP.
As we have argued previously, customer delight is a must-have in your products. This is particularly true of software.
Why? For the same reasons we listed above explaining why you are facing so much pressure to release products sooner and with less functionality. With the barriers to entry for software providers continually falling, and the fact that you’re facing more competitors than ever, you can’t release an unimpressive, minimally useful product and expect to find a loyal user base eager for your next version.
For this reason, we think the Wikipedia definition above, which is widely accepted in the product world, misses a critical element of what constitutes a minimum viable product. Your MVP should not simply have just enough to satisfy early users; it must also delight them.
Customer Delight: The All-Important Ingredient Many Minimum Viable Products Miss
Product teams often neglect to focus on customer delight in their minimum viable products for logical (although misguided) reasons. They’re under a time crunch. The market seems to be pulling ahead. They are low on budget. The CEO demands it.
And adding some elements to the MVP’s already-stretched development plan just because it will delight users can seem unnecessary and even risky.
But think of all the times you’ve tried a new software product—particularly one in beta or where you otherwise knew the company was in the early days. If that product wasn’t impressive in any way, didn’t deliver something at least a little cool, were you likely to want to keep using it? Were you likely to be interested in future versions of the product?
How many chances do you think you’ll have to re-introduce your product to users if it doesn’t wow them the first time?
