Three myths about scoping an MVP

The gap between knowing this and actually doing it is where most teams lose ground. A few things about scoping an MVP that get repeated more often than they get checked.

Strategy work is mostly deciding what not to do, and writing it down so it stays decided. It is the sort of thing that looks like polish right up until it costs you an enquiry.

“It only matters for big sites”

Minimum means uncomfortable, viable means it works. The cost of getting this wrong is rarely visible on the day it happens. The version that survives contact with a real deadline is the simple one.

“We can deal with it after launch”

Sometimes true, usually expensive. The teams that handle this well are rarely the ones with the biggest budgets.

“Our platform handles it”

The point is to learn something specific. In practice this is a scheduling problem more than a technical one. It is the sort of thing that looks like polish right up until it costs you an enquiry.

The short version

The projects that go badly are rarely the ones with the hardest technical problems. Three things worth confirming about scoping an MVP before you move on:

• Someone can say what the current setup is without going to look
• The point is to learn something specific — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If any of that sounds like a description of your current setup, it is fixable.