This makes me a little bonkers.<p>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."<p>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.
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.<p>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.<p>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.
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”.<p>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]<p>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.<p>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.<p>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.<p>[1] <a href="https://www.ycombinator.com/library/4Q-a-minimum-viable-product-is-not-a-product-it-s-a-process" rel="nofollow">https://www.ycombinator.com/library/4Q-a-minimum-viable-prod...</a><p>[2] <a href="https://hackernoon.com/the-mvp-is-dead-long-live-the-rat-233d5d16ab02" rel="nofollow">https://hackernoon.com/the-mvp-is-dead-long-live-the-rat-233...</a>
MVPs hurt when you cut corners (don't write tests) and mock functionality, then show the result to the business.<p>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.
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).<p>We decided to build the core technology and go after some very easy wins first, while laying the foundation for bigger, more complicated wins.<p>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.<p>(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.<p>(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).<p>(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.
The "launch fast, fail fast way(launch an MVP and iterate it)" is to optimize for the company and investor, not the customer.<p>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.<p>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.
<i>> 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.</i><p>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.<p>For a modernization project, if the riskiest parts are the 'hard bits', then your modernization MVP should absolutely tackle those first.<p>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?<p>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?<p>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.<p>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.<p>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.