The not-doing list
A to-do list is intent; a not-doing list is the actual decision. The first asks you to give up nothing; the second asks you to give up something.
A to-do list is intent; a not-doing list is the actual decision. The first asks you to give up nothing; the second asks you to give up something. Scope rarely blows up because of one crazy decision. It is usually the accumulation of a dozen "might as well add it" moments. Each one looks reasonable in isolation, because nothing is pushing back. The not-doing list is the thing that pushes back.shapeup Writing it costs little time and pays off every entry by closing a debate before it starts.
What you'll run into:
- Scope keeps ballooning, and every feature looks reasonable the moment it's added
- The same question gets re-debated because last time no conclusion was recorded
- You ask the AI for one feature and it quietly adds all the related ones, so you spend the afternoon deleting
What to put on it
| Category | Why it deserves its own line |
|---|---|
| Things that seem natural | "We already track records, might as well add stats" — the most common source of bloat |
| Competitor features you don't have | Write down why you're not following. Otherwise every rival update reopens the debate |
| User requests you judged fake | Record the reasoning along with it. Next time someone asks, look it up |
| Technically tempting | "This is a good chance to try the new framework" — has nothing to do with user value |
| Someday, not now | Label it "not this version" to keep it separate from "never" |
Keep the last category apart from the first four. Mixed together, the whole list reads as temporary, and its binding power evaporates.
Writing the list is also a discovery process. Usually you realize while writing it that the real blockers aren't the big items but a pile of small decisions — where a button goes, what a field is called. Small decisions left unwritten cost ten minutes of every meeting; big ones left unwritten cost a weekend three months later.
Three rules for writing it
- Every entry needs a reason. Just writing "no mobile" means in three months nobody remembers why. Write "no mobile, because target users reconcile at their desks," and the entry stays useful.
- Distinguish "not this version" from "never." The first is a scheduling question, the second a positioning one. Mixing them implies everything is negotiable.
- Put it at the very front of the spec. At the end is the same as not writing it. Every time a new feature comes up, scan this list first.
| Not doing | Why | Type |
|---|---|---|
| Team collaboration and permissions | Target users are solo freelance designers | Never |
| In-app wireframing | They already have professional tools; we can't win that fight | Never |
| Mobile | Reconciliation happens at the desk | Not this version |
| Custom themes | Only one person asked, and it's a designer habit | Not this version |
The three-column format costs a few extra minutes to write, but it turns one-time judgments into conclusions you can cite over and over.
A note for AI
Put the not-doing list into CLAUDE.md, and the AI will remind you even when you have forgotten it yourself.
CLAUDE.md · scope constraints
## This project explicitly does not do
Never (this is positioning — do not try to convince me otherwise):
- [Thing not done] — because [reason]
- [Thing not done] — because [reason]
Not in this version (maybe later, but do not implement now):
- [Thing not done] — because [reason]
Execution requirements:
- If a request of mine falls under any line above, point it out and name
which line it matches, and wait for my confirmation before breaking the rule.
- When implementing a feature, do not "helpfully" add related capabilities
from this list, even if it looks like only a few lines of code.
- If you believe a constraint is no longer reasonable, you may raise it,
but give your reason — do not quietly route around it.
The second rule is the most practical. AI loves to "helpfully" fill in — ask it for a list and it will quietly add sorting, filtering, pagination, and export. Those few lines block most of that. Once the list is written, the real work is deciding, not typing: separate "maybe later" from "never" and label each one. If you can't tell the difference, dig for the reason — that process is product positioning practice.