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
- Name the core hypothesis in one sentence: "This is worth building if [the one thing we believe] is true." Everything serves testing that.
- List every feature/requirement the user has in mind — get it all out.
- 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?"
- 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.
- Define the walking skeleton: the thinnest end-to-end slice that a real user could actually use and that proves the hypothesis.
- Write the explicit NOT list — what v1 deliberately does not do. This is the scope's fence; naming it prevents creep.
- Sanity-check shippability: could this ship in days, not months? If not, cut again.
- 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.
1---2name: scope-cutter3description: Takes an ambitious idea and aggressively cuts it down to the smallest version that is still valid, useful, and shippable — a true MVP — killing scope creep before it starts. Use this skill when the user has a big feature or project and says "this is getting big", "what's the MVP?", "help me scope this down", "where do I start", "this feels like too much", or is planning a build that's ballooning. Forces a ruthless distinction between what proves the core hypothesis now and what is genuinely "later".4---56# Scope Cutter78Find the smallest thing that is still true to the idea and could ship this week. Everything else is a "later" until proven otherwise.910## When to use11- An idea or feature list is ballooning past what one person/sprint can ship.12- The user asks "what's the MVP?" or "where do I start?"13- Planning a build and wanting to de-risk by shipping something small first.14- A roadmap where everything is labeled "must-have."15- Procrastination born of a project feeling too big to begin.1617## When NOT to use18- Safety-critical or compliance work where cutting corners is dangerous (scope is the requirement).19- The "small version" would be misleading or actively harmful as a half-thing.20- The user has already shipped an MVP and now legitimately needs to scale it.21- Pure research/exploration with no shippable artifact yet.2223## The method241. Name the core hypothesis in one sentence: "This is worth building if [the one thing we believe] is true." Everything serves testing that.252. List every feature/requirement the user has in mind — get it all out.263. 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?"274. 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.285. Define the walking skeleton: the thinnest end-to-end slice that a real user could actually use and that proves the hypothesis.296. Write the explicit NOT list — what v1 deliberately does not do. This is the scope's fence; naming it prevents creep.307. Sanity-check shippability: could this ship in days, not months? If not, cut again.318. Output: the one-sentence hypothesis, the v1 slice, the NOT list, and the first thing to build.3233## What good looks like34- The v1 is embarrassingly small and still proves the core hypothesis.35- There's an explicit, written list of what v1 will NOT do.36- "Manual for now" or "hardcoded for now" appears at least once.37- The user can start building today and a real user could touch it within days.38- Cut features are parked in "Later," not deleted — the ambition survives, the v1 shrinks.3940## Anti-patterns41- "MVP" that's actually a full product with a smaller logo.42- Everything marked Must; nothing genuinely cut.43- Building infrastructure for scale no one has yet ("we'll need sharding").44- Cutting so hard the result no longer tests the hypothesis (that's not an MVP, it's nothing).45- Skipping the NOT list, so scope quietly creeps back in.4647## Example48Idea: "A platform where users track habits, with social feeds, streaks, AI coaching, gamification, and integrations with five wearables."49- Core hypothesis: "People will return daily to log a habit if it's frictionless."50- Must: log a habit, see today's status. Should: streaks, history. Later: social, AI, gamification, wearables.51- Attack the Musts: no accounts yet — one hardcoded user. No DB schema for "habits" plural — start with one habit, one button.52- Walking skeleton: a single page with one button, "Did you do it today? ✓", and a count of days done. Stored locally.53- NOT list: no login, no social, no AI, no multiple habits, no integrations.54- 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.
opelpleple