Minimum Viable Products versus Maximum Possible Products
The Difference Between Learning and Proving
Welcome to Speedwell Research’s Newsletter. We write about business and investing. Our paid research product can be found at SpeedwellResearch.com. You can learn more about us here.
There is a podcast of this memo that is available if you prefer listening to it. You can find it on our podcast feed here (Apple, Spotify).
If you are new to Speedwell Memos, welcome! We have pieces on The Reverse DCF, Sell-side Price Targets, Zara & Shein, Google’s AI risk, Why Wish Failed, Alibaba’s Accounting, What was priced into Home Depot in 1999, and many more! If you haven’t already, check out our business philosophy pieces on The Piton Network (Part 1 and Part 2), as well as our Series on The Consumer Hierarchy of Preferences. A directory of our memos can be found here
Intro.
The test of a first-rate intelligence is the ability to hold two opposing ideas in mind at the same time and still retain the ability to function.
– Scott Fitzgerald
Is the customer always right? Or does the customer not know what they want?
Do you build what your customers say they want? Or do you build what they don’t know they want yet?
There are two seemingly contradictory ways to build a great product and a great company.
Do you build a perfect product and then introduce it to the customer, or do you get something out in front of the customer as quick as possible because you do not know what perfection is.
The former style is best portrayed by Apple, who in deep secrecy creates a new product with zero customer feedback prior to releasing it. The latter is usually referred to as a MVP or minimum viable product, popularized by Eric Ries’s Lean Startup. This is essentially how Amazon started as nothing was automated on the back end. Every time they made a book sale, a bell rung and a person manually sorted through books to pick & pack on the floor (they later facetiously noted that the idea of packing on a table was revolutionary).
These two innovation strategies seem worlds apart, but they have one fundamental underlying similarity.
The Foundation of Dueling Innovation Strategies.
Steve Jobs and Jeff Bezos both are building products that they themselves want to use.
Even when these products are created in secrecy, the person that the product is built for is usually themselves. Steve Jobs just thought how he would want to use the iPhone and built that. He was still building it to a customer, it just was a sample size of N=1. Similarly, James Dyson was solving problems he thought annoying: vacuums that lost suction, needed bags, and were hard to maneuver.
If you watch an episode of Shark Tank, you will see a very high correlation between interesting products that have strong use cases and whether that entrepreneur was solving a problem they themselves had. In fact, it is a considered a criticism if a Shark says “I don’t know what problem your product solves.”
This idea is similar to the Clay Christensen framework of “Jobs to Be Done”. A product is “hired” for something specific and if that entrepreneur built that product with a problem they had in mind—after they checked that all the existing alternatives couldn’t complete that job—then there is a high probability that that product fulfills a unique job. (That doesn’t mean it isn’t extremely niche though and thus might not be attractive as a business opportunity, i.e. Bob Iger’s proverbial trombone oil).
But there is of course still major differences between the two innovation styles: Do you know exactly what the customer wants? Or are you just lobbing an idea out and relying on the customer to get you closer to the end product?
Execution vs Idea Validation.
A keen observer may have noticed that there are really two aspects to an MVP. First, there is the MVP where an entrepreneur doesn’t know exactly what they should make and so they rely on customers to tell them with feedback. Second, there is an MVP in execution. While these two typically go together since someone who doesn’t know what to make will (or should) not spend much time on making the product as good as possible, they do not necessarily have to.
Amazon was an MVP only in execution because Jeff Bezos wasn’t worried about validating the idea: he knew people would buy things online. But he didn’t spend time perfecting a backend system and the design of the site, instead he just got started and knew all of these things would continue to improve overtime.
In contrast, Zappos founder Nick Swinmurn was unsure if people would buy shoes online in 1999. It was widely assumed that customer would want to feel how a shoe fits before buying it, so footwear wouldn’t be a good candidate for online sales.
Instead of just accepting that commonly held “wisdom”, he would snap photos of shoes from local retailers and post them online. If they sold, he could then purchase them at the store and ship them off. Swinmurn proved there was latent demand for online shoe sales. Zappos was both an MVP in execution and in idea validation.
The founders of DoorDash, before focusing on delivery, thought they would create software for small businesses to help them manage their business better. However, the small business owners they spoke with were disinterested in that. But one owner pointed out that delivery was a pain point, so they moved to focus on that.
Instead of spending months to push out a polished product, they created an MVP to test if the idea had validation. As DoorDash Cofounder, Stanley Tang notes below, “it was super simple, ugly and we weren’t really expecting anything”.
They decided to build a basic web page with menus from local restaurants to see if there was demand for a delivery business. “It was super simple, ugly, and honestly we weren’t really expecting anything,” Tang said at a Stanford lecture years later. “All of a sudden we got a phone call – someone called! They wanted to order Thai food.”
Alfred Lin, who would lead Sequia’s Series A investment in DoorDash after being unsure about the idea initially when he saw them at Y combinator, similarly noted that they didn’t know if this was a real problem they were solving.
We weren’t sure whether this was a problem that needed to be solved at the time, but it turned out to be a very big problem,” he told me. “All restaurants would deliver if they could, but it didn’t make sense for every restaurant to have their own. The same was true with all local merchants.”
On the other end of the spectrum, is what we will call a “Maximum possible product”. This is Apple’s iPhone. Maximum possible product’s, or MPPs, are not about idea validation to the entrepreneur, but rather to the masses. MPPs require very high execution because they are trying to convince people that they need something they previously didn’t know they did. Any sort of mediocrity in the product is doing a disservice to convincing them that they need this product.
We will talk more about MPPs in a moment, but first let us think in terms of the Consumer’s Hierarchy of Preferences to gain a better understanding of why something works.
Consumer Preferences Matter.
The Consumer’s Hierarchy of Preferences can also be thought of as the “Merchant’s” or “Business’s” Hierarchy of Preferences. The general idea is that there exist various preferences for any product and once a sufficient number of preferences are fulfilled, then there is an exchange of money for the product.
An MVP works well at finding what those minimum preferences are that need to be fulfilled in order to elicit a sale. Is the convenience of online shoe shopping a high enough preference that people are willing to risk the hassle of a return, wait several days, and pay a premium for delivery? The MVP discovered the answer.
The DoorDash team found out that helping restaurants take online orders and arrange for delivery was fulfilling a strong enough need to earn a merchant’s business. MVP products are about getting to market quickly, knowing that their solution, despite being hastily implemented, is good enough to start to serve the market.
In contrast, an MPP is about revealing unknown consumer preferences. It’s about creating something people didn’t know they wanted. Whether it is Apple’s iPhone, iPad, or AirPods, Dyson’s vacuum cleaner or Airwrap, Ford’s Model T, or Amazon’s AWS, these products were all created as very polished versions of the idea they represented. This is because they had to show the consumer that these were products they wanted. In contrast to an MVP where a customer has an imagination of what the product could become (and can share so with feedback), the MPP must instill that imagination in the consumer, getting them to envision why they need the product.
There is of course a bit of blurred line looking retrospectively because overtime these businesses continue to iterate on their products, so their initial launch looks like an MVP and not MPP. The iPhone 1, the original Dyson, and the Model T are all worse in everyway then their modern counterparts, but these products were all near the best they could have been at the time. And most critically they all revealed consumer preferences that were unknown to exist prior to their launch. People didn’t know they wanted a car before Henry Ford popularized it and the cloud wasn’t on anyone’s mind before AWS.
Just think of the quote commonly attributed to Henry Ford: “If you were to ask a customer what they wanted, they say faster horses.”
While we can be glib about this statement, it actually has an incredible amount of insight in it—and it is not for the reason that people typically think.
It seems intuitive to us that prior to the advent of cars, the typical person wouldn’t have thought of a car as something they wanted because it didn’t exist! An MVP is designed to give people something they would have already wanted (a faster horse) and couldn’t have successfully been used to launch a car. This is because to convince someone to try something totally new, their new experience with it can’t be garbage. How much would you have loved your first iPhone if it was very buggy, crashed all the time, and had the battery life of 75 minutes? An “MVP iPhone” could have turned people off from iPhones all together. Similarly, an MVP car that broke down every few miles would be a similarly poor experience.
The MPP is about convincing consumers or businesses that they need something they never thought they did and so inherent to that is making it a good enough product to dispel doubts.
An MPP can also be a late comer to the market. This is because while they are serving an existing market, they are also fulfilling preferences that are not currently met by the existing market. There existed plenty of vacuums before Dyson’s, but no product that was as well engineered with no loss of suction, a bagless design, a sturdy feel, and that looked nice aesthetically. Legacy vacuum companies didn’t know these things mattered, it turned out they did.
An MVP is about discovering preferences, whereas an MPP is about proving that consumers had an unrevealed preference.
Conclusion.
Science is a processes of testing hypotheses. You create a hypothesis and test it. But there is no way to know if a hypothesis is worth testing before testing it. Similar to mining for Bitcoin, you cannot know the solution to the SHA-256 hash function without actually computing it—there is no way to know the answer to the algorithm before calculating it.
Innovation is very similar.
You can create hypotheses about what preferences consumers have and create a product that tries to fulfill those, but your won’t know until you actually create that product.
If you are unsure if a consumer preference exists, then the MVP is like running a low-cost scientific experiment to probe to see if it does. You are answering the question, “what does the customer want?”.
If you know that a consumer preference exists, but the consumer doesn’t, then an MPP can prove to the consumer this unrevealed preference. You are answering a question that the consumer didn’t even know to ask.
The Synopsis Podcast.
Follow our Podcast below. We have four episode formats: “company” episodes that breakdown in-depth each business we write a report on, “dialogue” episodes that cover various business and investing topics, “article” episodes where we read our weekly memos, and “interviews”.
Speedwell Research Reports.
Become a Speedwell Research Member to receive all of our in-depth research reports, shorter exploratory reports, updates, and Members Plus also receive Excels.
(Many members have gotten their memberships expensed. If you need us to talk with your compliance department to become an approved vendor, please reach out at info@speedwellresearch.com).
Moving this from a twitter thread.
While the comparison of MVP with MPP is an interesting framing, it presents a false dichotomy. This analysis oversimplifies the complexities of product development by treating these approaches as strategic choices rather than what they often are: necessary adaptations to market realities and constraints.
Looking at the examples provide, one can clearly identify patterns.
MVP:
- Low distribution friction
- High iteration frequency
- Ability to update post-release
- Lower reputational risk on iterations
MMP:
- Hardware-dependent
- High per-unit costs
- Infrequent purchase cycles
- Limited post-release iteration capability
- High reputational stakes
AWS was used as an MPP example but this is a misclassification. Its development wasn't purely conceptual - it emerged from Amazon's internal needs, with extensive real-world testing through dogfooding. In other words, there were MVPs via internal customers.
The article mischaracterizes MVP as primarily about building what customers say they want. In reality, MVP is an approach to developing insights through experimentation - it's a learning process, not a product. Applied properly, you build what the customers didn't know they wanted but does the job they need.
Most importantly, companies can't freely choose between MVP and MPP - their market position and product type largely dictate their approaches.
Apple's reputation for quality and design excellence means their "minimum viable" threshold is naturally high. This isn't choosing MPP over MVP; it's setting a higher bar for what constitutes "viable."
Hardware products like vacuums or cars cannot be easily iterated post-release, and association with poor quality will impact subsequent sales. When each release carries high costs and risks, quality and design are front loaded. This isn't rejecting iteration; it's shifting it to pre-release phases, even though that implies higher level of initial investment and greater risk of loss.
This issue is more apparent if you look at different market positions and execution in the same industry. E.g. Hermès cannot adopt fast-fashion practices without undermining their brand positioning and market value - just as Zara cannot adopt Hermès's approach without destroying their business model.
As someone who has worked on building and launching a number of products, the MVP vs MPP framework isn't how things work in reality. What we're seeing is how different companies adapted their processes to their environment and its constraints.
The question facing builders and founders is rarely "should we choose MVP or MPP?". It's about developing a process for product development that optimizes the chance of success given your strengths, constraints, and market positioning.