Redefining MVPs: A faster way to derisk new product ideas
“Most MVP definitions are too vague to act on. A good minimum viable product isn’t about collecting the maximum amount of learning; it’s an experiment that tests the single biggest risk in your idea: whether your core innovation solves a high-priority problem and delivers real value for one specific customer segment, in the most resource-efficient way possible.”
Before you build, answer five questions: Persona (who is it for?), Problem (what high-priority problem do you solve?), Proposition (what value do they get?), Product (what unique thing do you do that no one else does?), and Positioning (what category are customers searching in?). The answer to the Product question is your Unique Product Attribute, and that's the only thing your MVP should contain. Leave out Hygiene Features, the solved, expected features like login and search, until you've proven the core works.
MVPs have given countless founders and product teams a free ticket to jump straight into building overscoped products that aren't designed to learn anything from.
Having built a bunch of terrible MVPs over the years myself, and watched hundreds of other founders take the same path to failure, I think it's about time we defined what a good MVP actually looks like.
Why are MVP definitions so vague?
Eric Ries, author of The Lean Startup, defines an MVP as:
“... that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
This is a pretty crappy definition. Founders don't need to "collect the maximum amount of learnings about customers" on Day 1. They need to disprove the biggest risks underpinning their idea in a resource-efficient manner.
A better approach would (1) clarify what founders need to understand about customers before building anything, (2) help them identify the minimum amount of product they'd need to build to validate the idea, and (3) spell out exactly which features to leave out of the MVP. That's what you're going to get in this essay.
What should you do before building an MVP?
Your first product idea is probably flawed in a lot of ways. If you've got time and money to burn, sure, you can uncover those flaws by just building the thing and seeing what you got wrong. But most people don't have that luxury, so they answer these three questions before writing a line of code:
Persona → Who are you building this product for? Try to build for several different types of customer and you're gonna end up with something that isn't quite right for any of them. Instead, the best founders build the perfect product for one specific customer segment, then scale to other segments later.
Problem → What high-priority problem do you solve for that customer? The best products solve one high-priority problem for one specific customer segment. When a customer has a high-priority problem, they go searching for a fix. Founders who solve a "mild inconvenience" end up begging target customers to even consider their product. Choose your problem wisely.
Proposition → What value do customers get by solving this problem? This is the most overlooked ingredient. Before you build, you need to understand how the customer's life gets better once the problem's solved. Otherwise you don't know the destination they expect to reach.
What should you include in your MVP?
The answers to those three questions are the ingredients that inform the most important decision for a pre-product founder:
Product → What unique thing does your product do to solve this problem and deliver this value, more usefully or valuably than anything else out there? The answer is your Unique Product Attribute, the only part of your product that actually needs to be innovative.
Your Unique Product Attribute is the big risk at the heart of your whole startup. Nail it and you've got a great shot at winning the market. Fail to build it and you fail overall. The goal of an MVP is to prove you can deliver Unique Product Attributes that are usable, valuable, feasible, and viable.
What should you exclude from your MVP?
To improve on the current definition, we also need to define what shouldn't go into your MVP. To do that, you need to answer one last question:
Positioning → Where are customers looking for your product? Your target customers don't know the range of options as well as you do. They think of the market in categories: email tools, survey tools, CRMs, and so on. You need to know which category customers are searching in to solve their problem, because that's how you'll describe your product.
But this matters beyond positioning. Whatever category you land in determines the core functionality customers expect. For an early-stage product, I call these "Hygiene Features". Without them, customers are gonna pick your competitors over you.
For now, though, that doesn't matter. You're on Day 0, so you don't need to think about stealing customers from competitors yet. Your job is to derisk the idea: validate whether your core innovation solves a high-priority problem and delivers the expected value for a specific segment in a uniquely useful, valuable way.
So even though you'll struggle to build commercial traction without these hygiene features, don't waste time adding them to your MVP. Instead, use the MVP to find out which hygiene features customers decide matter most for your category.
Watching people use your MVP (which at this stage is only the Unique Product Attributes) will uncover their basic feature expectations. You're not collecting feature ideas; you're watching for questions like "Why can't I update this profile attribute?" or "Where do I search for stuff?" that point to usability dead-ends.
If you've solved a genuinely high-priority problem, you often don't need many Hygiene Features to attract your first customers. Once people are desperate enough, they'll happily duct-tape their way around the rough edges of your early-stage product if it solves a hair-on-fire problem.
Unique Product Attributes vs Hygiene Features
We draw a clear line between Unique Product Attributes and Hygiene Features because of the difference in risk.
Hygiene Features are solved problems. People have already put years into building the best possible "Forgot Password" flow, so just copy what works. But don't even bother copying it yet. If your startup is destined to fail, it won't be because of your "Forgot Password" flow; it'll be the discovery that your Unique Product Attributes aren't usable, valuable, feasible or viable ("The Four Big Risks"). So instead of perfecting your sign-up flow before you've tested your idea's core assumptions, focus on "tackling the big risks early".
| Unique Product Attribute | Hygiene Feature | |
|---|---|---|
| What it is | Your core innovation, the one thing that solves the problem better than anything else | A solved, expected feature for your category (login, search, forgot-password) |
| Risk | High: if it fails, the startup fails | Low: already solved, copy what works |
| Include in your MVP? | Yes, this is all your MVP should be | No, leave it out until the core is validated |
| Why | It's the big risk you need to test first | Building it early wastes time on a non-risk |
A better, research-led MVP definition
The best Minimum Viable Products are experiments that test whether a set of Unique Product Attributes can solve a high-priority problem and deliver the value a specific customer segment expects, in the most resource-efficient way possible.
Frequently asked questions
What is a minimum viable product (MVP)? Eric Ries defines it as the version of a product that lets a team collect the most validated learning with the least effort. A more actionable definition: an MVP is an experiment that tests whether your core innovation solves a high-priority problem and delivers real value for one specific customer segment, as cheaply as possible.
What should an MVP include? Only your Unique Product Attribute, the one part of the product that has to be genuinely innovative to solve the problem better than the alternatives. That's the big risk your MVP exists to test.
What should you leave out of an MVP? Hygiene Features: the solved, expected features for your category, like login, search and forgot-password flows. They're low-risk and already solved elsewhere, so building them before you've validated the core just wastes time.
How do you validate an MVP idea before building it? Answer five questions first, persona, problem, proposition, product and positioning, and make sure the problem you're solving is genuinely high-priority for a specific segment. If the core problem isn't urgent, no amount of polish on the rest of the product will save it.
Resources to put this into practice
i. If you don't buy that the first step is to pick just one target customer segment, read this deconstruction of WeatherBill's $930M pivot. Betting on one segment was the decision that turned their failing startup into a billion-dollar exit in just 3 years.
ii. If you're not sure how to validate whether a problem is high-priority, read The Discovery Sandwich. It's a simple three-part framework that uses breadth interviews, Customer Problem Stack Ranking, and in-depth interviews to find and understand your target customer's hair-on-fire problems.
iii. Working out the answer to the Positioning question (#5 in this essay) is harder than it looks. The best resource for it is April Dunford's book "Obviously Awesome", a concise, practical read.
When I'm not writing essays, I'm busy building OpinionX, the platform for advanced market research surveys. Thousands of product teams use OpinionX to get better data on their customers' biggest needs, so they can make sharper decisions about what to build next.
Daniel