Scoping an MVP

When a new client brings us a product idea, the first draft of the scope is usually three times bigger than what we end up building. That's normal. Everyone can picture the finished product, and it's tempting to build the picture.

The problem is that the finished product is a guess. Until real users touch it, you don't know which parts matter. So we push scope in one direction: what is the single riskiest assumption here, and what's the smallest thing we can ship to test it? For a marketplace, that's usually whether supply and demand will actually show up. For an internal tool, it's whether people will change how they work. The feature list follows from the answer.

In practice this means launching on one platform instead of three, taking one payment method, and running some admin processes by hand behind the scenes where users can't see them. None of that is visible to users, and all of it can be automated later once you know the product is right.

Where we don't cut: the one flow users will repeat every day. That's where the product gets judged, so that's where the design and engineering time goes.

Clients are sometimes uneasy about how small the first version is. A few months in, they're usually glad — half the backlog from that first scoping meeting never gets built, because users asked for different things entirely.