Redefining MVPs: A faster way to derisk new product ideas
What makes a good MVP; What to exclude from your V0.1; What you need to do before writing your first line of code.
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 personally built a bunch of terrible MVPs over the years and watched hundreds of other founders follow the same path to failure, I think it’s about time we define what a good MVP actually looks like.
The Curse of Vague Definitions
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 — the need to disprove the biggest risks underpinning their idea in a resource-efficient manner.
A better approach to building an MVP would (1) clarify what founders need to understand about customers before building anything, (2) help founders identify the minimum amount of product that would need to be built to validate their idea, and (3) very specifically outline what features should be excluded entirely from the MVP. And that’s exactly what you’re going to get in this essay.
What to do before you start building an MVP
Your first product idea is likely very flawed in many ways. If you’ve got time and money to burn, you can of course uncover these flaws by just building your product to figure out what you got wrong. But most people don’t have that luxury, so they focus on answering these three questions before writing their first line of code:
1. Persona → Who are you building this product for? If you try to build a product for multiple different types of customers, then you’re gonna end up with something that isn’t really perfect for any of them. Instead, the best founders focus on building the perfect solution for one specific customer segment and then later scaling to other segments.
2. Problem → What high-priority problem do you solve for that customer? The best products solve a specific high-priority problem for a specific customer segment. When a customer has a high-priority problem, they proactively search for solutions. Founders that solve a ‘mild inconvenience’ end up begging target customers to consider their product. Choose your problem wisely.
3. Proposition → What value do customers get by solving this problem? This is the most often overlooked ingredient. Before you build your product, you need to understand how the customer’s life will be better once this problem has been solved. Otherwise, you don’t know the destination your customers are expecting to arrive at.
What to include in your MVP
The answers to those three questions are the ingredients that inform the most important decision for a pre-product founder:
4. Product → What is the unique thing your product does to solve this problem and deliver this value in a way that is more useful or valuable than any other solution currently available? The answer to this question is your Unique Product Attribute — the only part of your product that truly needs to be innovative.
Your Unique Product Attribute is the big risk at the heart of your entire startup. If you can nail it, you’ve got a great shot of winning the entire market opportunity. If you fail to build it, you fail overall. The goal of building an MVP is to prove that you can deliver Unique Product Attributes that are useable, valuable, feasible, and viable.
What to 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:
5. Positioning → Where are customers looking for your solution? Your target customers don’t share your depth of knowledge on the range of available solutions. Instead, they think of the market in categories — there are email tools, survey tools, CRMs, etc. You need to know what category customers are looking for a solution for their problem because that’s how you’re going to describe your product.
But this is more important than just product positioning. Whatever category your product falls into determines the core functionality that customers expect your product to have. For an early-stage product, I call these ‘Hygiene Features’ —without them, your customers are likely gonna have to pick your competitors over your product.
Right now, though, that doesn’t matter to you! You’re on Day 0 — you don’t need to think about stealing customers away from competitors just yet. Your focus right now is to derisk your idea by validating whether your core innovation solves a high-priority problem and delivers the expected value for a specific customer segment in a uniquely useful/valuable way.
So, although you’ll struggle to build commercial traction without including these hygiene features, you shouldn’t waste any time adding them to your MVP. Instead, you want to use your MVP to figure out what customers determine to be the most important hygiene features for your product category.
Watching people use your MVP (which at this stage is only the Unique Product Attributes) will uncover customers’ basic feature expectations. It’s worth noting that you won’t be trying to collect for feature ideas — you’re looking out for questions like “Why can’t I update this profile attribute?” or “I can’t find where I search for stuff?” that hint at usability dead-ends.
If you’ve solved a truly high-priority customer problem, you often don’t even need many Hygiene Features to attract your first customers. Once people have reached a certain level of desperation, they’ll happily duct-tape their way around the rough edges of your early-stage product if it solves helps them solve a hair-on-fire problem.
The difference between Unique Product Attributes and Hygiene Features
We draw a clear differentiation between Unique Product Attributes and Hygiene Features due to the difference in risk involved.
Hygiene Features are solved problems. People have already put years of work into building the most optimal version possible of the ‘Forgot Password’ flow, so just copy what works best. But don’t actually bother copying it just yet. If your startup is destined to fail, it won’t be because of your ‘Forgot Password’ flow — it will be the discovery that your Unique Product Attributes are not useable, valuable, feasible or viable (’The Four Big Risks’). So, rather than waste time iterating your sign-up flow to perfection when you haven’t even tested your idea’s core assumptions, focus on “tackling the big risks early” instead.
An actionable, research-led MVP definition
The best MVPs are experiments that test whether a set of Unique Product Attributes can successfully solve a high-priority problem and deliver the value expected by a specific customer segment in the most resource-efficient manner possible.
Resources to help you put this essay into practice
i. If you don’t agree that the first step is to pick just one target customer segment, then you should read this deconstruction of WeatherBill’s $930M pivot. Betting on one customer segment was the key 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 or not, you should read The Discovery Sandwich. It’s a simple three-part framework that uses breadth interviews, Customer Problem Stack Ranking, and in-depth interviews to identify and understand your target customer’s hair-on-fire problems.
iii. Figuring out the answer to the Product Positioning question (#5 in this essay) is harder than it looks. The best resource for this job is April Dunford’s book ‘Obviously Awesome’ — an actionable and concise read.
If you enjoyed this essay, please consider sharing it with friends that would find it useful. If you’re new to The Full-Stack Researcher, subscribe to receive future editions:
When I’m not writing essays, I’m busy building OpinionX — a free research tool for stack ranking people’s priorities. Thousands of product teams use OpinionX to get better data on their customer’s biggest needs so that they can make better-informed decisions about what to build next.