This makes me a little bonkers. 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 us…
When MVPs Hurt
31–37 of 37 posts
Re: When MVPs Hurt
#32It 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.
Re: When MVPs Hurt
#33I 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.
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.
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.
Re: When MVPs Hurt
#34Earlier quoted context omitted.
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 wrappe…
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…
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.
Re: When MVPs Hurt
#35This makes me a little bonkers. 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 us…
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.
Re: When MVPs Hurt
#36Earlier quoted context omitted.
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.
Re: When MVPs Hurt
#37Earlier quoted context omitted.
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.