When to sacrifice design for speed in product management

The war between design and speed is probably as old as product management itself (believe it or not, product management has been a thing since the 1930s!) We’ve all been there, staring at a looming deadline, a backlog of features, and a team that’s burning out — often, not just figuratively — and you start questioning the scope of the actual project. Which things are worth trimming, compromising on, or simply cutting off entirely in favor of speed?

How much MVP is too MVP?

Things will always need to be compromised on, especially as we start understanding the cost of delay. I’m all for moving fast, as long as fast does not start compromising actual quality and value. This is why I have a love-hate relationship with the term MVP. On one hand, it allows you to test assumptions and gather user feedback without over-investing. On the other, if your MVP is too “minimal,” it might not provide enough value to your users, rendering any feedback moot.

That is, unfortunately, where most product building goes wrong. We tend to take the “minimal” a bit too seriously, compromising value far too much. It’s really time to drop the notion of move fast and break things, especially when that results in subpar products and features that provide no actual value and are just there to satisfy some HiPPO’s shiny object syndrome.

When it comes to product management, “minimal” can mean vastly different things depending on your environment. In a…