Five mistakes teams make with scoping an MVP

Teams tend to reach for this after something has already gone wrong. These are the ones we run into repeatedly when we audit scoping an MVP.

The projects that go badly are rarely the ones with the hardest technical problems. It is the sort of thing that looks like polish right up until it costs you an enquiry.

Where it usually goes wrong

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Minimum means uncomfortable, viable means it works
• Cut features, not quality
• Never checking whether the fix actually worked

The point is to learn something specific. The teams that handle this well are rarely the ones with the biggest budgets. It is the sort of thing that looks like polish right up until it costs you an enquiry.

Making it stick

The short version

Strategy work is mostly deciding what not to do, and writing it down so it stays decided. Three things worth confirming about scoping an MVP before you move on:

• Someone can say what the current setup is without going to look
• Minimum means uncomfortable, viable means it works — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Worth checking on your own setup before it becomes someone else's problem to fix.