When MVPs Hurt(builtin.com)
builtin.com
When MVPs Hurt
https://builtin.com/software-engineering-perspectives/when-mvps-hurt
13 comments
Oh, and if your project hasn't explicitly thought through the risk, you may find out your biggest risk the hard way. If the team hasn't discused it, here's what I suggest:
Set up a 1-hour meeting. For the pre-reading, google a couple of articles on the kinds of risk to software projects. For the meeting, explain the goal is to find the the current top 5 risks. Open up a Google Sheet, label one column "Risk", and have everybody spend 10-15 minutes filling the column in. Then add a column called "Votes", and have everybody increment the votes counter by 1 for what they see as the top 5. Now sort by votes.
If people already agree on the top 5, great. If not, you'll need to get more consensus around the risk. One way to do that is to add two more columns called "Odds" and "Impact". (You can use H/M/L or 0-10 for most people; an especially numerate audience can use actual odd and actual cost.) Jointly fill those in, getting people to discuss why they would pick different things.
Once you have adequate consensus, move on to discussing them and how to mitigate them. Hopefully you end up with specific action items (which can include an MVP!). Then come back in 1-3 months to do it again; hopefully your big risks will go away and you'll have new risks. If you're lucky, the meeting will become unnecessary over time.
Set up a 1-hour meeting. For the pre-reading, google a couple of articles on the kinds of risk to software projects. For the meeting, explain the goal is to find the the current top 5 risks. Open up a Google Sheet, label one column "Risk", and have everybody spend 10-15 minutes filling the column in. Then add a column called "Votes", and have everybody increment the votes counter by 1 for what they see as the top 5. Now sort by votes.
If people already agree on the top 5, great. If not, you'll need to get more consensus around the risk. One way to do that is to add two more columns called "Odds" and "Impact". (You can use H/M/L or 0-10 for most people; an especially numerate audience can use actual odd and actual cost.) Jointly fill those in, getting people to discuss why they would pick different things.
Once you have adequate consensus, move on to discussing them and how to mitigate them. Hopefully you end up with specific action items (which can include an MVP!). Then come back in 1-3 months to do it again; hopefully your big risks will go away and you'll have new risks. If you're lucky, the meeting will become unnecessary over time.
It's not always easy for team members to openly discuss risk. The pre-mortem technique can help with that. Basically, it comes down to imagining being in a future where the project has failed miserably and asking team members to look back and identify what has gone wrong.
This framing allows people to speak more freely about their fears.
This framing allows people to speak more freely about their fears.
Great point. I haven't tried that technique, but it sounds like a great way to get people to productively examine their fears.
MVP is commonly used in agile development in the way the article talks about it. Products in the agile world are often features and not products.
Ok? It's an incorrect usage. As somebody who was in on "Agile" since before it was "Agile", I'd say much of what happens in the "Agile" world is an incorrect usage. So it's no surprise to me that another term has been misappropriated.
The key concept has been widely adopted by the agile community. I have encountered the problem where project managers have mixed the startup MVP concept and the agile MVP concept up though. So, I guess you have a fair point.
Again, so? The "agile community" has adopted the notion of a "daily standup" where nobody actually stands up anymore. The "agile community" doing something a particular way isn't proof that they're doing it right. Indeed, given that the "agile community" these days seems to mostly consist of non-agile companies agile terms for non-agile activity, I'd argue it's evidence the other way.
yes the author has taken it way out of context. imagine if auto manufacturers produced MVP vehicles without seatbelts etc.
Modernization isn't about product features, it is about architecture. The reason it is hard is because many legacy systems never separated their application layers, making it difficult to just migrate the database (for example) without also migrating APIs and business layers, even all the way up to the UI.
Non-separated layers is what causes people to start to pick and choose features. I've been modernizing platforms for about 15 years now, and my first move is always to identify and correct the areas in the app where the layers are intertwined. Even if that is a 2 year effort, it builds up to a day when you can just pick a layer and move it, and it isn't hard anymore.
But those projects are not about MVPs, or features, or product prioritization. It is nothing but pure tech debt - keeping the lights on for the customers while you work hard to change everything under the covers without impacting them.
Non-separated layers is what causes people to start to pick and choose features. I've been modernizing platforms for about 15 years now, and my first move is always to identify and correct the areas in the app where the layers are intertwined. Even if that is a 2 year effort, it builds up to a day when you can just pick a layer and move it, and it isn't hard anymore.
But those projects are not about MVPs, or features, or product prioritization. It is nothing but pure tech debt - keeping the lights on for the customers while you work hard to change everything under the covers without impacting them.
Couldn’t agree more.
Plowing through this atm, about 10 months in…
In my experience, layers love to get intertwined in, so called, standard systems.
You end up with a business not really in control of its processes and developers who are experts in non-business domain data models and dsl/code abstractions.
What you wrote really hit it on the head for me in my current position.
Plowing through this atm, about 10 months in…
In my experience, layers love to get intertwined in, so called, standard systems.
You end up with a business not really in control of its processes and developers who are experts in non-business domain data models and dsl/code abstractions.
What you wrote really hit it on the head for me in my current position.
Of course there is useful insight here but it still irks me that MVP has become the word for “product with a bunch of features chopped out”.
MVPs are meant to be a business process where you try to validate your business idea as quickly as possible. It is not an actual product. [1]
I completely agree with the author in terms that an MVP should be used to test the riskiest assumptions of the work to be carried out. People seem to have forgotten about that aspect of the MVP and have instead focused on the speed aspect.
I quite like the idea of replacing MVPs with RATs (riskiest assumption test) [2] to stop the misunderstandings that come from MVP having the word “product” in it. Of course the reason for that is to focus the mind on selling from the start but it seems to have added new misunderstandings.
I may just be an old fogey complaining about what words used to mean and need to deal with the reality that language is dynamic, but it seems like it causes a whole load of issues when the important mental model goes missing.
[1] https://www.ycombinator.com/library/4Q-a-minimum-viable-prod...
[2] https://hackernoon.com/the-mvp-is-dead-long-live-the-rat-233...
MVPs are meant to be a business process where you try to validate your business idea as quickly as possible. It is not an actual product. [1]
I completely agree with the author in terms that an MVP should be used to test the riskiest assumptions of the work to be carried out. People seem to have forgotten about that aspect of the MVP and have instead focused on the speed aspect.
I quite like the idea of replacing MVPs with RATs (riskiest assumption test) [2] to stop the misunderstandings that come from MVP having the word “product” in it. Of course the reason for that is to focus the mind on selling from the start but it seems to have added new misunderstandings.
I may just be an old fogey complaining about what words used to mean and need to deal with the reality that language is dynamic, but it seems like it causes a whole load of issues when the important mental model goes missing.
[1] https://www.ycombinator.com/library/4Q-a-minimum-viable-prod...
[2] https://hackernoon.com/the-mvp-is-dead-long-live-the-rat-233...
"product with a bunch of [essential] features chopped off" is the most frustrating aspect of MVPs being misused.
The scenario I've seen loads with existing legacy systems is analogous having a decent but aging car, then some upstart waltzes in and pitches an MVP approach, only for the aging car to be replaced by an underpowered scooter, completely lacking boot space or whatever other essential requirement there is, but you cannot argue that this isn't acceptable "because MVP".
The scenario I've seen loads with existing legacy systems is analogous having a decent but aging car, then some upstart waltzes in and pitches an MVP approach, only for the aging car to be replaced by an underpowered scooter, completely lacking boot space or whatever other essential requirement there is, but you cannot argue that this isn't acceptable "because MVP".
Would you say that the MVP code should be thrown away when building the actual product?
If you built a proto as fast as possible to test hypothesis ? yes.
IME it's always been a mistake to keep the MVP's codebase (and a pure catastrophy when said codebase is dumped on another team)
Why throw it all away? If you use the bog standard components while building the MVP (and if you are bulding it as fast as you can why would you use non-standard stuff?), then you should be able to simply replace the "NotImplementedException" parts with the implementations and keep using the same codebase.
I mean, unless your MVP is a Bash script that emits a HTML page and sends an email via telnet, plus a CGI wrapper using a hand-rolled HTTP server ... why would you throw away the working and validated parts?
I mean if you use super dirty JS (Express) and jQuery ... then great, you can refactor that to use TS and plop the frontend code into components in whichever framework you like (Angular, React, Vue).
But again, these standard frameworks have a ton of "starter projects" on GitHub. Why not just start with those?
I mean, unless your MVP is a Bash script that emits a HTML page and sends an email via telnet, plus a CGI wrapper using a hand-rolled HTTP server ... why would you throw away the working and validated parts?
I mean if you use super dirty JS (Express) and jQuery ... then great, you can refactor that to use TS and plop the frontend code into components in whichever framework you like (Angular, React, Vue).
But again, these standard frameworks have a ton of "starter projects" on GitHub. Why not just start with those?
Because chances are that in building that MVP you’ve rampaged around a domain you didn’t yet understand. And that’s fine. Expected, even.
Now your APIs are a mess. You have view details in the DB and pieces of business logic strewn across the frontend. There’s no separation of concerns because your only concern was to validate an idea. And for some unknown reason the only test you have keeps breaking because it doesn’t handle dates properly.
Previous mistakes inform future decisions. Best set it all alight.
The hardest part is understanding a problem anyway. The second try will take slightly more time but it won’t fall apart for no apparent reason.
Now your APIs are a mess. You have view details in the DB and pieces of business logic strewn across the frontend. There’s no separation of concerns because your only concern was to validate an idea. And for some unknown reason the only test you have keeps breaking because it doesn’t handle dates properly.
Previous mistakes inform future decisions. Best set it all alight.
The hardest part is understanding a problem anyway. The second try will take slightly more time but it won’t fall apart for no apparent reason.
Rewriting the MVP immediately leads to the dangers of second system syndrome.
Fixing the obvious problems is obviously needed. But refactoring is the way instead of doing the MVP again. After all the domain is still barely understood.
Fixing the obvious problems is obviously needed. But refactoring is the way instead of doing the MVP again. After all the domain is still barely understood.
MVPs hurt when you cut corners (don't write tests) and mock functionality, then show the result to the business.
Because often, they will like what they see and want to go full steam ahead, by which time it's too late to explain you actually need another couple of months to get to the position they thought you were already at.
Because often, they will like what they see and want to go full steam ahead, by which time it's too late to explain you actually need another couple of months to get to the position they thought you were already at.
An MVP is supposed to actually work (be viable) and be something that you can actually put in front of users to test your business hypothesis.
If you present a demo where all functionality is mocked as an "MVP" to business and they think it really is an MVP, that is a reasonable assumption in my view. If it turns out it's not viable at all, can't be sold as a product to anyone, and doesn't actually work, that seems like you misused the term "MVP".
They want to go full steam ahead because at best there's been a miscommunication about the term "MVP". At worst they'll think you were lying to them.
It's really important to have clear communication and definitions of "accepted" terms which are sometimes used inaccurately.
If you present a demo where all functionality is mocked as an "MVP" to business and they think it really is an MVP, that is a reasonable assumption in my view. If it turns out it's not viable at all, can't be sold as a product to anyone, and doesn't actually work, that seems like you misused the term "MVP".
They want to go full steam ahead because at best there's been a miscommunication about the term "MVP". At worst they'll think you were lying to them.
It's really important to have clear communication and definitions of "accepted" terms which are sometimes used inaccurately.
That's the distinction between an MVP and a Prototype. While it can be useful to put together a hack and slash version, it needs to be marketed as such. Shameless plug, but I wrote about this exact thing: https://www.machow.ski/posts/galls-law-and-prototype-driven-...
> An MVP is supposed to actually work (be viable) and be something that you can actually put in front of users to test your business hypothesis.
Agreed, few of the comments in this thread seem to be throwing the 'V' of the MVP out the window.
It's not another word for a mock up or a proof of concept, and when did it start being a "process" instead of a "thing"?
Agreed, few of the comments in this thread seem to be throwing the 'V' of the MVP out the window.
It's not another word for a mock up or a proof of concept, and when did it start being a "process" instead of a "thing"?
They can also hurt the other way when the business is sold on the concept, but the MVP implementation is a lot less impressive than the concept.
I had a related experience with an MVP gone awry. We were building a product that had an entrenched competitor (let’s set aside whether that was a good idea in itself).
We decided to build the core technology and go after some very easy wins first, while laying the foundation for bigger, more complicated wins.
I thought this was a fairly sound plan at the time but we hit three problems that would make me rethink such an approach in the future.
(1) the “easy” use case ended up being significantly harder than expected. I’d guess it took 4x longer to ship than expected, which allowed doubt in the project to run rampant.
(2) the easy wins were smaller than expected (it didn’t help that the system we were augmenting already had some of the features we were building, just implemented in a more ad-hoc fashion).
(3) the more complex and profitable features required significantly new features in the core, the implementation of which had become very complex and the design compromised during the process of shipping the late, underwhelming MVP, and at that point there was no more appetite to continue investing in this technology.
We decided to build the core technology and go after some very easy wins first, while laying the foundation for bigger, more complicated wins.
I thought this was a fairly sound plan at the time but we hit three problems that would make me rethink such an approach in the future.
(1) the “easy” use case ended up being significantly harder than expected. I’d guess it took 4x longer to ship than expected, which allowed doubt in the project to run rampant.
(2) the easy wins were smaller than expected (it didn’t help that the system we were augmenting already had some of the features we were building, just implemented in a more ad-hoc fashion).
(3) the more complex and profitable features required significantly new features in the core, the implementation of which had become very complex and the design compromised during the process of shipping the late, underwhelming MVP, and at that point there was no more appetite to continue investing in this technology.
> I’d guess it took 4x longer to ship than expected, which allowed doubt in the project to run rampant.
Isn't that an MVP working as it should? Implement something small, realize the whole project is _much_ more complicated than expected, and therefore realizing it's a bad plan after investing 'MVP' sized money rather than 'full project' sized money?
Formulated otherwise, you haven't wasted X in building a useless MVP, rather you invested X in gaining knowledge that saved the company 10X (or 100X) by not investing in the wrong thing.
Isn't that an MVP working as it should? Implement something small, realize the whole project is _much_ more complicated than expected, and therefore realizing it's a bad plan after investing 'MVP' sized money rather than 'full project' sized money?
Formulated otherwise, you haven't wasted X in building a useless MVP, rather you invested X in gaining knowledge that saved the company 10X (or 100X) by not investing in the wrong thing.
The "launch fast, fail fast way(launch an MVP and iterate it)" is to optimize for the company and investor, not the customer.
Investor wanna see the MVP and traction because they want to de-risk a "deal". Most of the VCs care more about who is you lead investor than the potential upside of the product. As a founder, you need to de-risk your future by truly validate your product hypothesis.
The Lean approach will lead you to very incremental solutions or even make you run around in circles achieving nothing. It lowers the cost of failure (downside), but also the potential impact of success (upside). This approach determines your mindset as a product designer and destroys your potential product/business upside upfront.
Investor wanna see the MVP and traction because they want to de-risk a "deal". Most of the VCs care more about who is you lead investor than the potential upside of the product. As a founder, you need to de-risk your future by truly validate your product hypothesis.
The Lean approach will lead you to very incremental solutions or even make you run around in circles achieving nothing. It lowers the cost of failure (downside), but also the potential impact of success (upside). This approach determines your mindset as a product designer and destroys your potential product/business upside upfront.
"Difficult part first" is the right approach for legacy migration, or any mandated enterprise dev, to surface tricky issues ASAP. MVP is about product market fit, which is a given via mgmt authority in a corp environment.
It still makes sense to start with the core business values then go up with nice to have features.
Compexity comes sometimes from not so important features that could take much longer to migrate. But of course some of these features are why some products are picked over others in the first place, however this requires a case study and more analysis.
Compexity comes sometimes from not so important features that could take much longer to migrate. But of course some of these features are why some products are picked over others in the first place, however this requires a case study and more analysis.
> That’s why I tend to gravitate towards starting migrations with the harder parts of the system. It’s a more challenging project, yes — but you will never have more resources and more support for a modernization effort than you do in the very beginning. The hard bits won’t be any easier months or years later.
It should be no surprise that 5his advice is entirely in the spirit of the MVP. MVPs are supposed to de-risk your startup, and you should therefore always tackle the highest risk part of your plan. If the highest risk part is customer acquisition based on your UVP, buy some advertising and see if potential users click 'buy'. If it is retention, you need an app that they use, or a Wizard of Oz prototype. If it is technical feasibility, you need to build a POC.
For a modernization project, if the riskiest parts are the 'hard bits', then your modernization MVP should absolutely tackle those first.
In practice, though, the riskiest part of a modernization effort is usually whether you have enough political capital to see it through. Or to put it another way, whether there is enough buy-in by management. Which often means that you should first tackle the most recalcitrant parts of the organization that have to sign off on it.
It should be no surprise that 5his advice is entirely in the spirit of the MVP. MVPs are supposed to de-risk your startup, and you should therefore always tackle the highest risk part of your plan. If the highest risk part is customer acquisition based on your UVP, buy some advertising and see if potential users click 'buy'. If it is retention, you need an app that they use, or a Wizard of Oz prototype. If it is technical feasibility, you need to build a POC.
For a modernization project, if the riskiest parts are the 'hard bits', then your modernization MVP should absolutely tackle those first.
In practice, though, the riskiest part of a modernization effort is usually whether you have enough political capital to see it through. Or to put it another way, whether there is enough buy-in by management. Which often means that you should first tackle the most recalcitrant parts of the organization that have to sign off on it.
The entire idea of a modernization project doesn't make sense to me. The author seems to be mixing in the MVP strategy used to validate product-market fit (which still has nothing to do with simple or easy, it's about lowest-cost value demonstration) with some sort of prototyping or technical spiking approach. Neither is pursuing "modernization", which is a valueless idea. You update things like architecture or implementation so that you can DO something with the result. It is not the end production.
Regardless, there need to be opportunities to re-evaluate decisions that don’t work out. Sometimes the project will need to backtrack as people discover what works and what doesn’t.
Since when is "MVP" an engineering term?
Also, if you're modernizing / migrating your stack, aren't you effectively NOT talking about an MVP anymore? I thought the first MVP was supposed to be a throwaway prototype used to validate (market, technical, UX) feasibility, and once you've validated, you can't consider it an "MVP" anymore?
I think there should be a new term for what she's talking about — maybe a "minimally stable product"?
Also, if you're modernizing / migrating your stack, aren't you effectively NOT talking about an MVP anymore? I thought the first MVP was supposed to be a throwaway prototype used to validate (market, technical, UX) feasibility, and once you've validated, you can't consider it an "MVP" anymore?
I think there should be a new term for what she's talking about — maybe a "minimally stable product"?
At my current employer, everything starts as an MVP. Everything. They even call it that.
We build an MVP and go from there. New project? MVP. New massive feature? That's an MVP, too. And we iterate on that. I guess it's just different terminology, or maybe I am way stupider than them
We build an MVP and go from there. New project? MVP. New massive feature? That's an MVP, too. And we iterate on that. I guess it's just different terminology, or maybe I am way stupider than them
I come to think that an MVP is only that, when after validating your product case. You scrap the mvp and build the product from scratch.
If you’re not able yo scrap what you have you aren’t validating product market fit, you are forcing a product onto the market.
If you’re not able yo scrap what you have you aren’t validating product market fit, you are forcing a product onto the market.
Not sure I agree with you. It’sa minimal product. It’s still something you can carry forward, improve on, and enhance.
Seems wasteful to build something only to scrap it once people say they want it.
I’m right now testing out demand for a headless CMS @ https://moogle.cc/nirvaancms.html and I’m not planning to redo the entire tech stack if there seems to be demand for such a product.
Seems wasteful to build something only to scrap it once people say they want it.
I’m right now testing out demand for a headless CMS @ https://moogle.cc/nirvaancms.html and I’m not planning to redo the entire tech stack if there seems to be demand for such a product.
> Seems wasteful to build something only to scrap it once people say they want it.
It can be. But you probably shouldn't build a product to test whether people in your chosen market say they want it, or to find out whether buyers or sellers are hardest to acquire to bootstrap a two-sided market, when you can probably validate that with some landing pages or user interviews.
If you need to test whether people will use it after buying (or perhaps which users will use it after buying, or how many users will keep using it and paying for it), you probably need to build something, but it may only need to be implemented using manual processes behind the scenes.
If you need to test whether you can serve the customer at scale for less than your cost to acquire them, that is a different sort of MVP.
In any case, there are definitely MVPs that can and should be scrapped when you are done using them to validate (or invalidate) whichever proposition is then your biggest source of risk.
Keep in mind that should you invalidate the hypothesis being tested, you may need to scrap the MVP anyway when you pivot away from that particular hypothesis. And, some of your hypotheses will be invalidated, so making sure you don't run out of resources for testing new ones is kind of important.
It can be. But you probably shouldn't build a product to test whether people in your chosen market say they want it, or to find out whether buyers or sellers are hardest to acquire to bootstrap a two-sided market, when you can probably validate that with some landing pages or user interviews.
If you need to test whether people will use it after buying (or perhaps which users will use it after buying, or how many users will keep using it and paying for it), you probably need to build something, but it may only need to be implemented using manual processes behind the scenes.
If you need to test whether you can serve the customer at scale for less than your cost to acquire them, that is a different sort of MVP.
In any case, there are definitely MVPs that can and should be scrapped when you are done using them to validate (or invalidate) whichever proposition is then your biggest source of risk.
Keep in mind that should you invalidate the hypothesis being tested, you may need to scrap the MVP anyway when you pivot away from that particular hypothesis. And, some of your hypotheses will be invalidated, so making sure you don't run out of resources for testing new ones is kind of important.
The MVP is a Lean Startup tool for exploring user needs in a startup context when the biggest risk is that you won't find product-market fit. (Which is the biggest risk for most startups.) It's a way of testing the hypothesis, "I think X is the basket of functionality needed to get users to keep using our product and get enough out of us that they'll happily pay us money."
If you're using it outside of that context, it's not an MVP. It's just a sparkling prototype. If your biggest risk is something other than product-market fit, please use a different risk mitigation strategy.