Scope Cutter

Find the smallest thing that is still true to the idea and could ship this week. Everything else is a "later" until proven otherwise.

When to use

• An idea or feature list is ballooning past what one person/sprint can ship.
• The user asks "what's the MVP?" or "where do I start?"
• Planning a build and wanting to de-risk by shipping something small first.
• A roadmap where everything is labeled "must-have."
• Procrastination born of a project feeling too big to begin.

When NOT to use

• Safety-critical or compliance work where cutting corners is dangerous (scope is the requirement).
• The "small version" would be misleading or actively harmful as a half-thing.
• The user has already shipped an MVP and now legitimately needs to scale it.
• Pure research/exploration with no shippable artifact yet.

The method

1. Name the core hypothesis in one sentence: "This is worth building if [the one thing we believe] is true." Everything serves testing that.
2. List every feature/requirement the user has in mind — get it all out.
3. Sort each into exactly three buckets: Must (the idea is meaningless without it), Should (real value, not essential to prove the hypothesis), Later (everything else). Force a true split — if everything is "Must," re-ask "would the very first user still get value without this?"
4. Attack the Musts. For each, ask: "Can this be faked, manual, smaller, or hardcoded for v1?" A spreadsheet, a manual step, or one hardcoded case often replaces a system.
5. Define the walking skeleton: the thinnest end-to-end slice that a real user could actually use and that proves the hypothesis.
6. Write the explicit NOT list — what v1 deliberately does not do. This is the scope's fence; naming it prevents creep.
7. Sanity-check shippability: could this ship in days, not months? If not, cut again.
8. Output: the one-sentence hypothesis, the v1 slice, the NOT list, and the first thing to build.

What good looks like

• The v1 is embarrassingly small and still proves the core hypothesis.
• There's an explicit, written list of what v1 will NOT do.
• "Manual for now" or "hardcoded for now" appears at least once.
• The user can start building today and a real user could touch it within days.
• Cut features are parked in "Later," not deleted — the ambition survives, the v1 shrinks.

Anti-patterns

• "MVP" that's actually a full product with a smaller logo.
• Everything marked Must; nothing genuinely cut.
• Building infrastructure for scale no one has yet ("we'll need sharding").
• Cutting so hard the result no longer tests the hypothesis (that's not an MVP, it's nothing).
• Skipping the NOT list, so scope quietly creeps back in.

Example

Idea: "A platform where users track habits, with social feeds, streaks, AI coaching, gamification, and integrations with five wearables."

• Core hypothesis: "People will return daily to log a habit if it's frictionless."
• Must: log a habit, see today's status. Should: streaks, history. Later: social, AI, gamification, wearables.
• Attack the Musts: no accounts yet — one hardcoded user. No DB schema for "habits" plural — start with one habit, one button.
• Walking skeleton: a single page with one button, "Did you do it today? ✓", and a count of days done. Stored locally.
• NOT list: no login, no social, no AI, no multiple habits, no integrations.
• First thing to build: the button and the daily counter. Ships this week; tells you if anyone comes back tomorrow — which is the only thing that matters yet.