When crafting products, iteration speed matters because the faster you improve, the more quickly you capture market share. That’s why so many software companies use the “minimum viable product” approach, where they build and release the smallest possible “usable” set of features for their product, then rely on inbound feedback to improve the product later.
While this approach can be helpful if done correctly, too many companies misunderstand what the definition of “usable” is. That misunderstanding then causes them to alienate their users and mistakenly rule out potentially winning solutions as “non-viable.”
That’s why I’ve written this essay to help product marketers and product managers build and launch more compelling products.
First, I’ll talk through what kinds of mistakes startups make when building minimum viable products. Then, I’ll share an alternative approach called the “minimum valuable product” approach. Finally, I’ll break down how to know whether you’re building in the right set of functionality or not when deciding what goes into your minimum valuable product.
What mistakes do companies make with minimum viable products?
When companies use the “minimum viable product” strategy, one common mistake that they make is that they determine for themselves what “minimally viable” means.
In other words, few companies actually speak with target users or conduct user research before deciding what the “cut line” is for a minimum viable product.
They treat the minimum viable product as a technical proof-of-concept, and get it out the door as quickly as possible, with very little functionality that truly solves the pain of their target market.
When companies pick a barebones threshold without speaking to users first, it winds up dissuading the target user segment from engaging with the minimum viable product that they’ve released.
While the company does achieve its stated objective to get a product into the market quickly, they fail to achieve the true objective of engaging with early adopters because their initial product offering is so thin.
When early adopters can’t see the benefit of working with such a barebones product, companies are unable to gain helpful feedback or capture revenue, which then causes them to pivot away from their minimum viable product entirely.
Don’t believe me?
Even companies as well-known as Google make this kind of mistake.
Many of Google’s messaging apps are built off of the minimum viable product mindset, and that strategy has plagued them with “bad first impressions” at the exact moment when their products have “the most attention and news coverage” (Ars Technica, 2021). That then causes their user base to “check out the bare-bones creation, declare it to be hopeless, and forget about it.”
This lack of critical mass has caused Google to fail to gain meaningful traction in the messaging app space for over a decade. Because they never secured enough users, they couldn’t staff more resources. And because they couldn’t staff up, they couldn’t address user feedback, which caused them to lose even more users.
You can see this vicious cycle play out not just with Google messaging apps, but also with a variety of products launched by startups and public companies alike.
What’s the root cause of failure with using the “minimum viable product” approach?
The problem with defining your product as “minimally viable” is that it’s not hypothesis-driven. Rather, decision-makers are whipping up subjective guesses on “how few features is enough for this iteration”, which isn’t an effective way to gain traction and drive learnings.
So, what would a better approach look like?
Companies can use the minimum valuable product framework to be more successful. To bring this concept to life, we’ll take a look at Venmo, the popular peer-to-peer payments app.
What is a minimum valuable product?
Coming up with a “minimum valuable product” forces you to define your value generation hypotheses more clearly, which then leads to faster and more impactful iteration.
A minimum valuable product requires us to first define “value.” And, we can’t define “what is valuable” until we pick a target segment and understand what their pains and needs are.
Rather than broadly aiming for “what is few enough features for early adopters to give it a try”, you have to define two things upfront before writing a single line of code:
- Which audience are we targeting?
- What functionality creates value for this audience?
These two pieces of information then form the basis of our value generation hypothesis. In other words, if we believe that “features A, B, and C are all necessary to create value for audience X”, then that’s a testable hypothesis for “how we think we’ll generate value.”
Let’s rewind the clock and consider what Venmo might have built as a “minimum viable product.”
A peer-to-peer payments app needs to enable users to send and receive payments. So, that’s technically “enough” to be usable.
But, Venmo’s value generation hypothesis wasn’t “people can’t send each other money.” Before Venmo existed, people could send each other money through checks and cash.
So, what was Venmo’s value generation hypothesis? Before we can look at that, we first have to look at what audience Venmo was targeting.
Venmo’s target audience was “tech-savvy young adults who use their phones to message each other.” Their audience wasn’t “business owners” or “financial institutions”, and their audience wasn’t “heads of households.”
For tech-savvy young adults, what kinds of functionality would delight them? In other words, what unmet needs did they have?
Venmo discovered that tech-savvy young adults wanted to share their payments feeds with others as a fun way to socialize. If Venmo could make sending money over the phone both fun and easy, it could win over this particular market segment.
Therefore, the ability to broadcast a public feed of payments to friends was its minimum valuable product. Emojis, likes, and comments were essential to Venmo’s success, even though they weren’t technically required to be “simply viable” as a peer-to-peer payments mobile app.
In this Hustle breakdown, you can easily see how Venmo could have launched solely with payments, without any sort of notation on what the payments were for, and without any social messages.
The stripped down version of “pay me over SMS” would have been the minimum viable product. They could have launched with that feature set and confirmed that their technology works, but they wouldn’t have gained the traction that they did.
We can be thankful that they opted for the minimum valuable product instead.
Because they thoughtfully identified their target audience and discovered an unmet need, Venmo created a product that was valuable and delightful for their target audience. That then enabled them to gain traction, gather feedback, and grow into the behemoth that it is today.
Why are minimum valuable products more effective than minimum viable products?
Once we decide which target audience to focus on, we’re no longer making uninformed guesses about “which features are minimally usable.”
As a reminder, just because an app is usable doesn’t mean that people will engage with it. And if people don’t engage with it, then you can’t get the feedback that you need to iterate.
Rather, as product managers, product marketing managers, engineers, and designers, we need to identify the set of functionality that crosses a minimum “critical mass threshold” of being valuable for a specific segment of the market.
Once we do so, we can then truly test our value generation hypothesis. We can confirm or disprove whether our feature set really does provide value to a specific market segment.
But wait, how do we know whether we’re putting way too many features into our hypothesized minimum valuable product? Here’s a litmus test to find out.
How do you know if you’re overbuilding your minimum valuable product?
Before you start coding or designing your product, first pull together the list of features that you’re planning on including in your initial release.
Once you have this itemized list of proposed features, you can then perform this exercise.
Look at the first feature on the list. Then, pretend that you’ve killed it. Now ask: “does this remaining set of features still provide real value to my target segment?”
If you can cut the feature and you can still provide value to your target segment, then you’re overbuilding.
Again, let’s look at how Venmo built their minimum valuable product. Back when they launched in 2009, they theoretically could have added lots of bells and whistles to their initial launch, such as QR code scanning or seller programs.
Venmo could have fallen for the trap of “build something for everyone.” They could’ve tried to build seller programs for small businesses and social feeds for tech-savvy consumers.
But, they stayed laser-focused on tech-savvy consumers rather than businesses, and that made all the difference in terms of iteration speed and traction.
So, now we know how to test which features are “too much” for our minimum valuable product, which saves us valuable time and money. But, how do we know if we’re underbuilding?
How do you know if you’re underbuilding your minimum valuable product?
We can repeat the exact same exercise above to determine “which features are absolutely essential to our initial release.”
As you go down your list of features, pretend that you’ve killed the feature. Then ask, “does this set of features still test my hypothesis on what’s valuable for my target segment?”
If you can no longer test the hypothesis because you’ve now cut away the key value proposition, then you know that you’re underbuilding.
As an example, if Venmo had cut out the ability to share payment feeds with friends, they would not have been able to tell whether young adults would clamor for their app as a new way to socialize with one another.
A generic payments app with no commenting and no feed would not have tested the value generation hypothesis of “we can create viral word-of-mouth through friends”, and that would have killed Venmo’s ability to get feedback and attention from early users or investors.
Closing thoughts
Instead of building a minimum viable product and alienating users, aim to build a minimum valuable product instead.
To build a minimum valuable product, you first have to define a single target segment to focus on, and you have to identify the key hypothesis about which of their needs you’re solving.
Once you’ve done so, you can then calibrate your proposed feature set by systematically analyzing each feature and asking, “is this really necessary for me to test my value generation hypothesis?”
By doing so, you’ll ship more impactful products and accelerate your iteration speed.
