MVP Scope Cutting

The goal of a first version is to learn or deliver the core value with the least build, not to ship a smaller version of the eventual product. Cutting scope well is choosing what not to build — and defending it.

Cut toward the riskiest assumption

1. Name the riskiest assumption: the belief that, if wrong, makes the whole thing pointless ("users will pay", "this is technically feasible", "people want this at all"). The MVP exists to test that, cheaply, first.
2. Identify the core value loop: the single end-to-end path that delivers the promised value once. Everything not on that path is a candidate for cutting.
3. Separate "must-have to deliver value" from "makes it nicer": most features are the latter wearing the former's clothes.

Cutting techniques that preserve value

• Vertical slice, not horizontal: build one complete feature end-to-end (thin but real) rather than every layer half-done. A working narrow path beats a broad path that doesn't connect.
• Manual before automated (concierge/Wizard-of-Oz): do the hard part by hand to validate demand before building the automation. Fake the engine, real the experience.
• Constrain the input space: support one file type, one platform, one use case first. Generality is the most expensive thing to build and the easiest to defer.
• Hardcode before configure: ship with sensible fixed defaults; add configurability only when a real user needs a different value.

Adversarial validation

• For each feature, ask: "if we ship without this, what specifically breaks?" If the answer is "it's less polished", it's a cut. If "no one can complete the core task", it stays.
• The cut that comes back: which cuts create rework or data migrations when you add them later? Cutting those is debt, not savings — distinguish reversible cuts from expensive-to-add-later ones (data model, auth, API shape).
• Validation honesty: does this MVP actually test the risky assumption, or did scope-cutting also cut the thing that makes the test meaningful?
• The hidden must-have: security, data integrity, and "don't lose the user's work" are not features to cut — cutting them produces a demo, not an MVP.

Non-obvious risks

• Cutting quality (it crashes, loses data) reads as "the product is bad", not "it's early" — never cut trust and correctness on the core path.
• An MVP that's too minimal tests nothing (users can't tell if they'd want the real thing); too maximal wastes the learning budget. Calibrate to the assumption, not to "small".
• Feature creep disguised as "it's just a small addition" — each addition delays the learning and dilutes the signal about the core value.

Output structure

Deliver: the riskiest assumption the MVP must test, the core value loop as a vertical slice, the explicit must-have vs defer list with "what breaks if cut" for each, the cuts flagged as expensive-to-reverse (so they're made consciously), and the non-negotiables (trust, data integrity) that stay regardless of deadline.