Nothing has contributed and detracted more from our industry than the Minimum Viable Product (MVP). As an industry, we’ve tried to address and minimize the potential downside of the MVP by reframing the concept as Minimum Lovable Product, Minimum Awesome Product, etc… One challenge is that we as founders and makers want to jump right to just that, making a product. We skip crucial steps that maybe aren’t in our comfort zones.
Building an MVP is only a part of the journey to building products people love. And an important part of that journey is doing the hard, and sometimes disheartening work of uncovering the what-to-make, followed by the equally hard work of commercializing a product at scale. The MVP has the potential to lead companies down a path to failure, not success. So how did we get here and where did we go wrong?
Context
The MVP was introduced in 2001 by Frank Robinson at a time when the waterfall model for software development was the common practice. Elongated product cycles and a hesitancy to talk to actual users prevailed. It was not unheard of to take more than a year to develop and bring a concept to market without ever making contact with a single potential customer. In 2008, Eric Ries popularized The Lean Startup in collaboration with Steve Blank, author of the 2005 book Four Steps to Epiphany.
Waterfall vs Agile showing Risk and Value over time
The concept was radical: we’d interview customers to understand their needs, we’d develop a hypothesis, implement it and measure results. We’d use those results to inform our product. Rinse, lather and repeating our way to a TechCrunch article heralding our success.
The Lean Startup Build-Measure-Learn Loop
Momentum built for the Lean movement and for a good reason — the lean approach to building software was both revolutionary and successful. Companies large and small were making better decisions and building better products much fast than before. The time to bring a product from concept to market could now neatly fit in a typical accelerator cohort timeframe which may have contributed to the early stage investment boom. Now venture capitalists (VCs) could expect actual user and revenue traction and, for the most part, were no longer funding just ideas.
Socialcam’s Y Combinator demo day pitch broadcast with their own MVP. Look at those DAUs!
The value of the MVP is that it loosely serves as a prototype. A prototype that can be used to have conversations with potential customers and users. A prototype you can use to test features. A prototype you can use to test people’s willingness to pay for your product and in some cases, even pre-pay for a fully baked product.
But then we lost our way. We forgot that the MVP was a prototype at its core. Folklore of MVPs yielding multi-million ARR run rates, such as Airbnb and Dropbox became fact, ignoring that those stories usually involved sophisticated growth hacking, effective customer success tactics and continued research and development (R&D) investments. Most importantly we forgot these products began as an MVP and evolved dramatically on the journey towards world domination.
Investments flowed and we dubbed them seed, pre-seed, post-seed rounds to reflect that while these companies had traction, they weren’t quite Series A companies. But why not? Well, both consumer and B2B users’ expectations continue to increase when it comes to software offerings and this includes production values, quality and your ability to support them. It is absolutely possible to capture early adopters with an MVP, yes the Chasm is still very relevant today.
The Chasm Group’s Technology Adoption Lifecycle Model
And with the Chasm, you can’t skip steps — you can’t use a sophisticated Product Hunt campaign to get to the Early Majority at launch. You need to build and ship a whole product, which Geoffrey Moore describes as “everything required to assure that your target customers can fulfill their compelling reason to buy.”. The classic example is Apple offering not just an MP3 player but also iTunes so users can have a total digital music experience.
For early-stage products, delivering “a whole product” is a fancy way of saying there’s a gap between what your product does, how you market it: “Disruptive!”, and what your target customer expects it to do: “Solve my damn problems!”.
You have to fill this gap with services, high-touch support, onboarding campaigns and maybe even some heroics to make your customers satisfied and productive in the early days. Companies that don’t recognize this, tend to get stuck and often end up spiraling the drain via a series of bridge and down financing rounds. The usual outcome is a controlled flight into terrain for these products that fail to launch. (Hey, thanks for letting me mix my aerospace metaphors.)
Scott’s Belsky depiction of the “real journey” building a company
This isn’t to crap all over the MVP, instead, it’s to recognize the role of the MVP as a tool to validate or invalidate your hypothesis: measure-learn-build-repeat. Before you build anything it’s critical you do the upfront work to identify your users and the problem you’re solving for them. A disclaimer: it’s possible you learn something you don’t want to hear during this phase but you’d rather find out bad news now when you still have time to react rather than invest your time, energy and money in a doomed product.
Then it’s time to validate your product. Depending on where you are in your learning you may use different methods to achieve this. It may be appropriate to conduct customer interviews if you need exploration into the problem you’re tackling. If you need to identify pain points, you might perform field studies to see users in their environments tackling the problem and more importantly to see how they solve it. Lastly, and here’s where an MVP-as-prototype shines, you might conduct user testing to validate your solution with your customers and/or potential customers. Remember to ask the hard questions and in particular, select questions that will validate or invalidate your hypothesis. Don’t ask things like “do you think this is a good solution?” Look to your friends and family for hugs and high-fives, not your users.
Now that you’ve gathered data and feedback, it’s time to share your insight with the team. What did you learn about your customer, about the problem you’re tackling and your proposed solution? Pay particular attention to how and why your learnings suggest you need to adapt not just your MVP but your whole product on your journey towards world domination. Build-measure-learn repeat.
