The Subtraction Playbook

Purpose

Most designer write-ups document what the team shipped. The harder, more senior move is to document what the team refused to ship — and to make the refusal legible enough that it survives the next planning cycle, the next reorg, and the next well-meaning stakeholder who’d really like that feature back, please.

This playbook is the structure for that write-up. It’s also a way of thinking about a product: every product has a shadow, the set of features it pointedly does not have. The shadow is where most of the leverage lives. Designers who can name and defend the shadow tend to be the ones who shape the product, not just decorate it.

When to use it

• A product team is debating whether to bring back a feature the previous version had
• A 2.0 or rewrite explicitly removed something — and the reason is sitting in someone’s head, not anywhere persistent
• You’re scoping a product down from a maximalist v1 to a focused v2 and need to defend the cuts
• You’re inheriting a product full of “why is this here” features and want to start naming what should not be
• A stakeholder is pushing for a feature and you have a strong design reason to say no, but it keeps coming back

Skip it when the removal is mechanical (deprecation of a dependency, fixing a bug). Subtraction here means design subtraction — refusing a capability the product could plausibly have.

Core framework

A Subtraction Playbook is built on five claims. Each claim is a paragraph in the write-up, in this order. Skip any one and the playbook collapses into a complaint.

1. The thing the previous version did

Name it neutrally. Not “the old version’s mistake” — that’s how you lose the people who built it. Describe the capability the previous version provided and the legitimate need it tried to serve. If the previous designers were senior people doing senior work, treat it that way. You’re not winning an argument; you’re documenting a redirection.

2. The thing the new version refuses to do

State the refusal as a flat sentence, not a hedge. “Groups do not have aggregate scores.” “There is no portfolio detail page.” “Bulk actions do not span workspaces.” Refusals work better as nouns than as principles. A noun is auditable; a principle is negotiable.

3. The “canaries” — what tells you the refusal is being violated

Three or four observable signals that the refusal is slipping. “If you find yourself adding a ‘view all’ route, the refusal is slipping.” “If a PRD has the word ‘rollup’ in it, the refusal is slipping.” “If you’re adding a checkbox toolbar above a group view, the refusal is slipping.” Canaries are the playbook’s enforcement mechanism — they let a reviewer six months from now spot the violation without rereading the whole document.

4. The trade-off you accepted

Every refusal costs something. The user who could do X in the old version can no longer do X. Name the cost. “Users who previously triaged at the group level now triage at the individual level — that’s more clicks for power users.” “Teams that depended on the rollup metric will need to recompose it from per-item data.” If you can’t name the trade-off, your refusal isn’t strong yet; you’ve just hidden a regression.

5. How you defend the refusal when asked

The script. Not a tone — actual sentences. “We removed group-level scores because they hid which member was the actual problem and slowed remediation. The metric isn’t gone; it’s at the individual level where the action is. Adding it back would re-introduce the hiding.” The script is how the playbook outlives you. The next designer can paste it into a meeting and not have to reconstruct the reasoning.

Reusable template

Drop this into a design doc, a PRD addendum, or a tools wiki. Each section is one paragraph; the whole thing should fit on one page.

# What this product refuses to do: <feature name>

## 1. What v<previous> did
<Neutral description of the old capability. Two to four sentences. State
the legitimate need it served. No editorializing.>

## 2. What v<current> refuses to do — flat statement
<One sentence. A noun, not a principle. Example: "There is no portfolio
detail page.">

## 3. Canaries — signs the refusal is slipping
- <Observable signal #1>
- <Observable signal #2>
- <Observable signal #3>

## 4. The trade-off we accepted
<Who loses what, plainly. Then what they get in return — usually
clarity, speed, or alignment with how users actually work.>

## 5. How to defend this in the room
> <Paste-ready paragraph the next designer can read out loud.>

---

Owner: <name>
Last reviewed: <date>
Status: <Active | Under review | Reversed (date)>

The status line matters. A reversed refusal is still useful documentation — it tells the next team this was tried, and what changed. A refusal with no last-reviewed date is a refusal nobody is willing to defend anymore.

AI-assisted workflow

AI is genuinely useful here in two narrow ways. Don’t ask it to make the decision; ask it to stress-test your draft.

Prompt: steelman the feature you removed

You are an experienced product manager reviewing a design decision. The
team removed the following feature from v2:

<paste the description from section 1>

Make the strongest possible case for putting the feature back. Argue
from real user behavior, business value, and competitive positioning.
Do not soften the argument. If the removal looks indefensible, say so.

Output: the three strongest reasons to reverse the decision, ranked.

If your defense script can’t withstand the AI’s strongest version of the counter-argument, the script isn’t ready. Either strengthen the defense or accept that you don’t yet have a strong enough reason for the cut.

Prompt: surface hidden re-introduction

Below is a PRD / design spec / Figma description. The product
explicitly refuses to do the following: <paste from section 2>.

Identify any element in the new spec that re-introduces the refused
capability, even partially. List each by name and quote the language
that re-introduces it. If none, say "no re-introduction detected."

This one catches the slow drift. The team keeps the rule for the first three quarters; by quarter four someone has added a “summary view” that’s the old hub with a new name. The prompt catches it during spec review, not during launch.

Collaboration considerations

• For PMs: subtraction playbooks live in the PRD or adjacent to it, not in a designer’s folder. They’re product decisions. If the playbook only exists in design tooling, it won’t be referenced when the next feature is being scoped.
• For engineers: a refusal that requires zero implementation is still a real piece of work — it’s the meetings and pushback you avoid. If your team is constantly answering “why don’t we just add a quick rollup,” you don’t have a tooling problem; you have a missing subtraction playbook.
• For research: test the defense script, not just the feature. Show power users your defense paragraph and ask if they buy it. If they don’t, you need a better script or a better refusal.
• For executives: these playbooks make scope conversations dramatically faster. A 30-minute “should we add X” debate compresses into “we have an active subtraction on this, here’s the canary that triggered the question, here’s the defense.”
• For your own career: a folder of subtraction playbooks is one of the best portfolios a staff or principal designer can show. It demonstrates judgment, not just craft.

Common failure patterns

1. Principle, not noun. “We value focus over breadth” is not a refusal. “There is no settings page” is. Principles collapse under pressure; nouns hold.
2. No trade-off named. A refusal that costs nothing is suspect. Either you’re hiding a regression or the feature was never worth having and the playbook is overkill.
3. Defense by tone. Refusing in italics or with exclamation points doesn’t help the next designer in the room. The defense has to be a paste-ready sentence.
4. Stale playbook. Six-month-old refusals with no last-reviewed date get treated as outdated even when they’re still right. Re-date them on each planning cycle.
5. Refusing in private. A subtraction playbook that lives in your head is not a playbook. It’s a grudge. Write it down.
6. No canaries. Without observable canaries, the refusal can be re-introduced under a new label without anyone noticing. The “summary view” / “rollup” / “overview tab” pattern is the most common re-entry vector.
7. Steelman skipped. If the case for the feature is so weak that you don’t bother writing it down, you’ll be unprepared when a senior person makes that case in a meeting. Always write the strongest version of the counter, in the playbook itself.
8. Treating reversals as failure. A refusal that gets reversed two years later because conditions changed is a working playbook, not a failed one. Mark it reversed, note what changed, keep the document.

Generalized example

A fictional customer-support inbox tool, version 2. Inherited from a maximalist v1 that included a “Team Inbox” view — a shared dashboard showing every open ticket across every agent, with aggregate response-time scores per team, and a “reassign all” bulk action.

1. What v1 did

The Team Inbox view aggregated every open ticket across the team into one dashboard. It exposed a team-level response-time score, a team-level resolution-rate score, and a “reassign all” bulk action that let a lead reassign a filtered subset of tickets to a different agent. The legitimate need: leads wanted a single place to see if their team was falling behind and a single mechanism to rebalance load.

2. What v2 refuses to do — flat statement

There is no Team Inbox. Tickets belong to individual agents. There is no team-level score and no cross-agent bulk reassignment.

3. Canaries

• A spec mentions “team dashboard,” “shared queue,” or “rollup.”
• The interface acquires a checkbox toolbar that operates above an agent grouping.
• A new metric is proposed at the team-or-higher level.
• A lead asks for “their” view of the team’s tickets — a sign the implicit hierarchy is sneaking back.

4. Trade-off

Leads who used to glance at the team dashboard once a morning now have to look at three to five individual-agent views to get the same picture, or wait for the weekly summary email. The team-level “reassign all” capability is gone; reassignment is per-ticket. In exchange: agents own their queues with no ambiguity about whose responsibility a ticket is, response-time data is no longer averaged to incoherence across very different ticket types, and the lead’s job shifts from queue management to coaching — which is what leads should have been doing the whole time.

5. Defense script

We removed the Team Inbox because it produced a number — the team response-time score — that hid which agent was actually behind and which kinds of tickets were piling up. Aggregating across agents and across ticket types averaged the signal away. We didn’t delete the data; we moved it to where the action is, on each agent’s own queue and each ticket’s own thread. Bulk reassignment was the most-requested feature of the old view, and it was also where the most damage happened — leads would rebalance based on the aggregate without understanding why one agent was slow, and the underlying problem would show up again the next week. Reassignment now happens per ticket, by the agent or the lead, with the context visible. If you find yourself wanting a Team Inbox, the right question is which specific agent is behind on which specific kind of ticket — and that question is already answered on each agent’s individual view.

Status line

Owner: Design (Maya R.) · Last reviewed: 2026-04-12 · Status: Active

That document, on one page, in the PRD folder, with the subject line “What our inbox refuses to do,” is the playbook.

---

Public-safe review (verified before publish)

• No employer or client product names, codenames, or org names
• No customer names, segment sizes, or identifiable details
• No internal metrics, thresholds, OKRs, or telemetry numbers
• No roadmap, ship dates, or future plans
• No architecture, service names, API shapes, or schema fields from real systems
• No screenshots showing real chrome, real data, or recognizable surfaces
• No internal-only workflows, tools, or terminology
• Every example is fictional or abstracted; numbers are illustrative
• A peer outside any employer could read this and learn nothing proprietary