When MVPs Hurt
builtin.com
builtin.com
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.
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.
This framing allows people to speak more freely about their fears.
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.
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.
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...
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".
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?
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.
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.
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.
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.
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"?
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.
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.
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.
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.
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.
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"?
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
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.
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.
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.