Minimal Viable Product is old and busted(michaeldehaan.substack.com)
michaeldehaan.substack.com
Minimal Viable Product is old and busted
https://michaeldehaan.substack.com/p/minimal-viable-product-is-old-and
131 comments
I came here to say this. The author of the article does not understand what an MVP is.
An MVP is the eventual answer to a metric fuckton of customer development, not what you go into customer development with.
If you think you already know what the customer wants, I wish you luck at your next startup after this one fails; you don’t know that, and neither does your customer, or they would have built / bought it already. It’s your job to find the real problems they’re facing, and then build a solution that makes them rip it out of your hands before it’s even done. then, iterate.
An MVP is the eventual answer to a metric fuckton of customer development, not what you go into customer development with.
If you think you already know what the customer wants, I wish you luck at your next startup after this one fails; you don’t know that, and neither does your customer, or they would have built / bought it already. It’s your job to find the real problems they’re facing, and then build a solution that makes them rip it out of your hands before it’s even done. then, iterate.
With Ansible, Mike already had a successful prototype (func) which had been developed and used by the Fedora infrastructure team for a while. He then left Red Hat and worked on Ansible. So he did in fact already know what the customer wanted! However that's an unusual case for a start-up. https://opensource.com/article/21/2/ansible-origin-story
Based on my experience func and ansible aren't very comparable and it's hard to call func a prototype for ansible. My recollection is that it was much more of a disruption to puppet, chef, and saltstack that had all become much more complicated and heavyweight by that time.
What I took away from this article is that an expert in that space (DeHaan) knew there was a gap and opportunity in this area, and the point of this article is that because he was able to capitalize on that opportunity because of his existing expertise and familiarity.
It's an interesting view compared to some interpretations of lean startups.
What I took away from this article is that an expert in that space (DeHaan) knew there was a gap and opportunity in this area, and the point of this article is that because he was able to capitalize on that opportunity because of his existing expertise and familiarity.
It's an interesting view compared to some interpretations of lean startups.
I think in that case you're not building a minimum viable product because that's already happened. The MVP was what Ansible was when the Fedora team were using it. When Mike left to form a company around the product it was much more than that - because there was already a really good understanding of what people would pay for.
Mike is also a great developer and infrastructure person so in a sense he is his own customer.
Some startups are created by experienced customers, and in these cases you often absolutely do know what the customer wants. Empirically, these can succeed without any significant customer development. Customer development becomes much more important if the startup lacks real domain and market expertise.
Also, while customer development might work well for web apps and such, there are classes of software where customers have no desire to interact with you until the product is almost fully baked. Trying to do customer development in these markets is often an exercise in futility. It is a different kind of process to arrive at an MVP, and in these cases it requires that the founders have strong domain and market expertise.
Also, while customer development might work well for web apps and such, there are classes of software where customers have no desire to interact with you until the product is almost fully baked. Trying to do customer development in these markets is often an exercise in futility. It is a different kind of process to arrive at an MVP, and in these cases it requires that the founders have strong domain and market expertise.
Customer development is always important. What constitutes an MVP may change, based on the industry or the customer, but the concept of talking to your customers regularly, understanding their problems, and iterating quickly doesn’t change.
As much as a founder would like to say they are the customer… they aren’t. They are a customer, and finding the commonalities amongst potential customers so you can build something they want is important. The founder being a customer just kickstarts that process and means the founder can ask better (aka “the right”) questions.
Which markets are you referring to? Gov requires customer dev, which is why there are often grants. Med requires customer dev, as building simply a better device rarely wins - it needs to be much better than existing solutions, and the only way you get there is by finding out what the problems are with existing solutions. Same goes for banking, etc
Domain and market expertise is always a benefit, but rarely a strict requirement for success. The ability to listen carefully, and iterate quickly, is much more important.
As much as a founder would like to say they are the customer… they aren’t. They are a customer, and finding the commonalities amongst potential customers so you can build something they want is important. The founder being a customer just kickstarts that process and means the founder can ask better (aka “the right”) questions.
Which markets are you referring to? Gov requires customer dev, which is why there are often grants. Med requires customer dev, as building simply a better device rarely wins - it needs to be much better than existing solutions, and the only way you get there is by finding out what the problems are with existing solutions. Same goes for banking, etc
Domain and market expertise is always a benefit, but rarely a strict requirement for success. The ability to listen carefully, and iterate quickly, is much more important.
I've worked on products where customer development was essential and also on products where it was largely useless for product development. You are assuming things about the product development process and customer interactions that are not always true. That doesn't imply that you don't talk to customers or don't understand their problems, just that this can be disconnected, often necessarily, from the product being developed.
As an example, hard tech products in data infrastructure often have this property. Famously, there are no incremental product outputs to show customers (or investors) as a matter of fundamental engineering; the product has to be almost fully baked before it can demonstrate anything of value at all. Customers have a difficult time understanding the implications of fundamentally new capabilities until they have time to play with them; they provide no useful feedback until the product has already reached a stage where this is possible (read: almost fully baked). And of course, there is no "iterate quickly" because the product value follows from architecture; if the architecture isn't correct the first time then iterating on the product means starting over from scratch. Consequently, the only people that can successfully build these products are people with serious expertise in the product and its use case. Even if you try to do customer development, there is nothing for the customer to engage with until you are well past the point where their feedback can materially change the product.
In these cases, no amounts of customer development will make up for a lack of deep domain and market expertise. The lean startup/MVP/customer development etc literature tacitly assumes that every product is an "app" of some type. If you work on software products that are not "apps" then you may find some of the advice to be misguided or useless.
As an example, hard tech products in data infrastructure often have this property. Famously, there are no incremental product outputs to show customers (or investors) as a matter of fundamental engineering; the product has to be almost fully baked before it can demonstrate anything of value at all. Customers have a difficult time understanding the implications of fundamentally new capabilities until they have time to play with them; they provide no useful feedback until the product has already reached a stage where this is possible (read: almost fully baked). And of course, there is no "iterate quickly" because the product value follows from architecture; if the architecture isn't correct the first time then iterating on the product means starting over from scratch. Consequently, the only people that can successfully build these products are people with serious expertise in the product and its use case. Even if you try to do customer development, there is nothing for the customer to engage with until you are well past the point where their feedback can materially change the product.
In these cases, no amounts of customer development will make up for a lack of deep domain and market expertise. The lean startup/MVP/customer development etc literature tacitly assumes that every product is an "app" of some type. If you work on software products that are not "apps" then you may find some of the advice to be misguided or useless.
See, I’m not convinced that’s true. Having built hard tech products before, there are plenty of places for iteration.
The catch is that you iterate the plan and architecture, before you write any significant code. In this case, it’s even more important to listen carefully to the customer and pay attention to the underlying problem.
For example, it may not have made sense to build Docker because “everyone uses VMs” and Vagrant was already a thing. But when talking to customers, they would have described ample problems with the existing approach - if you carefully listened, you could surmise that something like basic Linux containers would help, and you could provide a basic prototype of that to start. When they complain it lacks features, that’s okay, if and only if they still want to use it - THAT is the sign of PMF.
Want to build a new data warehouse? That’s hard, I agree - but the important part isn’t that it’s hard but why it’s better which is going to come from customer development. If listening to customers isn’t driving your product roadmap, you are literally guessing at what they need, and unless you’re Steve Jobs and your next product is the iPhone, you’re in for a rough time.
(And even the iPhone had plenty of customer dev; they interviewed thousands of people about their cell phones and surmised the solution wasn’t simply to build a better keyboard for a Palm Pilot, but to build a brand new device entirely, because people loved their phones but they had limited use. The Newton, on the other hand, had no market because people weren’t ready for it and it was built in a lab with no customers to talk to.)
The catch is that you iterate the plan and architecture, before you write any significant code. In this case, it’s even more important to listen carefully to the customer and pay attention to the underlying problem.
For example, it may not have made sense to build Docker because “everyone uses VMs” and Vagrant was already a thing. But when talking to customers, they would have described ample problems with the existing approach - if you carefully listened, you could surmise that something like basic Linux containers would help, and you could provide a basic prototype of that to start. When they complain it lacks features, that’s okay, if and only if they still want to use it - THAT is the sign of PMF.
Want to build a new data warehouse? That’s hard, I agree - but the important part isn’t that it’s hard but why it’s better which is going to come from customer development. If listening to customers isn’t driving your product roadmap, you are literally guessing at what they need, and unless you’re Steve Jobs and your next product is the iPhone, you’re in for a rough time.
(And even the iPhone had plenty of customer dev; they interviewed thousands of people about their cell phones and surmised the solution wasn’t simply to build a better keyboard for a Palm Pilot, but to build a brand new device entirely, because people loved their phones but they had limited use. The Newton, on the other hand, had no market because people weren’t ready for it and it was built in a lab with no customers to talk to.)
You are inadvertently reinforcing my point.
Customers do not have a mental model of the very complex theory that underpins the design of new kinds of data warehouses; they routinely ask for features and capabilities that are mutually exclusive or violate the laws of physics or computer science theorems if you ask them. There have been many attempts to "customer develop" a new kind of data warehouse, and the result is invariably naive architecture with too many deficiencies to be successful (basically the proverbial faster horse instead of a car).
In practice, the person building the product is usually a deep expert on the use cases for the product they are building in cases like new kinds of data warehouses. Indeed, there is the opposite problem that it is too customer and use case driven. Most such products fail due to insufficient expertise in the technical execution because the product was built by an expert user instead of an expert in the theory of building those types of systems, without a good understanding of the many subtle tradeoffs. If someone need to do customer development to understand why a new kind of data warehouse is better then they lack the deep technical expertise required execute ipso facto, since it trivially follows from low-level architecture.
Customers do not have a mental model of the very complex theory that underpins the design of new kinds of data warehouses; they routinely ask for features and capabilities that are mutually exclusive or violate the laws of physics or computer science theorems if you ask them. There have been many attempts to "customer develop" a new kind of data warehouse, and the result is invariably naive architecture with too many deficiencies to be successful (basically the proverbial faster horse instead of a car).
In practice, the person building the product is usually a deep expert on the use cases for the product they are building in cases like new kinds of data warehouses. Indeed, there is the opposite problem that it is too customer and use case driven. Most such products fail due to insufficient expertise in the technical execution because the product was built by an expert user instead of an expert in the theory of building those types of systems, without a good understanding of the many subtle tradeoffs. If someone need to do customer development to understand why a new kind of data warehouse is better then they lack the deep technical expertise required execute ipso facto, since it trivially follows from low-level architecture.
I think you’re missing mine. You don’t listen to the users’ feature requests; you listen to their problems and then devise solutions that solve a significant cross section of user issues.
Agreed, super super important to do customer dev.
What I haven't seen mentioned here is that if you do customer dev right, you get a leg up on sales.
One of the slickest founders I know would get conversations with his target customers to ask about their jobs + workflows. He'd learn from everyone but he kept note of the people who shared the same problem he was targeting. He now has a list of dozens of people who he has a relationship with who would make great first customers.
He didn't need to build a landing page or even a prototype in figma because he was just talking to people to learn about what they do.
What I haven't seen mentioned here is that if you do customer dev right, you get a leg up on sales.
One of the slickest founders I know would get conversations with his target customers to ask about their jobs + workflows. He'd learn from everyone but he kept note of the people who shared the same problem he was targeting. He now has a list of dozens of people who he has a relationship with who would make great first customers.
He didn't need to build a landing page or even a prototype in figma because he was just talking to people to learn about what they do.
Agreed.
The management of requirements in building anything needs to be structured properly to manage client expectations because it's often the first point of failure on development projects. MVP is a concept that is implemented on mission critical projects in order to insure a minimally acceptable point of project success, not to "be" project success... Anything else that can be added (within the implementation time frame) after base goals are met is a bonus.
Scope and schedule creep are 2 of the biggest threats to any major project, and it takes technical oversight just as much as managerial oversight... Technical Architects usually bridge this gap on projects.
An MVP is meant to be something that is generalized enough to fit KEY customer needs in a limited time frame, not ALL of the customer's needs, and customers inherently try to squeeze changes in during execution in large-scale projects. MVP for small-scale and startup projects may not mesh well, unless needs are well defined by an accountable customer.
An MVP is a contractual deliverable, so it shouldn't be delivered or even started before that contract is properly written and signed off.
Key aspects of a successful MVP -
It needs to be scale-able and mindful of future integrations and functionality.
It needs to be able to pivot and adjust to change, especially changes outside of your control (e.g. The Pandemic).
The data therein needs to maintain integrity and transfer-ability.
This is why experienced IT/Business architects are necessary on key projects. They incorporate business drivers, requirements, project management objectives, and technical teams into meaningful language, documentation, and project outcomes.
When you struggle on without an architect, projects suffer from a lack of direction, mixed communication, and often waste lots of money on back tracking solutions.
MVP is also a "version control" and project/client management concept/methodology, not a development language. The author broke down the title based on the words used. Taking time out to really investigate an understand why so many credible people use the term is a better move than declaring it obsolete.
The management of requirements in building anything needs to be structured properly to manage client expectations because it's often the first point of failure on development projects. MVP is a concept that is implemented on mission critical projects in order to insure a minimally acceptable point of project success, not to "be" project success... Anything else that can be added (within the implementation time frame) after base goals are met is a bonus.
Scope and schedule creep are 2 of the biggest threats to any major project, and it takes technical oversight just as much as managerial oversight... Technical Architects usually bridge this gap on projects.
An MVP is meant to be something that is generalized enough to fit KEY customer needs in a limited time frame, not ALL of the customer's needs, and customers inherently try to squeeze changes in during execution in large-scale projects. MVP for small-scale and startup projects may not mesh well, unless needs are well defined by an accountable customer.
An MVP is a contractual deliverable, so it shouldn't be delivered or even started before that contract is properly written and signed off.
Key aspects of a successful MVP -
It needs to be scale-able and mindful of future integrations and functionality.
It needs to be able to pivot and adjust to change, especially changes outside of your control (e.g. The Pandemic).
The data therein needs to maintain integrity and transfer-ability.
This is why experienced IT/Business architects are necessary on key projects. They incorporate business drivers, requirements, project management objectives, and technical teams into meaningful language, documentation, and project outcomes.
When you struggle on without an architect, projects suffer from a lack of direction, mixed communication, and often waste lots of money on back tracking solutions.
MVP is also a "version control" and project/client management concept/methodology, not a development language. The author broke down the title based on the words used. Taking time out to really investigate an understand why so many credible people use the term is a better move than declaring it obsolete.
"The author of the article does not understand what an MVP is" - it feels like that's not the case, based on their background? Reading the comments here, I see a lot of people with their own (and conflicting) ideas of what MVP is in the context of a startup. I also didn't get the idea from reading the article you are disagreeing with their point, and that they weren't opposing iterative learning.
It seems like a lot of YC companies are just drinking the MVP kool-aid. And there are 400 companies per batch now because they can just play the numbers game: throw them all at the wall and see who sticks.
It's a very interesting and nuanced distinction between:
"just build something and launch it as soon as possible"
...vs...
"think really hard about how to solve a particular problem in a novel way, then build the simplest possible solution that lets you iterate, but no simpler"
The most apt analogy for me has been multivariate optimization of a nonconvex function: the MVP is the initialization conditions. If you start near a local maximum then there is no way that hill-climbing (SGD, L-BFGS) will get you to a global maximum. So you need to make sure your starting point (MVP) lets you actually iterate to the global maximum through small local optimizations.
A product pivot is basically a random jump in the objective function hoping to get closer to a point where the function's gradient can lead you to a global maximum.
We did that with our product and thankfully the new initialization conditions are way better, and we are at a point where we can iterate to PMF. But there was no way we could have done that with our old product. (Here's the story of that pivot: https://parsnip.substack.com/p/a-new-hope)
It's a very interesting and nuanced distinction between:
"just build something and launch it as soon as possible"
...vs...
"think really hard about how to solve a particular problem in a novel way, then build the simplest possible solution that lets you iterate, but no simpler"
The most apt analogy for me has been multivariate optimization of a nonconvex function: the MVP is the initialization conditions. If you start near a local maximum then there is no way that hill-climbing (SGD, L-BFGS) will get you to a global maximum. So you need to make sure your starting point (MVP) lets you actually iterate to the global maximum through small local optimizations.
A product pivot is basically a random jump in the objective function hoping to get closer to a point where the function's gradient can lead you to a global maximum.
We did that with our product and thankfully the new initialization conditions are way better, and we are at a point where we can iterate to PMF. But there was no way we could have done that with our old product. (Here's the story of that pivot: https://parsnip.substack.com/p/a-new-hope)
The MVP strategy is entirely about validating your product. Unless you decide it has a good market fit, there is nothing in it telling you how to look for alternatives. There's nothing telling you to go by hill-climbing, or even by any gradient based search at all.
What it says is that once you find product-market fit, you don't destroy it by jumping around at random. But at this point, it's about disruption and the Innovator's Dilemma, where you are the incumbent. It's not about starting-up anymore.
What it says is that once you find product-market fit, you don't destroy it by jumping around at random. But at this point, it's about disruption and the Innovator's Dilemma, where you are the incumbent. It's not about starting-up anymore.
This is a great analogy, basically plotting startup success on an evolutionary NK landscape [0]. Finding optima rests on a healthy balance of exploration and exploitation, as in the behavior of ant colonies searching for food. Apple has been a good historical model of this in business, though for a startup it's often necessary to keep the chips all in on one product. Ideally though, a pivot isn't a random jump, but is rather guided by an incomplete map of the landscape. Herein lies the value of the MVP, but it's curse is being difficult to throw away, especially once it has some traction.
[0] https://en.wikipedia.org/wiki/NK_model
[0] https://en.wikipedia.org/wiki/NK_model
The other big reason for an MVP is to get from 'customers told us they want this' to 'customers are actually paying for this' as quickly as possible. All to often potential customers say they want X, but really have no idea what they want. The only surefire way to know if a product is on the right path is to have customers using and paying for the product.
All to often potential customers say they want X, but really have no idea what they want.
Or they actually do really want and need X _right now_. However when you come back with X in 18 month then the customer has already solved X themselves, found another company that can do X or don't really need X any more.
Or they actually do really want and need X _right now_. However when you come back with X in 18 month then the customer has already solved X themselves, found another company that can do X or don't really need X any more.
It’s quite rare that a customer knows exactly what they need; often, if they do, they build it.
The wins happen when a customer knows what problems they have, and you can present a solution that solves them better than they could otherwise get elsewhere.
Otherwise, as you say, they will build it or buy it elsewhere.
The wins happen when a customer knows what problems they have, and you can present a solution that solves them better than they could otherwise get elsewhere.
Otherwise, as you say, they will build it or buy it elsewhere.
I think there's some degree of nuance that isn't captured with comments like yours. I agree with your comment in principle, but there are interpretations of this method that are too extreme and that's where most of the bad MVPisms come from (and what I assume this blog post is a response to). As with any process, what most people are doing is not what was intended, and so we have to discuss what people are doing more so than the theory.
Data is only as valuable as the insight, understanding and intuition at the disposal of those gathering and actioning the data. There are organisations that truly embrace this idea of "we know nothing, the data will guide us" and they get lost because they're chasing a bunch of numbers for the sake of numbers on weak experiments that don't marry up to anything of meaning.
You need some amount of difficult-to-define "understanding" and "intuition" to be able to turn any learnings (whether gathered from experience or data) into a product: without it, you'll fail, regardless of process. There are many successful products that started out as someone absolutely committed to a belief in what is needed by the market, there are many successful products that were developed by following the data from day one, and likewise there are many unsuccessful products following both patterns.
My personal disdain for MVP-ing is exactly because it is so difficult to get right, and is very easy to get wrong, and it leaves little room for corrective action: I'm sure we all have experience with zombie startups, years old, still frantically "MVPing" everything under the sun. Personally, I'd much rather work within an organisation that has a clear vision about the problem they're trying to solve with flexibility around how it is to be solved, even if it ultimately leads to failure.
Customers lie, but so does data.
Data is only as valuable as the insight, understanding and intuition at the disposal of those gathering and actioning the data. There are organisations that truly embrace this idea of "we know nothing, the data will guide us" and they get lost because they're chasing a bunch of numbers for the sake of numbers on weak experiments that don't marry up to anything of meaning.
You need some amount of difficult-to-define "understanding" and "intuition" to be able to turn any learnings (whether gathered from experience or data) into a product: without it, you'll fail, regardless of process. There are many successful products that started out as someone absolutely committed to a belief in what is needed by the market, there are many successful products that were developed by following the data from day one, and likewise there are many unsuccessful products following both patterns.
My personal disdain for MVP-ing is exactly because it is so difficult to get right, and is very easy to get wrong, and it leaves little room for corrective action: I'm sure we all have experience with zombie startups, years old, still frantically "MVPing" everything under the sun. Personally, I'd much rather work within an organisation that has a clear vision about the problem they're trying to solve with flexibility around how it is to be solved, even if it ultimately leads to failure.
Customers lie, but so does data.
it leaves little room for corrective action
Building an MVP means getting something in front of customers as soon as possible, in order to test your product works for customers and change it if you're wrong. The entire point of an MVP is to give you as much time to change things as possible.
Everything you do prior to putting your product in front of someone might be wrong. The only validation that counts is the customer handing you their money. The longer you spend building before getting something out there the more expensive any mistakes might be. Consequently, making an MVP and only building the absolute minimum viable solution to a problem, give you as much correction time as possible.
I'd much rather work within an organisation that has a clear vision about the problem they're trying to solve with flexibility around how it is to be solved
We all would. The question is about how the org goes about getting clarity about the problem. If they think they fully understand it without talking to customers or putting something in front of customers in order to give the customer something to talk about, run the hell away. Those discussions will happen as soon as the customer sees something. If you've built a full product that you think is ideal, and then the customer doesn't agree, then you either lose the customer or you have to do a ton of work to change the product. Those are expensive mistakes that kill a startup. Having those conversations as early as possible is how you avoid that cost.
Building an MVP means getting something in front of customers as soon as possible, in order to test your product works for customers and change it if you're wrong. The entire point of an MVP is to give you as much time to change things as possible.
Everything you do prior to putting your product in front of someone might be wrong. The only validation that counts is the customer handing you their money. The longer you spend building before getting something out there the more expensive any mistakes might be. Consequently, making an MVP and only building the absolute minimum viable solution to a problem, give you as much correction time as possible.
I'd much rather work within an organisation that has a clear vision about the problem they're trying to solve with flexibility around how it is to be solved
We all would. The question is about how the org goes about getting clarity about the problem. If they think they fully understand it without talking to customers or putting something in front of customers in order to give the customer something to talk about, run the hell away. Those discussions will happen as soon as the customer sees something. If you've built a full product that you think is ideal, and then the customer doesn't agree, then you either lose the customer or you have to do a ton of work to change the product. Those are expensive mistakes that kill a startup. Having those conversations as early as possible is how you avoid that cost.
When I say there's little room for corrective action, I am specifically speaking about the choice to pursue the MVP strategy. A person who starts a company and decides to embrace the MVP strategy is stuck on a hamster wheel: if they've spent a year and not validated anything positively, they cannot "just" change strategy because the organisation has been built atop of the idea of small ideas, not big ideas.
My experience is that most businesses that pursue the MVP strategy never leave the MVP stage, regardless of the viability of the thing that originally inspired them, because they believe to MVP properly is to surrender all creativity, vision and intuition to numbers, which is in turn to surrender what's important when building anything.
No matter what strategy you choose, there has to be a meaningful amount of intuition and understanding to be able to make decisions: a purely data driven approach (with arbitrary goals like "someone paid us") is predicated on product development being entirely quantitative. Customers lie not just in what they say but also in what they do: getting a customer to pay is very easy compared to, say, building a sustainable business. People would have paid for faster horses!
People who espouse the success of the MVP strategy in their own businesses are often people with a level of creativity/intuition/understanding that most people do not have. MVP is a powerful tool in the right hands, absolutely, and I don't doubt that you're one such person, but MVP as a strategy for "normal" people has so many foot guns that I would never recommend it over a grand vision strategy. How many people are capable of picking the right customers to talk to? How many people are capable of understanding customer behaviour? How many people are capable of balancing outlier vs. representative behaviour?
I believe that normal people will have a higher chance of success by pursuing a vision than they would by following customer behaviour from the start.
My experience is that most businesses that pursue the MVP strategy never leave the MVP stage, regardless of the viability of the thing that originally inspired them, because they believe to MVP properly is to surrender all creativity, vision and intuition to numbers, which is in turn to surrender what's important when building anything.
No matter what strategy you choose, there has to be a meaningful amount of intuition and understanding to be able to make decisions: a purely data driven approach (with arbitrary goals like "someone paid us") is predicated on product development being entirely quantitative. Customers lie not just in what they say but also in what they do: getting a customer to pay is very easy compared to, say, building a sustainable business. People would have paid for faster horses!
People who espouse the success of the MVP strategy in their own businesses are often people with a level of creativity/intuition/understanding that most people do not have. MVP is a powerful tool in the right hands, absolutely, and I don't doubt that you're one such person, but MVP as a strategy for "normal" people has so many foot guns that I would never recommend it over a grand vision strategy. How many people are capable of picking the right customers to talk to? How many people are capable of understanding customer behaviour? How many people are capable of balancing outlier vs. representative behaviour?
I believe that normal people will have a higher chance of success by pursuing a vision than they would by following customer behaviour from the start.
You're expecting normal people to successfully invent the car? I have much more faith in them forming a relationship with a paying customer, and offering a small process improvement through a MVP.
An MVP will also help with appropriately market timing of your product. If the client is asking for a faster horse, you might want to look at innovating the saddle or horseshoe first. You might be 1000 years too early with your car engine idea.
An MVP will also help with appropriately market timing of your product. If the client is asking for a faster horse, you might want to look at innovating the saddle or horseshoe first. You might be 1000 years too early with your car engine idea.
> The only validation that counts is the customer handing you their money.
TLDR; of this whole thread.
I wrote something similar in a direct response to your first comment while you were writing this one :)
TLDR; of this whole thread.
I wrote something similar in a direct response to your first comment while you were writing this one :)
> it leaves little room for corrective action
The entire idea of MVPs is to leave as much room for corrective action as possible.
It doesn't happen often, but when it happens it really annoying that society is so reluctant to embrace an idea that people won't even acknowledge that the idea exists. If you name it, they will change the word meaning to the opposite of the thing you named. If you show it by example, they will completely ignore your idea on the example, and only ever accept irrelevant details.
We are seeing an example here, with MVPs. People really dislike anything lean and anything scientific. Merge the two ideas and you have a sure mind-repellent.
The entire idea of MVPs is to leave as much room for corrective action as possible.
It doesn't happen often, but when it happens it really annoying that society is so reluctant to embrace an idea that people won't even acknowledge that the idea exists. If you name it, they will change the word meaning to the opposite of the thing you named. If you show it by example, they will completely ignore your idea on the example, and only ever accept irrelevant details.
We are seeing an example here, with MVPs. People really dislike anything lean and anything scientific. Merge the two ideas and you have a sure mind-repellent.
>My personal disdain for MVP-ing is [...], and it leaves little room for corrective action
The "corrective action" is actually embedded into the MVP / Lean Startup terminology popularized by Eric Reis: https://www.slideshare.net/startuplessonslearned/minimum-via...
It's just the that acronym wasn't longer such as MVPI (Minimum Viable Product Iteration) or MVPLL ((Minimum Viable Product Learning Loop).
>Customers lie, but so does data.
The "data" in the MVP iteration framework doesn't lie because the relevant data is "paying customers". Either the startup has growing revenue from its product or it doesn't.
The "corrective action" is actually embedded into the MVP / Lean Startup terminology popularized by Eric Reis: https://www.slideshare.net/startuplessonslearned/minimum-via...
It's just the that acronym wasn't longer such as MVPI (Minimum Viable Product Iteration) or MVPLL ((Minimum Viable Product Learning Loop).
>Customers lie, but so does data.
The "data" in the MVP iteration framework doesn't lie because the relevant data is "paying customers". Either the startup has growing revenue from its product or it doesn't.
In your story you thought you knew what to build, but didn't.
The "MVP" theory is that the MVP is part of validating that you really know what to build, as you say.
OP author disagrees. (I'm not sure OP author says anything about when you "start selling" exactly).
Clearly a lot more can be said about how you know what to build if not an "MVP" approach. OP suggests a few things: "cultivated instinct" (which as a phrase alone isn't too useful, how do you get it?); Spending a lot of time talking to potential customers, and not necessarily taking what they say at face value but "averaging" it, and mixing with that "cultivated instinct"; and maybe most specifically/operationalizable -- spend some time working in the industry/market before starting the company at all, so you've seen "how 5 other companies have built something and know all the things that they’ve done wrong, and it will be a lot easier."
"Domain expertise" might be the main thing he's talking about, arguing agianst the idea that you can start a company without somebody involved having significant domain expertise/experience in the industry, but instead develop that market knowledge as you go, through an "MVP" approach.
I'm curious how those ideas relate to your company, how much industry/domain experience you had before starting the company.
The "MVP" theory is that the MVP is part of validating that you really know what to build, as you say.
OP author disagrees. (I'm not sure OP author says anything about when you "start selling" exactly).
Clearly a lot more can be said about how you know what to build if not an "MVP" approach. OP suggests a few things: "cultivated instinct" (which as a phrase alone isn't too useful, how do you get it?); Spending a lot of time talking to potential customers, and not necessarily taking what they say at face value but "averaging" it, and mixing with that "cultivated instinct"; and maybe most specifically/operationalizable -- spend some time working in the industry/market before starting the company at all, so you've seen "how 5 other companies have built something and know all the things that they’ve done wrong, and it will be a lot easier."
"Domain expertise" might be the main thing he's talking about, arguing agianst the idea that you can start a company without somebody involved having significant domain expertise/experience in the industry, but instead develop that market knowledge as you go, through an "MVP" approach.
I'm curious how those ideas relate to your company, how much industry/domain experience you had before starting the company.
>> "Domain expertise" might be the main thing he's talking about
This is clearly what he is talking about. When he is talking about his experience with the "Senior Design project course in Computer Science at my alma mater" he is really talking about how people can "MVP their way into getting domain expertise" at some level. This is a fundamental problem with the "startup industry".
Groups of people from a computing (I want to be broader than CS) that have reasonably strong technical skills and a lot of enthusiasm for applying those skills want to build successful startups. They generally lack domain expertise outside of technology-adjacent products for the most part. It's not completely absent because there is some success, but there isn't a balance for the most part.
Where does the domain expertise come from then? It could come from a slow development process involving the founders immersing themselves in the area. That's really only something that's going to be feasible before the founders create the company. Once the company has been founded, it becomes a scramble to interpret some ideas and build an MVP that can be sold to some of the advisors that the founders could get time with. It's only now that the foundational work is happening. If the right people see the MVP, or the founders make the right connections, it's possible to catapult forward from here, but it's a predictable failure point.
This is clearly what he is talking about. When he is talking about his experience with the "Senior Design project course in Computer Science at my alma mater" he is really talking about how people can "MVP their way into getting domain expertise" at some level. This is a fundamental problem with the "startup industry".
Groups of people from a computing (I want to be broader than CS) that have reasonably strong technical skills and a lot of enthusiasm for applying those skills want to build successful startups. They generally lack domain expertise outside of technology-adjacent products for the most part. It's not completely absent because there is some success, but there isn't a balance for the most part.
Where does the domain expertise come from then? It could come from a slow development process involving the founders immersing themselves in the area. That's really only something that's going to be feasible before the founders create the company. Once the company has been founded, it becomes a scramble to interpret some ideas and build an MVP that can be sold to some of the advisors that the founders could get time with. It's only now that the foundational work is happening. If the right people see the MVP, or the founders make the right connections, it's possible to catapult forward from here, but it's a predictable failure point.
[deleted]
Bit of an arrogant and directionless rant with no concrete detail and many false dichotomies. "Just build the right product" is like saying "just don't write bugs" or "just have money." It feels like DeHaan is reacting to the idea of exploration because he thinks you should just know everything to begin with.
Knowing everything upfront is definitely better than exploring your domain, product and market incrementally. The problem is that this rarely happens in practice. Founders who adopt DeHaan's attitude and think they can leapfrog the exploratory phase of their startup usually end up failing.
Knowing everything upfront is definitely better than exploring your domain, product and market incrementally. The problem is that this rarely happens in practice. Founders who adopt DeHaan's attitude and think they can leapfrog the exploratory phase of their startup usually end up failing.
This wasn't what I got out of the article.
Too many people focus on the Minimum, and don't care about the Viable or the Product. There are table stakes. MVP doesn't mean half-assed and buggy. They misuse the concept and release any old crap.
As a result, MVP has become too much of a buzzword and the intention behind it got lost.
Too many people focus on the Minimum, and don't care about the Viable or the Product. There are table stakes. MVP doesn't mean half-assed and buggy. They misuse the concept and release any old crap.
As a result, MVP has become too much of a buzzword and the intention behind it got lost.
The author speaks as if 'minimum', 'viable', 'product' are a Venn diagram rather than 2 adjectives and a noun, which muddies their point a bit. The Venn diagram version that people use is often feasible (can it be built), viable (will it sell), desirable (do people want to use it), which would've made their point clearer.
I think the trouble with MVP is that what we consider the "minimum that's viable" has changed — if you look at early days of Twitter for example (both its UI and the frequent 'fail whale' outages), it wouldn't pass muster today but at the time was enough to become one of the main platforms of the web.
Nowadays, you'd need a much more polished MVP in order to compete because the standard of what end-users expect has risen a lot (both in terms of functionality & NFRs, like security, robustness, interop, etc.).
I think the trouble with MVP is that what we consider the "minimum that's viable" has changed — if you look at early days of Twitter for example (both its UI and the frequent 'fail whale' outages), it wouldn't pass muster today but at the time was enough to become one of the main platforms of the web.
Nowadays, you'd need a much more polished MVP in order to compete because the standard of what end-users expect has risen a lot (both in terms of functionality & NFRs, like security, robustness, interop, etc.).
I agree that this is what I drew out of it. You can't hand wave away some pieces of the product as 'minimal' if they are directly applicable to the basic use case. I've been the audience that has to say 'great but the fact that this doesn't allow more than 20 things is a complete non-starter' constantly. You then wait for the next iteration and these critical changes aren't even talked about, and so you just give up on them and start working with the next vendor. Another variant I see often too is something that 'creates a job title' at the customer where their product is so much of a ongoing headache that you end up needing a FTE or department just to manage the thing. It is often quite apparent from the visible product where you ask about things like 'how does the system alert if there is a problem' or 'how do we know your agents are connecting' is a TODO item that says 'we defer to YOUR infrastructure' instead of having a plan that works through the whole system well.
I don't mind that people try to setup a minimal product or have people to be self-inserted to do the work that is planned to be automated later on the service company's side, but if your answer to the question 'if we use this product we'll have 1000 artifacts to configure, how do we do this efficiently' is 'you have to go one by one and we'll implement it later' on a product/service that clearly is going to have 1000's of things is just junky and not minimal at all.
EDIT: also don't be that person who says 'well you can do that with the API!' when you in fact can't do it through the API and/or it is the exact same level of clunkiness as the UI.
I don't mind that people try to setup a minimal product or have people to be self-inserted to do the work that is planned to be automated later on the service company's side, but if your answer to the question 'if we use this product we'll have 1000 artifacts to configure, how do we do this efficiently' is 'you have to go one by one and we'll implement it later' on a product/service that clearly is going to have 1000's of things is just junky and not minimal at all.
EDIT: also don't be that person who says 'well you can do that with the API!' when you in fact can't do it through the API and/or it is the exact same level of clunkiness as the UI.
That doesn't mean the MVP is a bad idea, then. That means it's being poorly implemented.
If an idea is routinely implemented badly, then it is a bad idea to implement it at all.
I have an intuition that there are multiple classes of ideas:
ideas that are linear interpolation of the present into the future: Those are intuitive, either for domain experts or the general public. A little voice that says "Next we do this..."
ideas that form a gravitational force: these are ideas that pull many, uncoordinated efforts. It is a bit hard to describe, but I think of this as ideas that are "necessary" in a grander emergence that needs the ideas to cement its existence.
Ideas that are not ready to be hatched: "the too early" class. Sometimes because a missing ingredient has not been identified or not sufficiently widely available. When those ideas fail, and a decade or so later new thinkers think them again and realise they failed, sometimes they go back and figure out the prerequisites weren't there and now they are or they build the prerequisites themselves.
Ideas that are non linear: those are the rarest to come by. I believe they require extreme tolerance for counter-factual thinking either naturally or otherwise-inhibition-reducing aids.
ideas that form a gravitational force: these are ideas that pull many, uncoordinated efforts. It is a bit hard to describe, but I think of this as ideas that are "necessary" in a grander emergence that needs the ideas to cement its existence.
Ideas that are not ready to be hatched: "the too early" class. Sometimes because a missing ingredient has not been identified or not sufficiently widely available. When those ideas fail, and a decade or so later new thinkers think them again and realise they failed, sometimes they go back and figure out the prerequisites weren't there and now they are or they build the prerequisites themselves.
Ideas that are non linear: those are the rarest to come by. I believe they require extreme tolerance for counter-factual thinking either naturally or otherwise-inhibition-reducing aids.
I don't think such an absolutism holds water: great ideas don't exist in vacuums. There is no magic bullet which makes startups successful: lots of things, big and small, need to come together to make it. I think the article touches on several failings which aren't actually the fault of mvps at all.
For reference, from the article
> An example of non-viability or non-productness is if you want to have a business, but you’re not quite positive what you should build or sell. This is no good as the product and the desire to help your customer, rather than to just “have a business”, should be your soul.
Reading that and your answer back to back, I think you have a better view than the author of what an MVP should be.
The piece is all over the place, and paradoxically might work better for people who already have a good idea of what it should be about, fill the gaps with their own wisdom and ignore the part that make no sense otherwise.
> An example of non-viability or non-productness is if you want to have a business, but you’re not quite positive what you should build or sell. This is no good as the product and the desire to help your customer, rather than to just “have a business”, should be your soul.
Reading that and your answer back to back, I think you have a better view than the author of what an MVP should be.
The piece is all over the place, and paradoxically might work better for people who already have a good idea of what it should be about, fill the gaps with their own wisdom and ignore the part that make no sense otherwise.
I also did not get this from the OP article. I would say he could have articulated things better.
It is imperative to note that what constitutes minimum and viable had generally changed since 2010.
We should also keep in mind that those terms are relative terms, depending on the domain.
For me, I think one should know a lot or experienced personally the problem(domain expertise) and be open to the form of the solution(the product). For practical reasons, if nothing else, learning any sufficiently complex domain while trying to build a business is expensive.
It is imperative to note that what constitutes minimum and viable had generally changed since 2010.
We should also keep in mind that those terms are relative terms, depending on the domain.
For me, I think one should know a lot or experienced personally the problem(domain expertise) and be open to the form of the solution(the product). For practical reasons, if nothing else, learning any sufficiently complex domain while trying to build a business is expensive.
This article then serves to increase the misunderstanding, rather than just clarifying what it should mean. Conflating idea and implementation is not good.
"just have money" - this is my new mantra.
That was my takeaway too. MVPs help you understand what the product should be. Helps you escape chicken/egg situations.
> An example of too much minimalism would be failing to implement UI pagination and your UI falling over with more than 20 objects, because you didn’t think about the use case. Maybe you haven’t thought about scale-out or upgrades or you can install on only one operating system. A serious buyer can sniff out this incompleteness and won’t take you seriously, and only serious domain experience can fill in these gaps. You can’t expect your buyer to be like “hey, nice try with this prototype but I can tell this won’t scale to more than 20 objects”. They are looking to you to be the expert.
IME this part is completely wrong, unless it's defining "serious buyer" in such a way that most of your market isn't one.
> Time is short, funding is short (especially if you are running on your own money), and you don’t want to waste time.
> Your company shouldn’t be in search of a business model, you should know what you need to build. Wait until you see the exact right thing, because you are about to put too much of your lifeforce into it, and if you don’t, you have a much harder road ahead. You want to know it will work, and this requires cultivated instinct. When the time is right and you know enough, that’s when you decide to have a product.
Ok so what is the author advocating doing until then? Sitting around twiddling your thumbs until inspiration strikes?
The whole point of the MVP is: build just enough to find out whether this is a viable business or not. And nothing in the article seems to be contrary to that. It's a whole lot of words but the only advice seems to be to have better instincts (how?) and just make a better product bro.
IME this part is completely wrong, unless it's defining "serious buyer" in such a way that most of your market isn't one.
> Time is short, funding is short (especially if you are running on your own money), and you don’t want to waste time.
> Your company shouldn’t be in search of a business model, you should know what you need to build. Wait until you see the exact right thing, because you are about to put too much of your lifeforce into it, and if you don’t, you have a much harder road ahead. You want to know it will work, and this requires cultivated instinct. When the time is right and you know enough, that’s when you decide to have a product.
Ok so what is the author advocating doing until then? Sitting around twiddling your thumbs until inspiration strikes?
The whole point of the MVP is: build just enough to find out whether this is a viable business or not. And nothing in the article seems to be contrary to that. It's a whole lot of words but the only advice seems to be to have better instincts (how?) and just make a better product bro.
> IME this part is completely wrong, unless it's defining "serious buyer" in such a way that most of your market isn't one.
I used to be such a "serious buyer". I represented a large government agency with over 2,000 sites and several hundred thousand employees.
Vendors would turn up with "cute" web apps that used drop downs to select objects like security groups or user accounts. This works great when you're developing in a toy environment in your dev lab.
In the real world, merely clicking something like that will make both the server and client use gigabytes of memory until either one or both crash.
Here's the thing though: if you can put just a modicum of engineering effort into making your software suitable for non-toy scenarios, then winning even just one enterprise customer like this could make your rich. Win two or three similar orgs in other states or countries and you can start subscribing to Superyacht Owners' Quarterly.
But there will be no yacht because you used a drop-down. A simple control that can be implemented in minutes instead of a search box that takes a few extra lines of code.
Sorry...
PS: On a more serious note, I had a checklist that wasn't long or all that difficult to implement, and 90% of vendors would fail outright on most/all points.
I used to be such a "serious buyer". I represented a large government agency with over 2,000 sites and several hundred thousand employees.
Vendors would turn up with "cute" web apps that used drop downs to select objects like security groups or user accounts. This works great when you're developing in a toy environment in your dev lab.
In the real world, merely clicking something like that will make both the server and client use gigabytes of memory until either one or both crash.
Here's the thing though: if you can put just a modicum of engineering effort into making your software suitable for non-toy scenarios, then winning even just one enterprise customer like this could make your rich. Win two or three similar orgs in other states or countries and you can start subscribing to Superyacht Owners' Quarterly.
But there will be no yacht because you used a drop-down. A simple control that can be implemented in minutes instead of a search box that takes a few extra lines of code.
Sorry...
PS: On a more serious note, I had a checklist that wasn't long or all that difficult to implement, and 90% of vendors would fail outright on most/all points.
1. Search-for-select
2. A provisioning API of some sort (REST, PowerShell, whatever)
3. Hierarchical permissions & delegation
4. Hierarchical policy & preferences
5. Single-sign-on support
6. Central audit & error logging
7. Clone-to-deploy and/or highly automated setup.
8. Don't demand Domain Admin rights for setup.
9. No quadratic (or worse) scaling issues. (USE INDEXES in the DB!!)> merely clicking something like that will make both the server and client use gigabytes of memory until either one or both crash
Curious as to how clicking on an UI object would consume gigabytes of memory, both in frontend and backend?
Curious as to how clicking on an UI object would consume gigabytes of memory, both in frontend and backend?
For large organisations the amount of entries in the dropdown is probably very large. To fill the dropdown would then require significant work on the server, and to build up and show the dropdown would require significant work on the client.
Edit, of course a proper solution would be well-thought out and would not crash, but that solution would also not be using a single dropdown to show all possible values because that is not usable when it is more than 20 entries.
Edit, of course a proper solution would be well-thought out and would not crash, but that solution would also not be using a single dropdown to show all possible values because that is not usable when it is more than 20 entries.
Modern backends and frontends can surely handle way more than 20 entries in a dropdown without sweating.
But in case you do have a LOT of entries that modern hardware cannot handle efficiently, just switch to a selector based on a search box (perhaps with autocomplete), instead of a dropdown.
Since it's an easy modification in the UI, perhaps these startups used a dropdown for simplicity, knowing they can change to a selector search box quickly, if it becomes an issue.
But in case you do have a LOT of entries that modern hardware cannot handle efficiently, just switch to a selector based on a search box (perhaps with autocomplete), instead of a dropdown.
Since it's an easy modification in the UI, perhaps these startups used a dropdown for simplicity, knowing they can change to a selector search box quickly, if it becomes an issue.
> Modern backends and frontends can surely handle way more than 20 entries in a dropdown without sweating.
I agree. I meant that I as a user will not find it usable enough if I often have to search the correct value in lists of 20 or more.
The discussion of the load on the frontend and backend was about amounts large enough to create problems if the developer wrote naive code, but we did not get in to a specific amount.
I agree. I meant that I as a user will not find it usable enough if I often have to search the correct value in lists of 20 or more.
The discussion of the load on the frontend and backend was about amounts large enough to create problems if the developer wrote naive code, but we did not get in to a specific amount.
because toy apps that use dropdowns like the OP mentioned will do a "SELECT * FROM security_groups" at the backend (requiring RAM for the whole thing to format the response) and then send it down to the frontend which will then spend eternities formatting the list in the DOM as a complete UL/LI of objects that will blow up the front end.
Drop-downs for unconstrained lists are just flat wrong, they become unusable at a mere few hundred entries. Even with just a few thousand, you'll see only a tiny subset of accounts/groups/objects and it'll look like this:
I would do the "look at the server RAM disappear like a magic trick! ...and now the whole server is gone!" demo to really drive the point home, but that happens around the 200K-1M object level (depending on the software).
About 50% of the time there would be a senior developer there who would just slowly blink at me and suggest the "solution" of cutting down the directory to a more manageable size, like 50 users.
Like... yeah buddy. We'll just delete 99.975% of the user accounts in the directory system because you learned programming from a "4 Dummies" book.
AADEN
AADIT
AADVIK
AAIDEN
AARAV
AARIZ
AARON
AARUSH
AARYAN
AAYAN
AAYDEN
ABDEL
ABDIEL
ABDUL
ABDULLAH
...
I would do the "look at the server RAM disappear like a magic trick! ...and now the whole server is gone!" demo to really drive the point home, but that happens around the 200K-1M object level (depending on the software).
About 50% of the time there would be a senior developer there who would just slowly blink at me and suggest the "solution" of cutting down the directory to a more manageable size, like 50 users.
Like... yeah buddy. We'll just delete 99.975% of the user accounts in the directory system because you learned programming from a "4 Dummies" book.
Sure, you can roll the dice on a handful of big organisational buyers, and you may find that good engineering is what they're after. But there's a whole lot of politics (organisational and other), relationships, and other stuff in play; having a heavily engineered product is not remotely a guarantee of winning that kind of contract.
These 9 bullet points are far from "not difficult to implement" though.
Well, 2 of them are hard, the others are the kind of thing you get if you let a developer take a week or two to solve them at the beginning, but almost impossible to create after the system is built.
So, 3 months of up-front work. It very likely won't break any project/company, but it's enough of a drag that most people will say "fuck it" and not target large enterprises. And, well, there are plenty of other reasons not to target enterprises that the GP isn't talking about, so it may be a good choice.
So, 3 months of up-front work. It very likely won't break any project/company, but it's enough of a drag that most people will say "fuck it" and not target large enterprises. And, well, there are plenty of other reasons not to target enterprises that the GP isn't talking about, so it may be a good choice.
Having worked at a large enterprise I agree that there are many good reasons not to target 'us'. However far too many companies are rocking up to sales meetings with large enterprises and have no idea about their actual needs and the scale and problems of selling to large enterprises.
Having also sold to large enterprises, you have to be willing to sometimes spend 3-6 month developing a really obscure feature that will only be used by that one customer to get the sale.
Having also sold to large enterprises, you have to be willing to sometimes spend 3-6 month developing a really obscure feature that will only be used by that one customer to get the sale.
Well, you ain't getting that 7+ figure contract for just building easy stuff either.
Exactly. Their advice essentially is – don't build an MVP, instead have a perfect working product with all features and a perfect market fit and huge demand with an years-long rigid roadmap on day one. Like...okay? And how do you do all this exactly?
I think this is a bit of a misread of what MVP means. It's not a prototype or a way to search for the right product to build. It's prioritising the minimum set of features to launch a viable product.
That pretty obviously implies that you already know what to build, at least roughly, so that thinking has been done. If you need more than 20 objects and pagination, then that's part of the V in MVP.
The difference is that you don't spend 2 years on 100 features you think people will want (or even, people tell you they want) - you boil that research down to 15 features that can work together as a product that you've defined will be useful, and then build the next set of features on top that will allow you to access more of the market, partly based on what you learned from the previous iteration, etc etc.
You may still spend 2 years building (and you should definitely carve out budget assuming that) and you may still build 100 features, but you launched much earlier to get information, and you may have built 30 features differently due to the extra information you got, and you'll have got a pretty battle-tested product into the market by the end of the two years.
You probably know all this. I'm restating because I read so many articles that confuse an idea with observed (or anecdotal) bad implementations, and this seems to do the same thing.
That pretty obviously implies that you already know what to build, at least roughly, so that thinking has been done. If you need more than 20 objects and pagination, then that's part of the V in MVP.
The difference is that you don't spend 2 years on 100 features you think people will want (or even, people tell you they want) - you boil that research down to 15 features that can work together as a product that you've defined will be useful, and then build the next set of features on top that will allow you to access more of the market, partly based on what you learned from the previous iteration, etc etc.
You may still spend 2 years building (and you should definitely carve out budget assuming that) and you may still build 100 features, but you launched much earlier to get information, and you may have built 30 features differently due to the extra information you got, and you'll have got a pretty battle-tested product into the market by the end of the two years.
You probably know all this. I'm restating because I read so many articles that confuse an idea with observed (or anecdotal) bad implementations, and this seems to do the same thing.
I think there’s two kinds of MVP in common use and they’re both valid tools in specific situations.
In Lean Startup, Eric Ries argues that if your business has giant unknowns. Big leap of faith assumptions. Then you’re best off using the scientific process to validate those unknowns before you do anything else. Start with a theory, design experiments and analyse the results. Repeat.
The MVP is the experiment. It’s a pity that he didn’t call it “quickest experiment”, because that’s what a Lean Startup MVP is, just the quickest experiment you can use to validate your businesses assumptions. And how can using a “quickest experiment” be old and broken? It’s a perfectly valid approach sometimes.
The other common use of the term MVP is to ruthlessly cull a products features before the first release. To find the MINIMUM PRODUCT that would be VIABLE. People use the term that way because that’s what it sounds like an MVP would be. And again… it’s a perfectly valid approach. How could it be old and broken to pragmatically limit the scope of a first release to the minimum set of features that users find viable so that you can keep as much time as possible for responding to change.
Anyway, I think the two kinds of MVPs are still good tools in the right hands when used in the right situations. I’d hate to throw away good tools just because they don’t work in every possible situation.
In Lean Startup, Eric Ries argues that if your business has giant unknowns. Big leap of faith assumptions. Then you’re best off using the scientific process to validate those unknowns before you do anything else. Start with a theory, design experiments and analyse the results. Repeat.
The MVP is the experiment. It’s a pity that he didn’t call it “quickest experiment”, because that’s what a Lean Startup MVP is, just the quickest experiment you can use to validate your businesses assumptions. And how can using a “quickest experiment” be old and broken? It’s a perfectly valid approach sometimes.
The other common use of the term MVP is to ruthlessly cull a products features before the first release. To find the MINIMUM PRODUCT that would be VIABLE. People use the term that way because that’s what it sounds like an MVP would be. And again… it’s a perfectly valid approach. How could it be old and broken to pragmatically limit the scope of a first release to the minimum set of features that users find viable so that you can keep as much time as possible for responding to change.
Anyway, I think the two kinds of MVPs are still good tools in the right hands when used in the right situations. I’d hate to throw away good tools just because they don’t work in every possible situation.
> And again… it’s a perfectly valid approach.
It's a valid approach in certain markets.
But if you're FAANG and launch that sort of MVP going against mature products from your competitors, often replacing a more feature complete product with an existing user base that you try to port over... well, you're going to get destroyed. As keeps happening to Google because they don't seem to realise that the market has moved on and you can't launch things like Gmail any more.
It's a valid approach in certain markets.
But if you're FAANG and launch that sort of MVP going against mature products from your competitors, often replacing a more feature complete product with an existing user base that you try to port over... well, you're going to get destroyed. As keeps happening to Google because they don't seem to realise that the market has moved on and you can't launch things like Gmail any more.
> But if you're FAANG and launch that sort of MVP going against mature products from your competitors, often replacing a more feature complete product with an existing user base that you try to port over... well, you're going to get destroyed.
I think what you're describing though is if you cull too many features, i.e. if you try to launch _below_ the minimum that's viable for your product-market fit, you'll always get destroyed.
You get some more leeway if you're the only offering in a problem space, but going up against incumbents really raises the bar of what the viable minimum is.
That said, you _can_ offer less features but a better execution — e.g. there's a lot of challenge banks (Monzo, Revolut, Starling, etc.) doing well in the UK at the moment (in the sense of customer acquisition, at least).
I remember when they were applying for their banking licences, a lot of people working in traditional fintech were saying that they'd be a flash in the pan & that customers wouldn't switch to these new businesses until they had parity in terms of offering things like loans and mortgages. But the offering of trad banks was _so bad_ that people were willing to overlook a lot of missing features for a better UX on their day-to-day banking.
I think what you're describing though is if you cull too many features, i.e. if you try to launch _below_ the minimum that's viable for your product-market fit, you'll always get destroyed.
You get some more leeway if you're the only offering in a problem space, but going up against incumbents really raises the bar of what the viable minimum is.
That said, you _can_ offer less features but a better execution — e.g. there's a lot of challenge banks (Monzo, Revolut, Starling, etc.) doing well in the UK at the moment (in the sense of customer acquisition, at least).
I remember when they were applying for their banking licences, a lot of people working in traditional fintech were saying that they'd be a flash in the pan & that customers wouldn't switch to these new businesses until they had parity in terms of offering things like loans and mortgages. But the offering of trad banks was _so bad_ that people were willing to overlook a lot of missing features for a better UX on their day-to-day banking.
Yeah I think we actually agree, that’s why I said it’s a valid approach “sometimes”.
Like any tool, Lean Startup MVPs aren’t the right tool for every situation. You need extreme uncertainty.
If you’re a FAANG and you’re releasing a new version of a well established type of product like an email client, what giant existential risks do you have? FAANG have existing customers, we all know people use email. There’s no questions to answer, no uncertainty, so MVPs are the wrong tool for the job.
Why bother running experiments if we have 20 years of data showing us that we have customers and they like using email…
Like any tool, Lean Startup MVPs aren’t the right tool for every situation. You need extreme uncertainty.
If you’re a FAANG and you’re releasing a new version of a well established type of product like an email client, what giant existential risks do you have? FAANG have existing customers, we all know people use email. There’s no questions to answer, no uncertainty, so MVPs are the wrong tool for the job.
Why bother running experiments if we have 20 years of data showing us that we have customers and they like using email…
> But if you're FAANG and launch that sort of MVP going against mature products from your competitors
Then you haven't launched a viable product. You haven't made an MVP.
Then you haven't launched a viable product. You haven't made an MVP.
Is it really a Minimum Viable Product if it needs to have every single feature that the incumbents already have?
If it doesn't stand a chance it's not viable, right?
What is smallest product we can build to learn something from and iterate with. If you build something too small that no one uses because it doesn't have enough features, then you can't learn anything from it (apart from you need to build more).
What is smallest product we can build to learn something from and iterate with. If you build something too small that no one uses because it doesn't have enough features, then you can't learn anything from it (apart from you need to build more).
I was recently watching a YT lecture from Geoffrey Moore, and one student raise their question about MVP. Their argument is that MVP doesn't work in B2C because no one wants to use your shitty product. Everyone expected everything to be complete. I think this makes sense from my experience. If you have web, people will ask if you have mobile. If you have iOS, they will ask if you have Android.
And given the YC have shifted their focus to mainly B2B Saas companies, I couldn't help be think the student was right in some way. B2C is so much harder to crack because expectations are high and attention spans are very low. If it doesn't click within 5 seconds, customers just move on. People's tolerance for trying new products compared to a decade again has decreased substantially.
This isn't the case for B2B. If there is a business need, people are much more willing to tolerate your shitty product as long as they receive a net gain. Of course, B2B comes with its challenges.
It was an interesting perspective.
And given the YC have shifted their focus to mainly B2B Saas companies, I couldn't help be think the student was right in some way. B2C is so much harder to crack because expectations are high and attention spans are very low. If it doesn't click within 5 seconds, customers just move on. People's tolerance for trying new products compared to a decade again has decreased substantially.
This isn't the case for B2B. If there is a business need, people are much more willing to tolerate your shitty product as long as they receive a net gain. Of course, B2B comes with its challenges.
It was an interesting perspective.
The best way to tackle that specific problem i've found is by applying Geoffrey Moore's advice in crossing the chasm: slice the market in niches of customers. And then make sure you have the best possible solution for that niche.
Customers want a complete solution for their use case, but not all customers are the same, and not all use cases are the same.
Say you want to create a sports tracking app. You can focus on all sports, or just a few, you can focus on all forms of one sport, or just one particular.
Customers want a complete solution for their use case, but not all customers are the same, and not all use cases are the same.
Say you want to create a sports tracking app. You can focus on all sports, or just a few, you can focus on all forms of one sport, or just one particular.
Interesting, I had the opposite idea. I come from doing B2C product and now work at a B2B SaaS company and my first thought was that B2B is so much harder to crack because existing solutions are really feature complete and clients are not going to tolerate for your service to have quirks or errors.
I guess B2B and B2C are not that much different regarding user tolerance and it just comes down to how much unique value is your solution giving to the customer.
I guess B2B and B2C are not that much different regarding user tolerance and it just comes down to how much unique value is your solution giving to the customer.
This is probably just a lack of familiarity with the playbook for selling B2B. People that have been doing it a long time can intuitively navigate around these obvious objections.
Outside of some rare cases, there are standard positioning techniques to avoid being evaluated for completeness relative to whatever the business has. For example, not positioning your product as a replacement for existing products -- "and" not "or" -- is an effective approach. Trying to be a feature for feature clone of an existing product they already use is a losing proposition, so having a strategy to reframe the discussion away from that perspective is a requirement.
Outside of some rare cases, there are standard positioning techniques to avoid being evaluated for completeness relative to whatever the business has. For example, not positioning your product as a replacement for existing products -- "and" not "or" -- is an effective approach. Trying to be a feature for feature clone of an existing product they already use is a losing proposition, so having a strategy to reframe the discussion away from that perspective is a requirement.
I don’t think it’s necessarily true for B2C. It just depends on who your target audience is. It’s pretty normal for a game, shopping app, etc. to start on iOS and make its way over to Android months later.
The only place where you need more completeness is if you’re building a social app, in my experience. People want to be able to respond to messages everywhere.
The only place where you need more completeness is if you’re building a social app, in my experience. People want to be able to respond to messages everywhere.
Completeness isn't just about cross platform. It is just one example.
Completeness can also mean content. If your shopping app doesn't have vendors, no one is going to use it. Try getting vendors to join your no-name shopping app and I bet you will be 100% ignored other than desperate mom and pop shops.
And for games, it requires a huge investment of talent to develop, and very few games succeed. So completeness here would be getting game designers, graphic designer, software engineers to work together for low pay and high possibility of failure. The only games that don't require huge investments are puzzle games like tetris and 2048.
Completeness is the bar where the end users feel there is sufficient value to use. If Uber Eats only had 10 restaurants, very few people would ever use it. So the bar is very high to get people to start using it consistently.
Completeness can also mean content. If your shopping app doesn't have vendors, no one is going to use it. Try getting vendors to join your no-name shopping app and I bet you will be 100% ignored other than desperate mom and pop shops.
And for games, it requires a huge investment of talent to develop, and very few games succeed. So completeness here would be getting game designers, graphic designer, software engineers to work together for low pay and high possibility of failure. The only games that don't require huge investments are puzzle games like tetris and 2048.
Completeness is the bar where the end users feel there is sufficient value to use. If Uber Eats only had 10 restaurants, very few people would ever use it. So the bar is very high to get people to start using it consistently.
> The emphasis should be on viable and product, and getting there ASAP.
So… a minimum viable product?
So… a minimum viable product?
This made me stopped reading this post. He says it shouldn't be on minimal, then goes on to describe... A MVP.
> So… a minimum viable product?
For most companies a MVP is planting a fast growing seed of technical debt. It's rushed, not polished, full of bugs and used to see if you have any traction because your Product Owners and Sales teams usually have a significant disconnect and development is thought of as an after thought. If you can do a MVP in 1 month, but a minimal polished product in 2, I think that extra month will pay for itself if the product is worth anything.
The worse thing a company can do is have your customers fund your products with a JIT development process.
Sure some companies can get it right doing a true MVP, but most cant and it shows.
For most companies a MVP is planting a fast growing seed of technical debt. It's rushed, not polished, full of bugs and used to see if you have any traction because your Product Owners and Sales teams usually have a significant disconnect and development is thought of as an after thought. If you can do a MVP in 1 month, but a minimal polished product in 2, I think that extra month will pay for itself if the product is worth anything.
The worse thing a company can do is have your customers fund your products with a JIT development process.
Sure some companies can get it right doing a true MVP, but most cant and it shows.
It should be a viable product first. You need to build it fast. So you have to keep its size/feature-set minimum.
If it's not viable, it's not a minimum viable product because it's not viable. If it's not something you can sell or at least market to customers, it's not a minimum viable product because it's not a product. If it doesn't meet enough needs in a clear enough way, it's not a minimum viable product because you haven't met the minimum.
MVP is not a longterm goal, but it can be an important stepping stone. All three of those words matter, though, not just the "minimum". It has to be a viable product. Once you have an product that is viable, you can start selling it as a solution to some problems and find out what else those paying customers want it to do. Don't give up three years of income making a product more than it has to be, but don't release that small starter version yet if it's buggy or confusing, either.
MVP is not a longterm goal, but it can be an important stepping stone. All three of those words matter, though, not just the "minimum". It has to be a viable product. Once you have an product that is viable, you can start selling it as a solution to some problems and find out what else those paying customers want it to do. Don't give up three years of income making a product more than it has to be, but don't release that small starter version yet if it's buggy or confusing, either.
Absolutely! The "minimum" in MVP is about minimising the time until a viable product's in the market. It's not that worse is better, it's that - other things being equal - quicker is better.
Key point I agree with:
- hire people with domain and technical expertise; don't stumble through without expertise and having to reinvent things poorly and fail.
The author seems to be advising to wait till you have a fairly concrete business idea and the required technical and domain expertise for starting up – especially with your own money – because both time and money are in short supply.
This is great advice if you want to build a new business with you own savings or with debt etc, but without funding from VCs.
If it is VC funded, in the early rounds, you are basically an experimental bet for the VC – a small risk for a potential huge upside. For you too it should be the same – a small risk bet with a potential huge upside (you shouldn't starve yourself).
By the time you get to bigger funding rounds, you have figured out – product market fit and execution – that you and VCs believe this is scalable and hence the bigger round.
If you fail at the earlier rounds, that's an expected likely outcome. If you and VCs have a relationship of mutual admiration, then you continue to be funded to do something else – the pivot.
When this happens, VCs and you should consider the previous investment as mostly a write-off and think of this as a new start. After a few such pivots, the VCs may lose confidence and hence you run out of funding. You may also be burnt out (from the high-stakes decision fueled execution stress) and choose to return the money and take a break.
All this is perfectly normal and expected in VC land.
- hire people with domain and technical expertise; don't stumble through without expertise and having to reinvent things poorly and fail.
The author seems to be advising to wait till you have a fairly concrete business idea and the required technical and domain expertise for starting up – especially with your own money – because both time and money are in short supply.
This is great advice if you want to build a new business with you own savings or with debt etc, but without funding from VCs.
If it is VC funded, in the early rounds, you are basically an experimental bet for the VC – a small risk for a potential huge upside. For you too it should be the same – a small risk bet with a potential huge upside (you shouldn't starve yourself).
By the time you get to bigger funding rounds, you have figured out – product market fit and execution – that you and VCs believe this is scalable and hence the bigger round.
If you fail at the earlier rounds, that's an expected likely outcome. If you and VCs have a relationship of mutual admiration, then you continue to be funded to do something else – the pivot.
When this happens, VCs and you should consider the previous investment as mostly a write-off and think of this as a new start. After a few such pivots, the VCs may lose confidence and hence you run out of funding. You may also be burnt out (from the high-stakes decision fueled execution stress) and choose to return the money and take a break.
All this is perfectly normal and expected in VC land.
MVP is tool like any other. It might be used well (to validate an idea) or may be used poorly (to implement semi-functional piece of software, which is strictly worse than the peers).
There's also nothing wrong with pivoting, because while you may implement working businesses case, along the way you may discover one, that's better for you and your customers. Of course it can be used in pathological manner as any tool again.
I think, that what should be definitely busted in IT(or maybe in general?) is easily talking in absolutes (OOP best/bad, functional programming best/bad, k8s best/bad).
Everything depends on the context. Especially would be great to see that altitude from members of academia, because they influence a lot of young engineers.
There's also nothing wrong with pivoting, because while you may implement working businesses case, along the way you may discover one, that's better for you and your customers. Of course it can be used in pathological manner as any tool again.
I think, that what should be definitely busted in IT(or maybe in general?) is easily talking in absolutes (OOP best/bad, functional programming best/bad, k8s best/bad).
Everything depends on the context. Especially would be great to see that altitude from members of academia, because they influence a lot of young engineers.
> The risk is you’re going to build something and nobody will come (or stay), and then you’ll run out of money.
I feel like the author missed the letter in the middle, V. V=viable. So you build an MVP missing the viable. Yep, that's a risk. How does that bust the concept of MVP?
The author goes on to reason in circles several times, occasionally repeating some permutation of "it has to be viable", and "why didn't you start with something viable". "You're doing it wrong, you don't have the viable."
This person isn't ranting about MVPs. This person is ranting about startups that obviously do not have MVPs and are stabbing blindly at one.
I feel like the author missed the letter in the middle, V. V=viable. So you build an MVP missing the viable. Yep, that's a risk. How does that bust the concept of MVP?
The author goes on to reason in circles several times, occasionally repeating some permutation of "it has to be viable", and "why didn't you start with something viable". "You're doing it wrong, you don't have the viable."
This person isn't ranting about MVPs. This person is ranting about startups that obviously do not have MVPs and are stabbing blindly at one.
> The risk is you’re going to build something and nobody will come (or stay), and then you’ll run out of money.
Maybe author is conflating MVP with "build and they'll come". They're quite different ideas, although are frequently seen together in the same minds.
"Build and they'll come" is silly. 95% of businesses will need effort to bring products to consumers. Some form of marketing and/or sales.
One great risk is whether you can market and or sell the product. That's where MVPs help. Simulating marketing/sales without any product usually is not a good predictor of reality.
Maybe author is conflating MVP with "build and they'll come". They're quite different ideas, although are frequently seen together in the same minds.
"Build and they'll come" is silly. 95% of businesses will need effort to bring products to consumers. Some form of marketing and/or sales.
One great risk is whether you can market and or sell the product. That's where MVPs help. Simulating marketing/sales without any product usually is not a good predictor of reality.
"Build it and they'll come" is pure survivor's bias. It's true that there are some products (Wordle, Minecraft, Undertale, lots of other indie games, ...) that were built by single developers or small teams with little to no marketing and became wildly successful anyway. But nobody is remembering the thousands of products that tried to follow this strategy and failed (or still exist in complete obscurity).
> Maybe author is conflating MVP with "build and they'll come". They're quite different ideas, although are frequently seen together in the same minds.
I think the author is pointing out that other people are conflating the ideas. I don't think the author advocates building a fully-fledged 1.0 product before getting real-world feedback.
I've worked for startups that kept shouting "MVP, MVP" for each new feature (and customer) we built. What we got in return for that was a heap of half-finished features, lots of technical debt — and not a single happy customer.
I think the author is pointing out that other people are conflating the ideas. I don't think the author advocates building a fully-fledged 1.0 product before getting real-world feedback.
I've worked for startups that kept shouting "MVP, MVP" for each new feature (and customer) we built. What we got in return for that was a heap of half-finished features, lots of technical debt — and not a single happy customer.
Then you weren’t building MVPs, because V stands for “viable”.
Devs I’ve worked with will sometimes hear “MVP” and think “prototype”. Not really sure why. An MVP needs polish, it’s just a way of keeping a narrow focus and avoiding bike shedding.
Devs I’ve worked with will sometimes hear “MVP” and think “prototype”. Not really sure why. An MVP needs polish, it’s just a way of keeping a narrow focus and avoiding bike shedding.
Absolutely agree. I was about to make an edit to my post pointing out that we missed the "viable" part.
I work in UX, so I kept shouting to deaf ears. Unfortunately, it was seldom my decision to make.
I work in UX, so I kept shouting to deaf ears. Unfortunately, it was seldom my decision to make.
I'm ready to just say MVPs as a concept shouldn't be taught. In theory they should work fine, but I've never worked at a startup where they helped us. It's one of those things that's so easy to get wrong that it's dangerous and should be probably be avoided.
He nails it when he says people focus on the "minimum" part too much. The last startup I worked at insisted on making the minimum version of every piece of a huge system. This resulted in a shallow, unpolished platform that did everything, but didn't do anything well.
At every step, we'd say "this feature set sucks, and the UI is embarrassing. We need to flesh this out," and the response from PMs would be "this is the minimum viable product that might work". Well, it didn't. In the end, we made something nobody inside or outside the company wanted. We made the minimum, but it wasn't viable, and it wasn't a product.
You might say "well, the fact that people don't employ it correctly is not a strike against the concept of MVP" but I've seen this happen over and over. I've only ever seen MVP go wrong, and I've only heard anecdotes about it working. Using it doesn't seem to change your odds of success as a startup. I think it may be one of those theoretically good ideas most people aren't ready for.
He nails it when he says people focus on the "minimum" part too much. The last startup I worked at insisted on making the minimum version of every piece of a huge system. This resulted in a shallow, unpolished platform that did everything, but didn't do anything well.
At every step, we'd say "this feature set sucks, and the UI is embarrassing. We need to flesh this out," and the response from PMs would be "this is the minimum viable product that might work". Well, it didn't. In the end, we made something nobody inside or outside the company wanted. We made the minimum, but it wasn't viable, and it wasn't a product.
You might say "well, the fact that people don't employ it correctly is not a strike against the concept of MVP" but I've seen this happen over and over. I've only ever seen MVP go wrong, and I've only heard anecdotes about it working. Using it doesn't seem to change your odds of success as a startup. I think it may be one of those theoretically good ideas most people aren't ready for.
MVP as a concept suffers from the whole “implement the acronym” problem. At one point it was a helpful tool for understanding some repeatable patterns in startup product management, but its turned into something else. I suppose its mostly cargo culting startup advice these days.
Yeah it has go kinda same way as "agile", where people use both terms without understanding what it actually means and how to implement those. But that does not mean that "agile" or "MVP" is death and you should not use those.
This article isn't talking about MVP. It's talking about fools who don't know what they are doing. MVP doesn't suggest that you don't know what you want to do but that you understand that you are wrong and that you need to learn more.
Could not disagree more with the article. Sounds like Michael just isn't very good at building customer engagement and then using empathy driven engagement to understand pain points and ideate solutions.
For exmaple, he says:
> What is there to be careful of MVP as a strategy? Well, to start, I don’t think MVP works. The risk is you’re going to build something and nobody will come (or stay), and then you’ll run out of money.
This has nothing to do with a MVP approach and everything to do with ensuring you are building the MVP with and for a specific customer or customers who have pain points you understand, and then iterating on their feedback as you go. You could make the mistake of not having customers ready to share their feedback with you with and without an MVP.
He also says:
> But no - who would give you money if you didn’t know what product you were making? The product should be in your DNA
Utter tosh - I've had success building software that started as MVPs in two completely different industries that prior to building the software I had zero experience in.
I could go on...but I've made my point. Don't listen to anybody who says MVPs are old and busted - especially but not limited to this guy.
For exmaple, he says:
> What is there to be careful of MVP as a strategy? Well, to start, I don’t think MVP works. The risk is you’re going to build something and nobody will come (or stay), and then you’ll run out of money.
This has nothing to do with a MVP approach and everything to do with ensuring you are building the MVP with and for a specific customer or customers who have pain points you understand, and then iterating on their feedback as you go. You could make the mistake of not having customers ready to share their feedback with you with and without an MVP.
He also says:
> But no - who would give you money if you didn’t know what product you were making? The product should be in your DNA
Utter tosh - I've had success building software that started as MVPs in two completely different industries that prior to building the software I had zero experience in.
I could go on...but I've made my point. Don't listen to anybody who says MVPs are old and busted - especially but not limited to this guy.
Like every method that gets condensed to an acronym, MVP has been used to justify lots of bad decisions.
For example, I worked in very engineering-driven environments where “viable” meant nothing more than “it compiles”. Especially when combined with an over-reliance on quantitative metrics (and an under-appreciation of qualitative research) this leads to lots of ideas being killed prematurely. This meme has helped me a lot when communicating in these situations: https://imgur.com/a/pSY7IrF
From that point of view, I can understand the author, but “you should just know what’s going to be successful” isn’t a very useful alternative.
Even with great knowledge of your customers and domain, your first (or second, or third) solution might not be the right fit. Just think of all the personal projects that never end up getting used, even by the author.
In the end, the problem with MVPs and similar methods that get popular is that people think they can replace good judgement with a method. The methods can help, but they won’t do the thinking for you and they won’t make anything risk-free.
For example, I worked in very engineering-driven environments where “viable” meant nothing more than “it compiles”. Especially when combined with an over-reliance on quantitative metrics (and an under-appreciation of qualitative research) this leads to lots of ideas being killed prematurely. This meme has helped me a lot when communicating in these situations: https://imgur.com/a/pSY7IrF
From that point of view, I can understand the author, but “you should just know what’s going to be successful” isn’t a very useful alternative.
Even with great knowledge of your customers and domain, your first (or second, or third) solution might not be the right fit. Just think of all the personal projects that never end up getting used, even by the author.
In the end, the problem with MVPs and similar methods that get popular is that people think they can replace good judgement with a method. The methods can help, but they won’t do the thinking for you and they won’t make anything risk-free.
Every time I read something like this, I am reminded of the story of the blind men and the elephant [0].
It sounds like the author had some success and, now that they had that success, they are going around imposing their world view on others whose paths to success may necessarily require different strategies and patterns of thoughts. Because they are different fucking people from the author, under different conditions, and with different interests and passions.
This articles is meant to advertise the author's endeavors as a speaker and perhaps as a coach. Nothing more.
If you are struggling with your business, please disregard this article as drivel. You have many paths to success or failure. None of them are universal.
0. https://en.wikipedia.org/wiki/Blind_men_and_an_elephant
It sounds like the author had some success and, now that they had that success, they are going around imposing their world view on others whose paths to success may necessarily require different strategies and patterns of thoughts. Because they are different fucking people from the author, under different conditions, and with different interests and passions.
This articles is meant to advertise the author's endeavors as a speaker and perhaps as a coach. Nothing more.
If you are struggling with your business, please disregard this article as drivel. You have many paths to success or failure. None of them are universal.
0. https://en.wikipedia.org/wiki/Blind_men_and_an_elephant
> The whole MVP process presumes you don’t know what you are making for a product...
Then how can the minimum viabilty be judged?
This seems a logical flaw, theoretically speaking.
As a practical matter, inexperience may lead to not understanding what the term even means. But that has more to with people than the acronym.
No term is immune to human debasement.
Then how can the minimum viabilty be judged?
This seems a logical flaw, theoretically speaking.
As a practical matter, inexperience may lead to not understanding what the term even means. But that has more to with people than the acronym.
No term is immune to human debasement.
Let's come up with an edgy title, go on a rant that has nothing to do with the title and call it a productive day!
> The whole MVP process presumes you don’t know what you are making for a product, and that is death
This is not how MVP is defined. The MVP is the actually definition of a pre-determined product.
> The whole MVP process presumes you don’t know what you are making for a product, and that is death
This is not how MVP is defined. The MVP is the actually definition of a pre-determined product.
Ability to pivot and agility is what separates the losers from the winners. In evolution, it is not the strongest that survives, it is the one that can adapt to changes. Building an MVP is being agile.
I was leading engineering at a finance company that offered ways to invest in an ESG fund that the company managed. The product had no traction. We had 6 months of runway left in the bank and no investor would even touch us with near 0 growth. This was when Wells Fargo scandal hit and people were angry at their banks. We pivoted to online banking and released a banking app in 4 months. 10x our customer base and raised $40m in under a year. If we kept just building out the investment product, we would have failed.
I was leading engineering at a finance company that offered ways to invest in an ESG fund that the company managed. The product had no traction. We had 6 months of runway left in the bank and no investor would even touch us with near 0 growth. This was when Wells Fargo scandal hit and people were angry at their banks. We pivoted to online banking and released a banking app in 4 months. 10x our customer base and raised $40m in under a year. If we kept just building out the investment product, we would have failed.
I generally agree that MVP tends to be cargo-culted rather than chosen as an intentional strategy. Most people who tend to spew the term often don't even know what they mean. I also agree on people tending to focus way too much on the 'minimum' and not nearly enough on the 'viable'. for example, how can you know if investing in the UI or design of a product is necessary for viability? I've seen that any interesting UI is often cut in the effort to find an MVP... but, well, sometimes an interesting design actually increases viability.
In 2011 I released an app which was an education in MVP for me. I knew there was an free open source Java library that parsed Microsoft Access Library, so one day I had the idea to write an Android app for it. As there was no competition at all to parse Microsoft Access databases on the Android device(1) at that time, I figured I could release it without much features, so four days after having the idea I release the app - you can load one database and then one table from the disk and page forward (not backwards) through it. I had an immediate user base despite so few features as there was no alternative at the time.
The education was in what the users wanted. I had ideas about what users might want next, like column sorting, and was thinking of what big O sorting method to use for doing that. My other ideas for features people might want were more technically complex than that.
No one asked about column sorting in the first few months. First they asked if you could page backwards through the table. Then they wanted search. Then they wanted case insensitive search. Then they wanted wildcard search. Then someone said they always loaded the same database, and had to go through the filesystem to find it each new session, and could I have a recent files tab.
I had no idea what features users thought were important. Some were probably important to more than one person, as I got multiple comments and e-mails asking for search. Pretty much everything I implemented was something asked by multiple users. The only exception to that is if one user asked for a feature, but it was simple and obviously a good idea. Some features multiple users asked for, but I put on the backlog because I knew it would take a lot of time to implement correctly.
It was an unusual scenario in that I had a sizable user base who loved that they could look at their Microsoft Access databases on their phones, even though it initially was written in four days. The main lesson was all these ideas I had about the challenges of which big-O algorithm to use were for features users never asked for, and a lot of what they wanted was pretty simple. I knew users would probably want to read Microsoft Access databases on their phones, but I had no idea at all which features of doing that were most important to them until they told me.
The education was in what the users wanted. I had ideas about what users might want next, like column sorting, and was thinking of what big O sorting method to use for doing that. My other ideas for features people might want were more technically complex than that.
No one asked about column sorting in the first few months. First they asked if you could page backwards through the table. Then they wanted search. Then they wanted case insensitive search. Then they wanted wildcard search. Then someone said they always loaded the same database, and had to go through the filesystem to find it each new session, and could I have a recent files tab.
I had no idea what features users thought were important. Some were probably important to more than one person, as I got multiple comments and e-mails asking for search. Pretty much everything I implemented was something asked by multiple users. The only exception to that is if one user asked for a feature, but it was simple and obviously a good idea. Some features multiple users asked for, but I put on the backlog because I knew it would take a lot of time to implement correctly.
It was an unusual scenario in that I had a sizable user base who loved that they could look at their Microsoft Access databases on their phones, even though it initially was written in four days. The main lesson was all these ideas I had about the challenges of which big-O algorithm to use were for features users never asked for, and a lot of what they wanted was pretty simple. I knew users would probably want to read Microsoft Access databases on their phones, but I had no idea at all which features of doing that were most important to them until they told me.
> The whole MVP process presumes you don’t know what you are making for a product, and that is death.
No, the MVP process presumes that you are not omniscient.
Just because you think you know what a customer wants, doesn't mean that anything you make will satisfy the customer. They need to actually get their hands on it, so they can tell you if it works for them. 99% of the time they will be unhappy about something. And that is fine; nothing is ever perfect! But if there is a big expensive time-consuming problem, you won't know that until the customer gets their hands on it, so you don't want to wait long to find those problems.
You want to find those problems as early as possible, so you can fix things early, to reduce the time/cost/complexity of "fixing" things down the line, so your time and money is spent building things right the first time. This reduces cost, speeds up delivery, and improves quality. This concept is called Shift Left.
MVP is intended to get something in the hands of the earliest customers so they can give you feedback. Some people use this just to figure out if they have a market or a product to sell at all, but you don't have to use it that way. You can use as a "minimum customer-acceptable prototype with feedback".
No, the MVP process presumes that you are not omniscient.
Just because you think you know what a customer wants, doesn't mean that anything you make will satisfy the customer. They need to actually get their hands on it, so they can tell you if it works for them. 99% of the time they will be unhappy about something. And that is fine; nothing is ever perfect! But if there is a big expensive time-consuming problem, you won't know that until the customer gets their hands on it, so you don't want to wait long to find those problems.
You want to find those problems as early as possible, so you can fix things early, to reduce the time/cost/complexity of "fixing" things down the line, so your time and money is spent building things right the first time. This reduces cost, speeds up delivery, and improves quality. This concept is called Shift Left.
MVP is intended to get something in the hands of the earliest customers so they can give you feedback. Some people use this just to figure out if they have a market or a product to sell at all, but you don't have to use it that way. You can use as a "minimum customer-acceptable prototype with feedback".
Last year I tried to launch something like a dozen small companies based on an "MVP" or 80/20 approach.
The hypothesis being that even if not a full 80/20 split, I could ~probably~ catch 50% of the value by catering to the core 20% of features.
This was completely incorrect. I made 12 things that made ~no money.
SaaS is by no means saturated, but it is mature enough that you can't just crank out crap and make money.
Buyers are sophisticated
The hypothesis being that even if not a full 80/20 split, I could ~probably~ catch 50% of the value by catering to the core 20% of features.
This was completely incorrect. I made 12 things that made ~no money.
SaaS is by no means saturated, but it is mature enough that you can't just crank out crap and make money.
Buyers are sophisticated
Paul Graham had references to MVP before Lean Startup, he called it "release early" in 2006:
http://www.paulgraham.com/startuplessons.html
Quote: "By "release early" I don't mean you should release something full of bugs, but that you should release something minimal."
Quote: "By "release early" I don't mean you should release something full of bugs, but that you should release something minimal."
This article is entirely about startups, which means the title is too click-baity. The idea of MVP makes a lot more sense in its more common setting: mundane corporate backoffice applications. In such a setting your audience is not millions of people; sometimes it can be one person.
When you have a small audience you aren't afforded the freedom to decide what the product should be. Of course you control the eventual product, but the stakeholder has a huge say in what must be done, and they often have a fairly clear idea of what they want. That's where MVP comes in. You and the "customer" (stakeholder) come to an agreement on the eventual product, and you deliver an MVP to them as a milestone. The point of this MVP is to give the customer something that delivers a bit of value early on, and gives them a way to try out their initial idea to see if it really holds water. Through their time using the MVP they are able to sooner refine and readjust their wish list. Maybe the end product they initially asked for wasn't quite right after all.
In the case of startups, I sort of agree with the author, but he's still missing something: the first customer is you. Yes you should have a crystalline idea of your eventual product (similar to corporate stakeholders) because that is what separates you from your competition. But you should still use MVP! MVP doesn't mean delivering unfinished garbage. MVP just means there's more to come later. "Viable" is completely subjective, and in the case of a startup with a grand vision it should absolutely be a much higher bar than usual. You the customer/entrepreneur need the MVP because you need to see how your product performs when you present it to millions of people.
The whole point is just to avoid the morass of never-ending vaporware with years of missed deadlines, only to finally deliver something nobody wants. If "MVP" is too much of a trigger word you're welcome to call it whatever you want ¯\_(ツ)_/¯
When you have a small audience you aren't afforded the freedom to decide what the product should be. Of course you control the eventual product, but the stakeholder has a huge say in what must be done, and they often have a fairly clear idea of what they want. That's where MVP comes in. You and the "customer" (stakeholder) come to an agreement on the eventual product, and you deliver an MVP to them as a milestone. The point of this MVP is to give the customer something that delivers a bit of value early on, and gives them a way to try out their initial idea to see if it really holds water. Through their time using the MVP they are able to sooner refine and readjust their wish list. Maybe the end product they initially asked for wasn't quite right after all.
In the case of startups, I sort of agree with the author, but he's still missing something: the first customer is you. Yes you should have a crystalline idea of your eventual product (similar to corporate stakeholders) because that is what separates you from your competition. But you should still use MVP! MVP doesn't mean delivering unfinished garbage. MVP just means there's more to come later. "Viable" is completely subjective, and in the case of a startup with a grand vision it should absolutely be a much higher bar than usual. You the customer/entrepreneur need the MVP because you need to see how your product performs when you present it to millions of people.
The whole point is just to avoid the morass of never-ending vaporware with years of missed deadlines, only to finally deliver something nobody wants. If "MVP" is too much of a trigger word you're welcome to call it whatever you want ¯\_(ツ)_/¯
Someone finally said it. Also not all things fit the mvp paradigm.
The Lean Startup is very clear on both the why and the limitations of an MVP. Within that framework what constitutes an MVP is pretty obvious. In a nutshell you need to put something out that helps you learn as much as possible as quickly as possible. That is the primary purpose of an MVP and it should be considered both minimal and viable in that context.
Lot of "processes" that comes out of silicon valley(and in general US) should be adopted with caution. "Try before you buy" approach should be used. First let it settle in the industry(at least in the US) and then test and adapt to your project on a case-by-case basis.
Take any process, Lean, MVP, Agile, etc are paraded as if they are solution to every Mommy's and Daddy's problem. It is not. One size does not fit all. The only statement(which is an old wisdom out of the UK computing industry) is "There is no silver bullet". This applies to everything in life, even MVPs.
MVPs works for most software startups(and some other creative industries), but it is not viable for everyone. So saying that it "always works" or "it is busted" are both wrong statements.
Take any process, Lean, MVP, Agile, etc are paraded as if they are solution to every Mommy's and Daddy's problem. It is not. One size does not fit all. The only statement(which is an old wisdom out of the UK computing industry) is "There is no silver bullet". This applies to everything in life, even MVPs.
MVPs works for most software startups(and some other creative industries), but it is not viable for everyone. So saying that it "always works" or "it is busted" are both wrong statements.
> What is there to be careful of MVP as a strategy? Well, to start, I don’t think MVP works. The risk is you’re going to build something and nobody will come (or stay), and then you’ll run out of money.
MVPs don't exist in a vacuum, they are part of a larger effort to figure out your business model (what is the actual problem? Who are your customers? How will you make money?) in the most efficient way possible. For a MVP to make sense, you have to do user research and truly understand the problem domain.
> Your company shouldn’t be in search of a business model, you should know what you need to build.
This is wishful thinking. Tons of products and companies fail simply because founders think they "know" what their business model is when in fact it's just a bunch of unverified assumptions about the market.
MVPs don't exist in a vacuum, they are part of a larger effort to figure out your business model (what is the actual problem? Who are your customers? How will you make money?) in the most efficient way possible. For a MVP to make sense, you have to do user research and truly understand the problem domain.
> Your company shouldn’t be in search of a business model, you should know what you need to build.
This is wishful thinking. Tons of products and companies fail simply because founders think they "know" what their business model is when in fact it's just a bunch of unverified assumptions about the market.
But...by definition, if the product isn't viable it isn't a minimum viable product.
Read "Bulid the Right It". Then an MVP makes perfect sense.
A great session from the author here https://www.youtube.com/watch?v=njZ4H-5WRYA
A great session from the author here https://www.youtube.com/watch?v=njZ4H-5WRYA
Every company/startup will be different in some way, so what MVP means for them -- and the reason they go that route -- will be unique.
At least in some cases, MVP is the minimal product you made which illustrates your solution, your value proposition. You use that to get big investment to build "the real one".
Unfortunately, some (many?) companies want to take that MVP and live with it indefinitely, organically (sloppily) growing it as they go.
MVP can be seen as that thing you do which gives you the opportunity to exist but which gradually drags you to the bottom of the sea with technical debt.
At least in some cases, MVP is the minimal product you made which illustrates your solution, your value proposition. You use that to get big investment to build "the real one".
Unfortunately, some (many?) companies want to take that MVP and live with it indefinitely, organically (sloppily) growing it as they go.
MVP can be seen as that thing you do which gives you the opportunity to exist but which gradually drags you to the bottom of the sea with technical debt.
I think what people miss with MVP is how it fits into the product lifecycle.
There's inherently a not of 'gray' in the situation, so don't take more steps than you need to.
Do the 'first thing' and then adjust before the 'second thing' and just don't get too far ahead of yourselves.
Even if people loathe the MVP you'll find out why.
Going from 'Slides' to 'Something Material' is a big deal, so to it in steps.
It's almost another way of saying 'build your product incrementally' - and I you do that, the 'first increment' is an MVP.
That's it.
There's inherently a not of 'gray' in the situation, so don't take more steps than you need to.
Do the 'first thing' and then adjust before the 'second thing' and just don't get too far ahead of yourselves.
Even if people loathe the MVP you'll find out why.
Going from 'Slides' to 'Something Material' is a big deal, so to it in steps.
It's almost another way of saying 'build your product incrementally' - and I you do that, the 'first increment' is an MVP.
That's it.
Contra to most of the comments here, I found a lot to agree with in this article:
> You have no soul as a company at that point, you’re just trying to make money with other people, rather than help people with a problem that you know. You may think you have an idea, but it’s not good enough yet.
I think this is the crux of the difference. If you want to have a successful startup, you have to believe that you deserve to exist and believe you have something unique to offer. You cannot just "show up and listen" and get paid the big bucks.
> You have no soul as a company at that point, you’re just trying to make money with other people, rather than help people with a problem that you know. You may think you have an idea, but it’s not good enough yet.
I think this is the crux of the difference. If you want to have a successful startup, you have to believe that you deserve to exist and believe you have something unique to offer. You cannot just "show up and listen" and get paid the big bucks.
If its perfect, you took too long and its too late
You can tell me that’s a “startup religion” while I collect investment based on a random metric I made up simply because I have the data from a product I released
You can tell me that’s a “startup religion” while I collect investment based on a random metric I made up simply because I have the data from a product I released
This article appears to conflate the role of a pre-product/market fit startup (nailing the problem) with the role of a post-product/market fit startup (executing on a solution).
I disagree with “know what problem you’re solving exactly before you start a company”. The entire point of an early startup is working out exactly what problem to solve. A pivot is realising your hypothesis is flawed and redefining the problem based on some new information.
Great execution at the early stage is table stakes for survival.
I disagree with “know what problem you’re solving exactly before you start a company”. The entire point of an early startup is working out exactly what problem to solve. A pivot is realising your hypothesis is flawed and redefining the problem based on some new information.
Great execution at the early stage is table stakes for survival.
In my experience, building into a "red ocean" of 200 competitors, the MVP concept is still valid, but the goalposts have shifted.
Whereas before the advice might have been "just build a tiny solution to the problem you're solving, and see what people think", these days folks don't take you seriously without SaaS-like features around it, like inviting their team to the tool, auth, etc
Whereas before the advice might have been "just build a tiny solution to the problem you're solving, and see what people think", these days folks don't take you seriously without SaaS-like features around it, like inviting their team to the tool, auth, etc
[deleted]
> The whole MVP process presumes you don’t know what you are making for a product, and that is death.
I don't agree at all with this statement. It's not that you don't know, you know, but you are realistic with the pretentions: you will not go for huge product to hit the market, you want to focus on your best strenght and then grow faster until you complete your idea.
I don't agree at all with this statement. It's not that you don't know, you know, but you are realistic with the pretentions: you will not go for huge product to hit the market, you want to focus on your best strenght and then grow faster until you complete your idea.
I upvoted this for discussion purposes (and because it's well written) but I really disagree here. User needs are hard to predict in all sorts of businesses. In b2c consumers often don't know what they want. In b2b, the market often doesn't know how it needs its solution solved. In both cases MVP + iteration on traction is the fastest path to happy users.
"The whole MVP process presumes you don’t know what you are making for a product, and that is death. You have no soul as a company at that point, you’re just trying to make money with other people, rather than help people with a problem that you know."
People can argue about different beliefs about what MVP means, but regardless of semantics that line really resonated.
People can argue about different beliefs about what MVP means, but regardless of semantics that line really resonated.
I think the problem with MVP today is that MVPs have such a shorter lifespan now compared to the past decade that by the time you iterate into a full product it should have happened so fast that it looks like you basically built the right product from the start. If you don’t go fast you will miss the opportunity and be beaten by a competitor.
The author writes "who would give you money if you didn’t know what product you were making". Which is a very good point. And is the point of an creating an MVP first. You create an MVP before you seek outside financing, not after. You know, so that you know what product you're making when you ask for money.
Building a viable product is of course something you need to do as a company to succeed. Building a minimum viable product on the other hand might just trap you into building a product quickly that isn't viable because you end up throwing away the baby with the bathwater. The problem is with the word minimum. How much of your product can you strip away without losing the value proposition? If you strip away too much, it won't be viable.
This is where startup methodology of building something quickly and then failing is at odds with the traditional way of doing something well and then growing a business around that. It's a slower process but occasionally such companies become big. Investors are obsessed with taking short cuts to success. So they'll favor companies that build an MVP. Most of those will fail but occasionally they get lucky and the failures are relatively quick and painless (think acquihires).
An MVP is easier if you eliminate all risk. Like the outcomes of potentially risky R&D or actually doing anything complicated and risky. Of course the intersection of low risk stuff and actually valuable stuff is pretty narrow. So investors love things like uber, air bnb, because all these things are are simple variations of market places and easy to understand. They are no-tech companies and their MVP is a simple website. All they needed early on is marketing, business development, some generic full stack coders and lots of cash to fake it until they make it.
MVP thinking breeds generic no-tech startups. Some of these end up being valuable but most of them don't really do anything that is technically interesting. Or valuable. Or viable.
There's a different class of companies that follow a very different pattern. These are tech companies that start with some hard core R&D. They are risky investments with a non linear payoff (relative to the investment) in case things work out. SpaceX is a good example. They got close to failing after spending many billions. And then they made it to orbit and with a lot more investment they eventually got the company profitable. The MVP for a rocket company is a rocket that makes it to orbit. The MVP for a nuclear fusion plant is building a plant that produces power. That has not happened yet of course but people are spending billions trying to make that happen. That's a different type of investor that does that. Usually, these investors will base their decisions on very early proofs of concept, founder reputation, or other signals of things looking promising.
This is where startup methodology of building something quickly and then failing is at odds with the traditional way of doing something well and then growing a business around that. It's a slower process but occasionally such companies become big. Investors are obsessed with taking short cuts to success. So they'll favor companies that build an MVP. Most of those will fail but occasionally they get lucky and the failures are relatively quick and painless (think acquihires).
An MVP is easier if you eliminate all risk. Like the outcomes of potentially risky R&D or actually doing anything complicated and risky. Of course the intersection of low risk stuff and actually valuable stuff is pretty narrow. So investors love things like uber, air bnb, because all these things are are simple variations of market places and easy to understand. They are no-tech companies and their MVP is a simple website. All they needed early on is marketing, business development, some generic full stack coders and lots of cash to fake it until they make it.
MVP thinking breeds generic no-tech startups. Some of these end up being valuable but most of them don't really do anything that is technically interesting. Or valuable. Or viable.
There's a different class of companies that follow a very different pattern. These are tech companies that start with some hard core R&D. They are risky investments with a non linear payoff (relative to the investment) in case things work out. SpaceX is a good example. They got close to failing after spending many billions. And then they made it to orbit and with a lot more investment they eventually got the company profitable. The MVP for a rocket company is a rocket that makes it to orbit. The MVP for a nuclear fusion plant is building a plant that produces power. That has not happened yet of course but people are spending billions trying to make that happen. That's a different type of investor that does that. Usually, these investors will base their decisions on very early proofs of concept, founder reputation, or other signals of things looking promising.
> The whole MVP process presumes you don’t know what you are making for a product, and that is death.
I am not sure that is how everyone understand what an MVP is.
I think of it as "I know what product I am developing, I just don't know what features within the product I should prioritize now vs later"
I am not sure that is how everyone understand what an MVP is.
I think of it as "I know what product I am developing, I just don't know what features within the product I should prioritize now vs later"
This seems to be arguing that the complete implementation is what matters most.
That seems expensive and risky.
That seems expensive and risky.
Yes, a complete, well-rounded implementation is what makes for a successful product (where well-rounded == supports use-cases for customers well).
It is expensive (which is why it costs a lot to create a startup) and it is very risky (which is why most startups fail because they mess this up).
It is expensive (which is why it costs a lot to create a startup) and it is very risky (which is why most startups fail because they mess this up).
Exactly, none of this stuff is easy. And it's not supposed to be easy and risk-free. Otherwise, anyone could build a successful startup/product
The article separates 'Survey your Customers' and 'Know your Market' like they are two different things. Not sure how you can deprecate the customer input, and stress your own market knowledge without your head exploding.
Better to build a minimal version of the wrong thing than a full version of the wrong thing.
Of course, if you can just build the right thing then do that. But you're more likely to mess up that way.
Of course, if you can just build the right thing then do that. But you're more likely to mess up that way.
I think the way MVP is usually quoted at people is confusing. It should be something like “maximize the amount of feedback you’re getting from customers”.
Or: do the least amount of work for a reasonable amount of return. You are not maximising anything (yet) imo.
Seems to me that the author doesn’t understand what MVP means. Old maybe, but busted? Gtfo
It's still a tried and trusted approach. It may not fit every situation, but there's a big emphasis on derisking and early marketing which can't be ignored. I'm incorporating options like that into https://cxo.industries, a web app to help founders with making informed choices.
This is exactly what killed my first startup. We believed we fully understood what the customer needs and that we should build the right product before we started selling. We were actually trying to build the minimum viable product, but we were hilariously (with hindsight) wrong about what the customers wanted. Almost all our ideas were just wrong enough to make the product fail to solve the customers pains. They solved the pains we'd had in the past brilliantly, but sadly that wasn't relevant. We weren't buying our product.
Starting out with the notion that you already know everything you need to know will kill your startup. Running a startup is as much about spotting and understanding the signals that you discover along the way as it is about building what you think you customers need.
A minimum viable product is not "selling the least effort product you can get away with", it's spending the least amount of time you can to build something that you can use to gather more data than you can use to focus your product on what the customer wants rather than what you think they want. Building what you think the customer wants will very likely be wrong - customers lie, they're deluded, they don't understand their own problems, and they can't see value in solutions. But they do start to understand the problem when they see a solution to it, even if it's the minimum viable solution. And then they start having ideas about what else they can pay for to make it better...