Steve Jobs pinned Picasso's bull sketches to his wall. Not for inspiration. For permission to kill.
The sketches run from a full, heavy, detailed bull down to a few lines. Each step removes something, and each step gets closer to the animal. It reads like a lesson in editing.
Every product manager needs that permission now. Building has never been easier, which means adding has never been easier either. The skill I rate most now is knowing what not to build.
Why cutting is the job now
Jobs did the same at Apple. Around 350 products became four on a whiteboard, and that focus saved the company. His line on it: "Focus is saying no to a thousand things."
Anyone can add now. The job is knowing what to cut.
Most roadmaps are full because saying no is hard, not because the work matters. The nine moves below give you a reason, a question or a rule for each cut, so the no is easier to say and easier to defend. They fall into three groups: cutting what is already on the plan, stopping what is already running, and guarding the door so the roadmap stays short.
Cut what is already on the roadmap
Cut features that serve a stakeholder, not a user. Name the user problem each one solves. No answer, cut it. A feature that exists because someone senior asked for it is a promise to a person, not a solution to a problem.
Cut backlog items no one will recommit to. If nobody will fight for it this quarter, it isn't a priority. A backlog full of things nobody would argue for is a list of old intentions. Ask the team which items they would put their name to today, and let the rest go.
Drop metrics that never change a decision. For each metric, name the call it would change. None, remove it. A dashboard full of numbers that never move a decision is noise dressed up as rigour, and it eats attention that should go to the few numbers that matter.
Stop what is already running
Give every project a kill condition before it starts. Write the number and the date that would make you stop, on day one. It is far easier to agree a stopping rule before anyone is attached to the work than to argue for stopping once they are.
Kill the zombie no one stops because a senior owns it. Ask one question: "If this started today, would we fund it?" If the answer is no, end it. Zombie projects survive on ownership, not results, and every week they run is a week taken from something better.
Tie every shipped feature to one outcome. Give it one agreed window to move a number, then cut it or keep it. Shipped is not the same as finished. If a feature never had to earn its place, it will stay on the product long after anyone remembers why.
Guard the door so the roadmap stays short
Test the bet before you build the whole plan. Find the two-week version that proves it, and ship that first. A small test can kill a big plan cheaply, which is the best kind of cut there is.
Say no to the good idea that isn't THE idea. Cap the roadmap at three bets. A fourth means dropping one. Good ideas are the hardest to cut because they are good. A hard cap turns the argument from "is this worth doing?" into "is this worth more than what it replaces?"
Make every new feature pay for its place. Before you add, name what it replaces. Nothing to replace, don't add. This is the rule that keeps the other eight working. Without it, the roadmap fills back up as fast as you clear it.
The picture you are aiming for
Picasso's last bull is a handful of lines, and it is unmistakably a bull. That is the roadmap you want: fewer things, each one clearly there for a reason.
Cutting feels like losing work. It is the opposite. Every item you remove gives the remaining bets more time, more attention and a better chance of moving the number they were picked to move.
If the hard part is saying the no out loud to the person who asked, /vault/how-product-managers-say-no has phrases that keep the conversation open while you hold the line.
What would you clear off your roadmap first?