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.
Thank you for being reader and we greatly appreciate your well thought-out commentary.
We are going to have to disagree on a few things though.
First though, I think the idea of framing iteration in terms of pre and post release is interesting. And I like the idea of reputational risk being an aspect as well.
The gist of your argument, as I understand it, is that this isn’t how people who actually build products think—and I agree with that. It’s a theoretical concept and real business isn’t theoretical. Many great entrepreneurs/ product developers figure things out for themselves, and it is only afterwards that we observe their actions and fit frameworks around those outcomes. This creates all sorts of biases (availability bias, selection bias, hindsight bias, etc.)
Having said that, I think certain concepts can be helpful. Clay Christensen’s “Jobs to be Done” framework is probably one of the best, but I have no doubt the vast majority of successful products were built without knowledge of it. Nevertheless, it seemed to help in specific cases like with his McDonald's example. It is true though that (good) entrepreneurs have a sense for business/ product development that has nothing to do with theories. (Copart’s Willis Johnson was able to conceive of and state the “jobs” idea independently, despite no business school education).
My general position on everything we write is that if it isn’t helpful or doesn’t resonate with someone they should ignore it. If an idea is good it will naturally find its own defenders, but it won’t be us.
To address just a few specific things you mentioned though:
MPPs don’t imply there were no protypes, iteration, or testing. Just that the public/ customers aren’t a part of that process. (As you noted, it is pre-release). Dyson famously went through 5,126 prototypes before arriving at the vacuum he later manufactured.
I don’t think MPPs are hardware dependent, nor require high incremental per unit costs (movies like Avatar or video games like Legend of Zelda: Ocarina of Time could be considered MPPs).
You can reframe Apple’s strategy as setting a “high bar of viability” under an MVP, but when you make that bar as high as possible (which is what Steve Jobs did essentially by asking for technologies that weren’t available at the time like scratch-resistant glass), it is the same idea of the MPP, just refined.
We call the MVP “a low-cost scientific experiment”. When we say it is about “building what customers say they want”, that is in regard to the feedback they are giving. Someone shows them a car and they ask them how to make it better. (This was the Henry Ford "Faster Horse" example). The Zappos example was to show that Nick Swinmurn didn’t know if the idea would work and had to test it.
I don’t disagree with you though that an MVP can find a solution to problem to and doesn’t require an MPP to “prove it”. Additionally, there are many products that are neither MVP nor MPP and exist somewhere on the spectrum of “workable” and “best that it can be”.
AWS was used as an MPP example because it was launched as a well working, highly-vetted product. They also knew the market was there because they themselves wanted to use it (much like Jobs designing the iPhone after how he wished a phone could operate). I don’t disagree that they did a lot of real world testing before launching it. (The retail operation wasn’t using it until many years after they launched though). If this isn’t the best example of an MPP you can ignore it.
To be clear, I responded originally on Twitter because I saw a VC getting excited about the idea of MPP, which I think does a disservice to founders and builders.
The core of my critique isn't that the description is wrong. Similar to critiques of Christensen's ideas, frameworks like this are often descriptive but not actionable. They're great for assigning a backward-looking narrative but don't work when one has to find a way forward.
A few clarifications:
1. I don't think MPP is hardware dependent. It's just a property of the examples presented, though hardware does reinforce characteristics like high unit cost and difficulty of updates. There are software examples too - autopilot systems, EHRs, telecommunication systems, etc.
2. Products with a high bar for "viability" absolutely involve prototyping and iteration. I've worked on EHRs, embedded systems, and telecom infrastructure - all required high bars before release and involved extensive prototyping. That's actually the point: the MPP concept confuses product release with MVP, which isn't a product but a process for rapidly gaining insights into customer needs.
3. Regarding AWS: Amazon was already a large organization when they developed it. Combined with Bezos's famous API-first mandate, they had enough internal customers to go through the MVP process.
Finally, if an idea is good, it should allow for intelligent discourse.
I’ll leave it there and would say that I enjoy your memos overall.
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.
Thank you for being reader and we greatly appreciate your well thought-out commentary.
We are going to have to disagree on a few things though.
First though, I think the idea of framing iteration in terms of pre and post release is interesting. And I like the idea of reputational risk being an aspect as well.
The gist of your argument, as I understand it, is that this isn’t how people who actually build products think—and I agree with that. It’s a theoretical concept and real business isn’t theoretical. Many great entrepreneurs/ product developers figure things out for themselves, and it is only afterwards that we observe their actions and fit frameworks around those outcomes. This creates all sorts of biases (availability bias, selection bias, hindsight bias, etc.)
Having said that, I think certain concepts can be helpful. Clay Christensen’s “Jobs to be Done” framework is probably one of the best, but I have no doubt the vast majority of successful products were built without knowledge of it. Nevertheless, it seemed to help in specific cases like with his McDonald's example. It is true though that (good) entrepreneurs have a sense for business/ product development that has nothing to do with theories. (Copart’s Willis Johnson was able to conceive of and state the “jobs” idea independently, despite no business school education).
My general position on everything we write is that if it isn’t helpful or doesn’t resonate with someone they should ignore it. If an idea is good it will naturally find its own defenders, but it won’t be us.
To address just a few specific things you mentioned though:
MPPs don’t imply there were no protypes, iteration, or testing. Just that the public/ customers aren’t a part of that process. (As you noted, it is pre-release). Dyson famously went through 5,126 prototypes before arriving at the vacuum he later manufactured.
I don’t think MPPs are hardware dependent, nor require high incremental per unit costs (movies like Avatar or video games like Legend of Zelda: Ocarina of Time could be considered MPPs).
You can reframe Apple’s strategy as setting a “high bar of viability” under an MVP, but when you make that bar as high as possible (which is what Steve Jobs did essentially by asking for technologies that weren’t available at the time like scratch-resistant glass), it is the same idea of the MPP, just refined.
We call the MVP “a low-cost scientific experiment”. When we say it is about “building what customers say they want”, that is in regard to the feedback they are giving. Someone shows them a car and they ask them how to make it better. (This was the Henry Ford "Faster Horse" example). The Zappos example was to show that Nick Swinmurn didn’t know if the idea would work and had to test it.
I don’t disagree with you though that an MVP can find a solution to problem to and doesn’t require an MPP to “prove it”. Additionally, there are many products that are neither MVP nor MPP and exist somewhere on the spectrum of “workable” and “best that it can be”.
AWS was used as an MPP example because it was launched as a well working, highly-vetted product. They also knew the market was there because they themselves wanted to use it (much like Jobs designing the iPhone after how he wished a phone could operate). I don’t disagree that they did a lot of real world testing before launching it. (The retail operation wasn’t using it until many years after they launched though). If this isn’t the best example of an MPP you can ignore it.
Thank you for sharing your thoughts!
To be clear, I responded originally on Twitter because I saw a VC getting excited about the idea of MPP, which I think does a disservice to founders and builders.
The core of my critique isn't that the description is wrong. Similar to critiques of Christensen's ideas, frameworks like this are often descriptive but not actionable. They're great for assigning a backward-looking narrative but don't work when one has to find a way forward.
A few clarifications:
1. I don't think MPP is hardware dependent. It's just a property of the examples presented, though hardware does reinforce characteristics like high unit cost and difficulty of updates. There are software examples too - autopilot systems, EHRs, telecommunication systems, etc.
2. Products with a high bar for "viability" absolutely involve prototyping and iteration. I've worked on EHRs, embedded systems, and telecom infrastructure - all required high bars before release and involved extensive prototyping. That's actually the point: the MPP concept confuses product release with MVP, which isn't a product but a process for rapidly gaining insights into customer needs.
3. Regarding AWS: Amazon was already a large organization when they developed it. Combined with Bezos's famous API-first mandate, they had enough internal customers to go through the MVP process.
Finally, if an idea is good, it should allow for intelligent discourse.
I’ll leave it there and would say that I enjoy your memos overall.