What is and Isn’t a Minimum Viable Product (MVP)?
As product people in the non-startup world familiarize themselves with Lean Startup concepts, there’s a lot of discussion and confusion about what is and isn’t a minimum viable product (MVP). Worse, many execs and CEOs have latched on to the term without really understanding it—using it as a buzzword and as a synonym for a completed V1.0 that is ready to be sold to all customers.
Buzzwords are meaningless; they represent lazy thinking. If you’re using MVP to mean “first market launch” or “first customer ship,” it means you’re back to the old waterfall, project-driven approach to software development. If that’s your approach, OK. Just don’t confuse what you’re delivering with an MVP.
On the flip side, many folks in the enterprise world, including product professionals, are overthinking the term. They think of MVP as simply the smallest collection of features to satisfy customers. The problem with that approach is it assumes we know ahead of time exactly what will satisfy customers. But the odds are that when it comes to a startup product, we don’t—even if we’ve served those customers for years with other offerings.
MVP constitutes an entirely different way of thinking about our approach to new product development. Instead of being about product delivery, it’s about delivering product. It’s not about delivery for the sake of delivery–to hit some magical release date or arbitrarily set internal milestone–but it is about getting product into your customers’ hands, learning from their feedback and iterating on that learning while continuing to drive value. As such, an MVP is about validated learning. It puts customers’ problems, not our solution, squarely at the center.
Reality check: Customers don’t care about your solution. They care about their problems. To play on a Pragmatic Institute phrase, “Your solution, while interesting, is irrelevant.”
So if we’re going to use the term, MVP, it’s important to understand what it really means. Fortunately, all it takes to do that is to go back to the source.
MVP is a term coined by Eric Ries as part of his Lean Startup methodology, which lays out a framework for pursuing a startup in particular, and product innovation more generally. This means we need to understand the methodology of Lean Startup to have the right context for using terms like MVP. (Just like we shouldn’t use “product backlog” from Agile as a synonym for “dumping ground for all possible feature ideas.”)
Ries lays out a definition for what an MVP is:
“The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
He goes on to explain exactly what he means:
MVP, despite the name, is not about creating minimal products … In fact, MVP is quite annoying, because it imposes extra overhead. We have to manage to learn something from our first product iteration. In a lot of cases, this requires a lot of energy invested in talking to customers or metrics and analytics.
Second, the definition’s use of the words maximum and minimum means it is decidedly not formulaic. It requires judgment to figure out, for any given context, what MVP makes sense.
Let’s break this down.
- An MVP is a product. This means it must be something delivered to customers that they can use. There’s a lot that’s been written about creating landing pages, mockups, prototypes, doing smoke tests, etc., as forms of MVPs. While these are undoubtedly worthwhile efforts to gain valuable learnings, they are not products. A product must attempt to deliver real value to customers.
- An MVP is viable. This means it must try to tangibly solve real-world and urgent problems faced by your target customers. So it’s not about figuring out the smallest collection of features. It’s about making sure we’ve understood our customers’ top problems, and figuring out how to deliver a solution to those problems in a way that early customers are willing to “pay” for. If we can’t viably solve early customers’ primary problems, everything else is moot. That is why an MVP is about validated learning.
- An MVP is the minimum version of your product vision. In his blog post on why “Luck: The Secret Sauce of Successful Startups,” Ramli John provides some fascinating examples of MVPs using email, blogging, video and plain old hustle—including Groupon, which actually started as a blog. If our MVP is actual code, it most definitely does not mean it is a half-baked or buggy product. The “minimum” is that it needs to viably solve early customers’ top problems from day one, building only those features at first and putting everything else in the backlog until we’ve achieved product/market fit. It also means being very deliberate about finding those “earlyvangelists” that Steve Blank always talks about.
Ultimately, the key here is “maximum amount of validated learning.” This means being systematic about identifying our riskiest assumptions, formulating “testable falsifiable hypotheses” around these, and using our MVP to prove or disprove our hypotheses.
Lean Startup Realities
One of the biggest challenges product innovators face in defining an MVP is getting buy-in from internal stakeholders. Somehow, you have to make everyone feel a part of the process without having your MVP destroyed by feature bloat right at the definition stage.
The way I’ve done it is by fusing Lean Startup methods with product management practices—specifically by leveraging a process every product manager knows: roadmap prioritization.
In a Roadmapping 301 presentation, Bruce McCarthy has talked about “The 5 Pillars of Roadmaps,” the first three of which are.
1. Setting strategic goals
2. Objective prioritization
3. Shuttle diplomacy
These same pillars can be used for defining an MVP and getting stakeholder buy-in.
Setting Strategic Goals
The first step is to capture your product strategy. Although business cases, business plans and market requirements documents have their place, we need a way to quickly capture product ideas in a structured manner that is easy to share with others. I iterated from Alex Osterwalder’s Business Model Canvas and Ash Maurya’s Lean Canvas to create what I call the Product Canvas. It allows you to capture the key elements of any particular product or product strategy in a single page or snapshot.
What’s great about the Product Canvas is since it’s a single page, you can quickly jot down the basics of any product strategy or business model. It’s easy to share and more likely to get read than a PowerPoint deck or a Word doc. The single page also forces brevity: There isn’t a lot of space for a laundry list of features. You will need to distill your idea to its most essential building blocks.
Here are the key components of the Product Canvas:
1. Customer segment. Who is the target customer of our proposed product? This could be the company’s entire customer base, a segment or a new market or vertical.
1a. Early adopters. This section is designed to help explicitly avoid the temptation to think a new product idea is applicable to all customers. Identifying early adopters is critical to early traction for any new product.
2. Problem. Limit this to the top three problems we’re addressing for our target segment.
2a. Existing alternatives. How is the customer solving this problem today? This includes both direct and indirect competitors
3. Unique value proposition (UVP). What is the promise we’re making to our customers? This is the elevator pitch that clearly states how we’re uniquely solving our customers’ primary problem.
4. Solution. What are the most essential features of our solution that will deliver on our UVP? Limit it to the top three elements of the proposed solution.
5. Channels. How will we acquire, retain and sell more to customers? What is the marketing and sales strategy?
6. Revenue streams/business value. How will we make money? What’s our pricing strategy? If this is not a revenue-generating product, what other business value is it providing? Is it improving customer satisfaction, customer lifetime value or market positioning? Competitive differentiation? Operational efficiencies?
7. Key metrics or success factors. What are the most important metrics that will tell us that we’re successful? Sign-ups? Conversions? Referrals? These are the metrics that are driving our business value.
8. Unfair advantage. The UVP tells our customers how we uniquely solve their problem. Unfair advantage is about how our product or business model gives us a sustainable advantage. Do we have a patent? Benefit from economies of scale? A distribution network or brand value that can’t be easily copied or bought?
9. Key resources. What are the most critical resources we need? These could be platforms, systems, business processes or even partners.
10. Cost structure. What are the key cost drivers? Customer acquisition? Account management? Hiring and talent development? This is also a good place to capture a back-of-the-envelope break-even calculation.
The Product Canvas allows you to document your vision in a simple, portable and sharable way. The trick is to be concise. The intent isn’t to capture every nuance of the customer’s problems, nor detailed requirements. Just stick to the top three to five problems and the top three to five key elements of your solution.
This forces sharpness not only in your thinking, but also in your communication with stakeholders. This, in turn, encourages more constructive feedback, which is what you really need at this stage.
Objective Prioritization
You’ve probably received a lot of internal input (solicited and unsolicited) on features for your product. Most have probably been articulated as “must-haves” for one reason or another. Of course, you know that most of them are probably not really needed at this early stage, certainly not for an MVP.
To quote from the book “Getting Real” by 37signals: “Make features work hard to be implemented. Each feature must prove itself.” For an MVP, each feature must be tied to tangibly solving a top customer problem.
McCarthy discusses using a scorecard type system to objectively prioritize features for product roadmapping—in particular, assigning a value metric for a feature’s contribution toward the product’s business goals, and balancing it against a level-of-effort (LOE) metric. The exercise can easily be done in a spreadsheet.
A similar approach can be used to prioritize the features for your MVP:
- Rank each problem documented in your Product Canvas. Ranking should be in terms of your understanding of what is the customer’s top-most problem to be solved, followed by the second, etc.
- Map solution elements to problems. These may not necessarily be one-to-one, as sometimes multiple elements of your solution may work together to solve a particular customer problem.
- For each solution element, identify if it’s a must-have for your MVP. Solution elements meant to solve customer problem #1 are automatically must-haves. The trick is in making the determination for the remaining problem/solution mixes.
- Identify all features for each solution element. If you already have a list of feature ideas, this becomes more of a mapping exercise. The net result is every feature idea will be mapped directly back to a specific problem, which is awesome.
- Mark each feature as “In MVP” or not. Be ruthless in asking if a feature really, really needs to be part of the MVP. This includes specific features under a “must-have” solution element, as not every one may need to be “In MVP.”
- “T-shirt size” the level of effort for each feature. Just large/medium/small at this point. A quick conversation with your engineering lead can give you this.
Like with roadmap prioritization, this entire exercise can also be done via a simple spreadsheet. The beauty of this exercise is it brings into sharp focus a particular feature’s contribution toward solving customers’ primary problems. And an MVP must attempt to do exactly that.
Shuttle Diplomacy
Managing stakeholders is probably the most important part of any product development process. You need to get buy-in from your key stakeholders on your product strategy and have it “stick over time.”
McCarthy advocates using “shuttle diplomacy,” which in short means a series of ongoing conversations with your key stakeholders in which you need to ensure they’re feeling heard, while also being transparent about sharing the results of your customer and product development efforts. To quote McCarthy, when you practice shuttle diplomacy:
“A magical thing happens. ‘Your’ plan becomes their plan too. This makes [review and approval] more of a formality, because everyone has had a hand in putting together the plan.”
To be clear, you’re not looking for “decision by committee.” As the product owner, you still need to take a leadership role in making or facilitating decision making. A key part of leadership is actively working to bring others along by encouraging input and providing visibility.
Lean startup purists may find this nauseating, but that ignores the realities of getting things done in the corporate world. As Henry Chesbrough wrote: “You have to fight—and win—on two fronts (both outside and inside), in order to succeed in corporate venturing.” This means innovators “must work to retain support over time as conflicts arise (which they will).”
As I’ve shown, savvy product managers can fuse Lean Startup principles with tried and true product management practices with powerful results. With respect to an MVP, it’s important to remember it’s not about the smallest collection of features that can be delivered, but rather about validated learning, and then quickly iterating on that learning to gain market traction for your new product. Then use your practical product management skills of strategic goal setting, objective prioritization and shuttle diplomacy to gain and maintain traction internally.
