The Death of the MVP (Minimum Viable Product) in Competitive Markets(blog.groovehq.com)
blog.groovehq.com
The Death of the MVP (Minimum Viable Product) in Competitive Markets
http://blog.groovehq.com/post/13829640150/the-death-of-the-mvp-minimum-viable-product-in
13 コメント
a minimum viable product, keyword being viable
Absolutely, but I'll add this posit: What "viable" means is heavily context driven. If the goal is to learn about whether or not your specific take on things is valid, then what your MVP will need to look like will depend on the kind of market your pursuing, whether or not their are already existing players in your space, how radically different your approach is, etc.
IOW... if you wanted to launch an MVP of a "Facebook Killer" and the "secret sauce" was something, like, oh... some gamification thing... badges or accomplishments related to making new friends, let's say. That's enough like Facebook (or g+, etc.) that the expectation for a potential user would be based around Facebook... your "secret sauce" is only an incremental improvement, so you'd almost have to roll out something as feature rich and visually polished as Facebook, in order to find out if you can compete. That sucks, but one that's why there are both pluses and minuses to entering an established market with an incremental improvement. :-)
Now if your "secret sauce" is something world-changing and totally new, like say, "automatic Frombleglizzits when you Gwizztickum" (whatever that is), then you may ONLY need to build enough to make people understand what "automatic Frombleglizzits when you Gwizztickum" is, and then you can find out if that's compelling to them or not, in isolation. If it turns out it isn't, you would have wasted a tremendous amount of time building a complete Facebook clone just to find that out. You have more uncertainty in this case, but this is exactly where the Lean Startup approach helps... eliminating waste in the face of extreme uncertainty.
good news: no one knows who you are when you launch, so you have nothing to lose.
Exactly.
Unfortunately I think what we're seeing is the lean startup backlash where people use the terms but don't really take the time to understand what they mean.
Absolutely.
Absolutely, but I'll add this posit: What "viable" means is heavily context driven. If the goal is to learn about whether or not your specific take on things is valid, then what your MVP will need to look like will depend on the kind of market your pursuing, whether or not their are already existing players in your space, how radically different your approach is, etc.
IOW... if you wanted to launch an MVP of a "Facebook Killer" and the "secret sauce" was something, like, oh... some gamification thing... badges or accomplishments related to making new friends, let's say. That's enough like Facebook (or g+, etc.) that the expectation for a potential user would be based around Facebook... your "secret sauce" is only an incremental improvement, so you'd almost have to roll out something as feature rich and visually polished as Facebook, in order to find out if you can compete. That sucks, but one that's why there are both pluses and minuses to entering an established market with an incremental improvement. :-)
Now if your "secret sauce" is something world-changing and totally new, like say, "automatic Frombleglizzits when you Gwizztickum" (whatever that is), then you may ONLY need to build enough to make people understand what "automatic Frombleglizzits when you Gwizztickum" is, and then you can find out if that's compelling to them or not, in isolation. If it turns out it isn't, you would have wasted a tremendous amount of time building a complete Facebook clone just to find that out. You have more uncertainty in this case, but this is exactly where the Lean Startup approach helps... eliminating waste in the face of extreme uncertainty.
good news: no one knows who you are when you launch, so you have nothing to lose.
Exactly.
Unfortunately I think what we're seeing is the lean startup backlash where people use the terms but don't really take the time to understand what they mean.
Absolutely.
100% agree that viable is context driven, but I kind of disagree with your example. If you want to compete with an established player, focus on the differentiating factor that you think is game-changing rather than competing on features, otherwise you'll never win. The early adopters that you want to court will be excited by what's different, not by a clone of something that already exists. By the time the product is ready for the prime time it will need those features, but by then the bleeding edge early adopters will have moved on to the next new thing.
However, in cases like healthcare or finance, or certain B2B applications, viable may entail a much more mature product.
However, in cases like healthcare or finance, or certain B2B applications, viable may entail a much more mature product.
If you want to compete with an established player, focus on the differentiating factor that you think is game-changing rather than competing on features, otherwise you'll never win
"Never" is an awfully strong statement, but I mostly agree with that sentiment. I see this as orthogonal to the point I was originally trying to make though. My example was probably to hastily constructed and may not have been very clear.
"Never" is an awfully strong statement, but I mostly agree with that sentiment. I see this as orthogonal to the point I was originally trying to make though. My example was probably to hastily constructed and may not have been very clear.
What "viable" means is heavily context driven.
TLDR: In established markets, viable != minimal.
TLDR: In established markets, viable != minimal.
I think the "minimal" needs to be looked as as "relative to what you could conceivably build" not as "relative to the market." You always want to build the minimal thing you can, that enables you to get the validated learning that you're after. It's just that if there's an established market and existing players, you probably have to build up to that bar, in order to learn about the bit you intend to do differently.
Or something like that... :-)
Or something like that... :-)
> TLDR: In established markets, viable != minimal.
So it's not possible to target a niche with a specialized product that only has 20% of the competition's features, but does those 20% properly for that niche?
So it's not possible to target a niche with a specialized product that only has 20% of the competition's features, but does those 20% properly for that niche?
It's still possible. What I mean, is don't expect to be able to get away with something as skimpy as you would in a totally new market.
Agreed.
What we really need is an article about "The Death of Articles about (why|when|how|if) to use MVPs, written by people who don't understand Customer Development and the Lean Startup approach."
Of the several articles decrying the MVP that I've seen hit the HN frontpage in the past few days, every single one of them (and or the associated comments) have shown a profound misunderstanding of what it means to follow the Lean Startup approach. Hint: being a Lean Startup does NOT mean developing a buggy, shitty looking, incomplete application, releasing it to the public and hoping for the best.
Also note that the strategies for developing a product in an established market are NOT the same as when you're creating something truly novel. If you don't understand that, go back and re-read The Four Steps to the Epiphany.
In fact, if I could assign homework to random people, I'd assign re-reading that book as homework to any and every body who's tempted to write another blog post commenting on this subject. :-)
Just to re-iterate: A couple of the major tenets of the Lean Startup approach are to learn continuously, and specifically by gaining validated learning, AND to eliminate waste, by not building something nobody wants. Ergo, a true MVP represents the intersection of the least you can build and still gain some useful, validated learning (context matters here, see above about established markets, vs entirely new products), while avoiding building stuff in advance, that will ultimately become waste.
That's it... nothing requires your MVP to be incomplete, buggy, shitty-looking, unstable, or any of those other things... BUT, and this is a key but, it might actually be any of those things, IF it can be and still meet the above goals!
Also nothing about the methodology per-se requires you to launch your MVP to the entire world from day one. Ok, maybe there's something about your scenario that dictates that the ONLY way you can gain any validated learning is through a worldwide launch to the public... I don't know, it's your startup not mine. But for most of us, MVPs are meant to be shown to a handpicked set of early prospective customers, preferably ones who have already been through the earlier stages of the Customer Development process with you.
Edit: To be fair to the original author, the title does specifically mention that he's referring to "competitive markets" and I do acknowledge that the exact criteria for your MVP may vary when you're entering an existing market. The one point I'll add about that, is that while Customer Development and the Lean Startup approach still apply in this setting, they seem to be most optimized for startups that are creating entirely new markets for radically new products.
Of the several articles decrying the MVP that I've seen hit the HN frontpage in the past few days, every single one of them (and or the associated comments) have shown a profound misunderstanding of what it means to follow the Lean Startup approach. Hint: being a Lean Startup does NOT mean developing a buggy, shitty looking, incomplete application, releasing it to the public and hoping for the best.
Also note that the strategies for developing a product in an established market are NOT the same as when you're creating something truly novel. If you don't understand that, go back and re-read The Four Steps to the Epiphany.
In fact, if I could assign homework to random people, I'd assign re-reading that book as homework to any and every body who's tempted to write another blog post commenting on this subject. :-)
Just to re-iterate: A couple of the major tenets of the Lean Startup approach are to learn continuously, and specifically by gaining validated learning, AND to eliminate waste, by not building something nobody wants. Ergo, a true MVP represents the intersection of the least you can build and still gain some useful, validated learning (context matters here, see above about established markets, vs entirely new products), while avoiding building stuff in advance, that will ultimately become waste.
That's it... nothing requires your MVP to be incomplete, buggy, shitty-looking, unstable, or any of those other things... BUT, and this is a key but, it might actually be any of those things, IF it can be and still meet the above goals!
Also nothing about the methodology per-se requires you to launch your MVP to the entire world from day one. Ok, maybe there's something about your scenario that dictates that the ONLY way you can gain any validated learning is through a worldwide launch to the public... I don't know, it's your startup not mine. But for most of us, MVPs are meant to be shown to a handpicked set of early prospective customers, preferably ones who have already been through the earlier stages of the Customer Development process with you.
Edit: To be fair to the original author, the title does specifically mention that he's referring to "competitive markets" and I do acknowledge that the exact criteria for your MVP may vary when you're entering an existing market. The one point I'll add about that, is that while Customer Development and the Lean Startup approach still apply in this setting, they seem to be most optimized for startups that are creating entirely new markets for radically new products.
The point of the article, as I read it, is exactly that many people are misunderstanding the MVP to mean just tossing up a bunch of half-assed "products" to see if they stick. I don't think you're really in such fundamental disagreement. The idea is that, for a lot of people, the emphasis needs to shift back to the "viable" part of MVP.
+1 on being sick of correcting people who shit on these concepts while defining them as the opposite of what they actually are.
"Of the several articles decrying the MVP...", not sure that's what's going on here.
It just seems like, over the past week or so, there have been multiple articles touching on this topic, where the article itself - or a number of the comments - seem to disparage the idea of MVPs. Maybe I'm reading too much into it, it's just something I seem to have noticed as a pattern recently.
As time goes on The Lean Startup thing is starting to look a lot like the lifecycle Agile went through doesn't it?
- A good idea comes along that makes a lot of sense
- Starts to gain traction
- Some people get a bit too religious about it which annoys some other people.
- Some do it well and lots do it badly
- The annoyed people try use the examples of it done badly to make generalisations about it, smear its name and generally miss the point entirely.
- on and on we go
- A good idea comes along that makes a lot of sense
- Starts to gain traction
- Some people get a bit too religious about it which annoys some other people.
- Some do it well and lots do it badly
- The annoyed people try use the examples of it done badly to make generalisations about it, smear its name and generally miss the point entirely.
- on and on we go
Good point. :-)
Why do people keep writing articles bitching about the shortcomings of MVP filled with examples that clearly miss the "viable" part?
It's like reading about people complaining BLT sandwiches have no meat if you leave out the bacon...
Am I missing something?
It's like reading about people complaining BLT sandwiches have no meat if you leave out the bacon...
Am I missing something?
They're complaining about everyone else missing the "viable" part.
An important distinction, at least in my definition of MVP, is that you're flexing on scope, not quality. If you release crap, you can't accurately assess the viability of your idea. If you release a quality product that does one or two things really well then you can measure product market fit and start iterating on new functionality. By restricting scope, you give yourself a better chance of getting to that point.
As @alexmturnbull suggests, the equation is a little different when your scope is large just to be a contender in a space.
As @alexmturnbull suggests, the equation is a little different when your scope is large just to be a contender in a space.
Preach! ...I would add that there's a great deal of emotional complexity involved in great product design, and its easier said than done to determine correctly what is "viable" from what isn't for an initial launch product - even if its well tested (while I understand @alexturnbull isn't saying testing is bad, nor is he saying MVPs are inherently inappropriate or obsolete). That said, many of these "viable" touch-points are often intangibles - not discrete interactions, features or functional benefits, and this is something that can be really costly to get right. Hard to beef with the argument he's making specific to competitive markets. Its absolutely costly to enter competitive markets... Many product authors continue to miss the mark for what is MVP because these same "mission critical products" are getting more and more sophisticated, and consumer expectations are being raised all the time.
This probably won't be a popular opinion here, but anyone using the term "MVP" has always set off red flags of failure for me. The best products come from people who are in love with technology scratching their own itch.
People wanting to "do a startup" are most likely in for a world of hurt. If you're not writing code on a daily basis (because that's what you do!) and eventually writing code to solve a problem you're having, or just cause you have a cool idea, then the likelihood of success is basically nil.
People wanting to "do a startup" are most likely in for a world of hurt. If you're not writing code on a daily basis (because that's what you do!) and eventually writing code to solve a problem you're having, or just cause you have a cool idea, then the likelihood of success is basically nil.
Following the Lean Startup approach isn't incompatible with scratching your own itch, or with having passion or whatever. It's just a way to avoid wasting a ton of time and money building something that ultimately fails because nobody wants it.
Now if you look at a project through the lens of "even if it fails as a company, I win anyway because of the lessons I learned from building it" or something similar, then I could see the argument for disregarding this approach. But the idea really just reduces to "build what you want to build, but do it iteratively and combine some validated learning about your market along with your development."
Now if you look at a project through the lens of "even if it fails as a company, I win anyway because of the lessons I learned from building it" or something similar, then I could see the argument for disregarding this approach. But the idea really just reduces to "build what you want to build, but do it iteratively and combine some validated learning about your market along with your development."
Indeed, the lens is what I'm talking about. I'd go so far as to argue that you should never approach a new project as a potential company and instead just build things you find fun/useful/novel. The greatest successes (financially, world impact) I've seen have been from developers making cool projects. These eventually got traction and the developer had investors... beating down the door. At that point the project turned into a company (although not one that had revenue). Growth continued because the products were awesome and eventually led to massive acquisitions.
You could argue that they hit their MVP and that's when everything took off but the mindset was definitely "I'm going to build something cool" opposed to "I'm going to build an MVP so I can have a startup".
These founders eventually left post-acquisition and have since continued to crank out new projects without regard to commercial viability. Not what the business schools teach but they have "won" so I don't think they care.
You could argue that they hit their MVP and that's when everything took off but the mindset was definitely "I'm going to build something cool" opposed to "I'm going to build an MVP so I can have a startup".
These founders eventually left post-acquisition and have since continued to crank out new projects without regard to commercial viability. Not what the business schools teach but they have "won" so I don't think they care.
That's not so different from the way I'm approaching the startup I'm working on. It did start as something that I just thought would be cool to work on, and everything is open-source, and I definitely figure that I win from doing the project no matter whether it becomes commercially successful or not.
That said, I feel like it is something that has a chance commercially, and we are actually employing the Customer Development / Lean Startup model to things. I don't necessarily see that as incompatible with "doing cool stuff." I'm just prioritizing the "cool stuff" a little, based on feedback from potential customers. That's a sacrifice that I, personally, can live with. YMMV. :-)
That said, I feel like it is something that has a chance commercially, and we are actually employing the Customer Development / Lean Startup model to things. I don't necessarily see that as incompatible with "doing cool stuff." I'm just prioritizing the "cool stuff" a little, based on feedback from potential customers. That's a sacrifice that I, personally, can live with. YMMV. :-)
MVP doesn't really apply to VC financing in my opinion. Or, it does, but it stands for "Minimum Viable Pitch".
The whole POINT of a lean startup is not to go running for cash the instant you think you have a good idea. With today's scalable cloud platforms that start at zero dollars, low cost or free development environments, and plenty of freelance help when you need it, WHY do people still think they need $10 million to launch a website or build an app?
Especially their first one?
I contend that if you are building a product for the sole purpose of taking a juicy exit, then you are just taking part in the gold rush (and he's right, it is a gold rush). In that case, no amount of practical advice applies to you, because if you're being honest with yourself, your whole mission is to create the "Minimum Viable Pitch" that gets the VCs interested and then hang around long enough to get acquired.
And that has nothing to do with creating really good stuff.
Here's an idea: think of something you HAVE to build because you can't wait to start using it yourself. Define the "Minimum Viable Product" as that thing you have to build before you can start happily using it yourself. Now, go show it off. If people are interested, sell it or put in ads or whatever you have to do.
If it starts going like gangbusters and you need financing to grow or else you're really going to start pissing your customers off, then go looking for money with your now very REAL track record in hand. You know, because at this point you really NEED that money.
Seems like common sense to me. Also seems a lot more authentic and ethical.
But what if you really ARE building the next Facebook and need $50 million to spend on servers and office space and Aeron chairs and....
Well that's probably not your first startup, so nothing in the article is news to you anyway. If it IS your first startup, you crazy.
The whole POINT of a lean startup is not to go running for cash the instant you think you have a good idea. With today's scalable cloud platforms that start at zero dollars, low cost or free development environments, and plenty of freelance help when you need it, WHY do people still think they need $10 million to launch a website or build an app?
Especially their first one?
I contend that if you are building a product for the sole purpose of taking a juicy exit, then you are just taking part in the gold rush (and he's right, it is a gold rush). In that case, no amount of practical advice applies to you, because if you're being honest with yourself, your whole mission is to create the "Minimum Viable Pitch" that gets the VCs interested and then hang around long enough to get acquired.
And that has nothing to do with creating really good stuff.
Here's an idea: think of something you HAVE to build because you can't wait to start using it yourself. Define the "Minimum Viable Product" as that thing you have to build before you can start happily using it yourself. Now, go show it off. If people are interested, sell it or put in ads or whatever you have to do.
If it starts going like gangbusters and you need financing to grow or else you're really going to start pissing your customers off, then go looking for money with your now very REAL track record in hand. You know, because at this point you really NEED that money.
Seems like common sense to me. Also seems a lot more authentic and ethical.
But what if you really ARE building the next Facebook and need $50 million to spend on servers and office space and Aeron chairs and....
Well that's probably not your first startup, so nothing in the article is news to you anyway. If it IS your first startup, you crazy.
MVPs in Competitive/Established markets need to be exploring new solutions to the problem area, ideally with a chance of having a 10x+ improvement over established solutions. They shouldn't be poor replications of an established player with traction.
The point of an MVP is to learn about a market/problem-area. If there are established players, it's easier and less expensive to learn from them. The goal is to learn as much about the market/problem-area as fast as possible. In new markets, that usually requires a MVP. In established markets, that might require an MVP testing a new solution. If the goal is to compete in an already competitive market that demands a polished solution, anything less is likely to fail.
The point of an MVP is to learn about a market/problem-area. If there are established players, it's easier and less expensive to learn from them. The goal is to learn as much about the market/problem-area as fast as possible. In new markets, that usually requires a MVP. In established markets, that might require an MVP testing a new solution. If the goal is to compete in an already competitive market that demands a polished solution, anything less is likely to fail.
I think the rhetoric around MVP all boils down to market maturity...
MVP: If you are in a brand new market with few competitors you should put out an MVP. You will likely beat your competitors to the punch on visibility and customers will be willing to pay because of the relatively few quality alternatives.
No-MVP: If you are in a mature market your MVP will get you nowhere because there will be many competitors already there who are already competing with very mature products. (Ex. how many people will buy your MVP car made out of a hunk of steel, wheels, and a mower engine... 0 people)
So why all this talk of MVP...
Because many of the tech and startup markets of the last 5-10 years are maturing.
If you are creating a Fart iPhone app - that thing better be polished and be the best damn fart app because that market has become mature (well i suppose the wrong word choice but you get my drift).
On the other hand, if you are creating an iPhone app that lets you control your microwave, an MVP version would most likely be beneficial because its unknown if there is even all that much of a market for that.
MVP: If you are in a brand new market with few competitors you should put out an MVP. You will likely beat your competitors to the punch on visibility and customers will be willing to pay because of the relatively few quality alternatives.
No-MVP: If you are in a mature market your MVP will get you nowhere because there will be many competitors already there who are already competing with very mature products. (Ex. how many people will buy your MVP car made out of a hunk of steel, wheels, and a mower engine... 0 people)
So why all this talk of MVP...
Because many of the tech and startup markets of the last 5-10 years are maturing.
If you are creating a Fart iPhone app - that thing better be polished and be the best damn fart app because that market has become mature (well i suppose the wrong word choice but you get my drift).
On the other hand, if you are creating an iPhone app that lets you control your microwave, an MVP version would most likely be beneficial because its unknown if there is even all that much of a market for that.
I think you're misunderstanding "minimum viable" part of MVP.
"minimum viable" != "shitty", it means the bare minimum that is required to gain the validated learning in the product's market context. In a mature market, a product will generally have to be more polished to reach viability..
"minimum viable" != "shitty", it means the bare minimum that is required to gain the validated learning in the product's market context. In a mature market, a product will generally have to be more polished to reach viability..
I think thats exactly what Im saying
The MVP is not dead. Crappy MVP's are dead. Totally agree with @avand, it's about scope vs. quality. Quality is where the "V" comes in. But I also agree with the author, in that private beta is the way to go if you are launching an MVP. That's what I'll be doing in about a month with my iOS app
yep. yep.
"groovehq.com"
Maybe I should know this, but are these guys some kind of 37signals offshoot, or have they just copied the 'hq' thing?
>Groove is a hosted customer support and engagement platform that helps companies manage customer support across all types of channels - email, web, live chat, mobile, Twitter and more.
Tells me nothing. Nobody signed their name to this piece of whatever, and I have no idea why I should be paying any attention to it. Who are they, and why are their obviously self-submitted pontifications worth my time?
http://news.ycombinator.com/submitted?id=alexmturnbull
Maybe I should know this, but are these guys some kind of 37signals offshoot, or have they just copied the 'hq' thing?
>Groove is a hosted customer support and engagement platform that helps companies manage customer support across all types of channels - email, web, live chat, mobile, Twitter and more.
Tells me nothing. Nobody signed their name to this piece of whatever, and I have no idea why I should be paying any attention to it. Who are they, and why are their obviously self-submitted pontifications worth my time?
http://news.ycombinator.com/submitted?id=alexmturnbull
don't hate the playa, hate the game.
If you know the problem you're solving and how to solve it well (i.e. product-market fit), then you shouldn't waste your time on a hack MVP. Build something awesome.
Unfortunately, the majority of work for a startup is about finding product-market fit. A la Steve Blank, a new product rarely survives first contact with customers. As such, spending too much time on something that will inevitably be changed doesn't make much sense.
Also, some people who are testing out ideas are probably just exploring, playing with the idea in their own head. It helps to send something out to friends simply to generate conversation and get quick feedback.
Don't hate.
Unfortunately, the majority of work for a startup is about finding product-market fit. A la Steve Blank, a new product rarely survives first contact with customers. As such, spending too much time on something that will inevitably be changed doesn't make much sense.
Also, some people who are testing out ideas are probably just exploring, playing with the idea in their own head. It helps to send something out to friends simply to generate conversation and get quick feedback.
Don't hate.
Groove™ huh? Aren't you infringing on Microsoft's trademark?
http://en.wikipedia.org/wiki/Microsoft_Groove
http://en.wikipedia.org/wiki/Microsoft_Groove
Speaking of solutions in search of a problem...
2) The cycle of expectations that your product needs to be as feature rich as your competition on day one leads to what Eric Ries calls the large batch death spiral where it always seems like a good idea to add that one last feature (I've been there, it's painful, and really difficult to pull out of).
3) RE: fear of ruining your reputation if your MVP isn't shiny enough-- good news: no one knows who you are when you launch, so you have nothing to lose. Don't launch your MVP in the press, court early adopters, listen to your customers, and focus on building value until your product kicks the competition's ass. If you hide from customers out of fear you take the biggest risk of all: building something no one wants. Even if you have the best product idea in the world, the only way to know if the features you add are having a positive impact is to measure the behavior of real, live, human users.
Unfortunately I think what we're seeing is the lean startup backlash where people use the terms but don't really take the time to understand what they mean. The Lean startup movement is a powerful set of lessons that can empower entrepreneurs and save us from wasting our time and effort building the wrong things and chasing the wrong metrics, but maybe some of the lessons just have to be learned painfully through experience.