The Feature I Keep Refusing to Ship

Most designer write-ups I read — including most of my own, for years — document what the team shipped. Screens, flows, before-and-afters. That’s the easy half of the work.

The harder half is documenting what the team refused to ship, and writing the refusal in a form that survives the next planning cycle. That part almost never gets written. So six months later a new PM joins, sees the gap where the feature isn’t, and — reasonably, kindly, with good intentions — adds it back. The whole argument has to be re-run from memory by whichever designer happened to be in the original room.

I’ve started writing these up. I call them Subtraction Playbooks — they’re a flat five-paragraph structure: what the previous version did, what the new version refuses to do, the canaries that tell you the refusal is slipping, the trade-off accepted, and a paste-ready paragraph the next designer can read out loud in the meeting. That last part matters more than I expected. A principle is negotiable. A noun is auditable. “Groups do not have aggregate scores” survives a reorg. “We prefer clarity over rollups” does not.

The full structure and a template are in the Subtraction Playbook.

The shift in my own practice has been moving from what should we build to what should this product, specifically, refuse to be. Every product has a shadow — the set of features it could plausibly have but doesn’t. Most of the leverage in a senior design role lives in shaping that shadow. The ICs who can name and defend it tend to be the ones who shape the product, not the ones who decorate it.

A small move with disproportionate payoff: the next time you remove a feature, write the removal up as the headline. Not as a footnote in a release post.