MVP scope: what to actually build before you build anything else

Every founder has felt the pull: one more feature, one more design pass, then people will finally get it. The most common reason startups die is not that the product was too small. It's that it was too big, too slow, too polished — and the team kept polishing the wrong thing while the real question went unanswered.

Name the riskiest assumption

The entire skill of scoping an MVP is picking the single thing that must be true for the business to work and that nobody has proved yet.

• A B2B tool for payroll teams: is the risk the feature list, or that payroll teams will switch from Excel? The answer is almost always the latter.
• A marketplace for freelancers: the risk isn't profiles, it's whether both sides show up in the same city at the same time.
• An AI note-taking app: the risk isn't the AI, it's whether the user forms a habit.

Write the assumption in one sentence — the same discipline as a one-sentence pitch. If you can't state the riskiest assumption simply, you're not ready to scope anything.

Scope to the feature that proves it

The MVP is the smallest product that produces evidence about that assumption. At minimum:

• The workflow, not the surface. Your users need to accomplish one job end-to-end. Every feature beyond that job is scope creep wearing a business card.
• Manual where it's cheap. If the assumption is demand, a human behind a website greeting customers is a feature that costs nothing.
• One channel, one segment. The MVP serves one clear type of user in one clear context. Success looks like fifty people in one niche getting value, not a thousand tourists getting confused.

What the founders you admire actually did

• The group-chat app started as a way for a founder to message a friend — one use case, one user pair.
• The batch-payment tool launched with a single workflow that saved hours per month for users, and charged for it on day one.
• The design-tool MVP had none of the features that later made it famous — it had the one workflow that made people feel something shift.

None of these validated the giant vision. They validated a narrow slice of it, deeply, with real people — and used that evidence to raise or re-scope.

The two week rule

If your MVP will take more than two weeks of focused work, the scope is wrong for what you're testing. Either the assumption is too big (split it), or the product is too big (cut it).

Public boards are a cheap way to pressure-test the scope against the crowd: post the one-sentence version, and the reactions tell you if the problem framing lands — before a single line of code. The fastest founders wire that feedback loop early and keep it running while they ship. Aim small, ship fast, and let the evidence — not the feature list — decide what's next.