What is the right way to build products? Earlier in my career, I would have told you everything should be AB tested, and that you should build only as little as you need to validate a hypothesis. Every problem should have user research involved at the beginning, aligned on the problem instead of just validating or invalidating solutions. Every key result should be outcome based. Every engineer, designer and product manager on the team should be involved in defining the problem and the solution. These are all good ideas. However, once you add enough of these “best practices” up, it reads kind of like those articles talking about the morning habits of the most successful people in the world. If you actually try to follow all of those habits, it would take you six hours a day and cost a lot of money.

In particular, his post is focused on how many PMs reflexively reach for the MVP framework when building new features, even though it is often not the right approach for the situation.

I have definitely been guilty of this!

I often bias towards all new work being a ‘V0’, to being the hacked together, to being the minimum necessary to get to some value. The reason this is so often my bias is - as anyone that’s ever worked in software knows - that things always take longer than you expect, and so if you can limit the size of the project you leave yourself with more buffer for delays. Basically all projects have (let’s say) 30% more work than you anticipated. This is why it’s better to keep your projects short: if you keep the scope down to what can be delivered in 3 weeks, adding on an additional week in delay is not too painful. However if you had a 3 month project, that extra month is going to hurt...

The other benefit of the MVP framework is that the less you invest in up-front work, the less you’re risking in case your hypothesis is wrong. This is an argument for biasing more towards the scrappy MVP when you have higher uncertainty. However if you are confident in your hypothesis (for example, because you have prior evidence), this is less important.

For ideas you’re confident about, this is not to say that you do not need to work in iterations - you do! Shorter iterations leave less opportunity for unexpected problems to arise. It just means that the purpose of your initial iteration is focused on actually delivering value rather than proving a concept.