When MVPs Hurt

"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.

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...

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.

Would you say that the MVP code should be thrown away when building the actual product?

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.