How to Decide What Not to Build

Most roadmaps are not really chosen. They accumulate. A request from a large customer, a competitor launch, something a senior leader saw and liked, an idea left over from the last strategy cycle. Each arrives with a reason to exist, and very few arrive with an honest account of what they will displace.

For a long time, capacity did some of the filtering for us. Building was expensive enough that many ideas never made it past the conversation. That filter is getting weaker. When a plausible prototype can appear quickly, the question is no longer simply whether something can be built. It is whether it deserves the attention, capacity and future obligation that come with making it real. That is a harder decision.

Start with what the idea would displace

Most prioritisation conversations begin with the idea itself. How valuable could it be? How many customers want it? How quickly could we deliver it? I think the more revealing question is often the one sitting just outside the frame: what will we not do if we do this?

Every meaningful yes creates a no somewhere else, even when the no is invisible. It may mean delaying work on a core customer problem, less time spent improving quality, another quarter in which a strategic weakness remains untouched, or simply one more thing added to a team that is already carrying too much. If the displaced work stays unnamed, the new idea gets judged against nothing, and almost any plausible idea looks good under those conditions.

Price the ownership, not just the build

Once something exists, it can create support work, documentation, security exposure, operational complexity, customer expectations, migration costs and another part of the product that future decisions have to work around. That does not mean small features are bad. It means delivery effort is only one part of the cost. There is more on that arithmetic in The Cost of Cheap Building.

I like to ask a longer-horizon question. If this still exists in three years, what will we be glad we own and what will we wish we had never inherited? The answer is often more useful than the sprint estimate.

A two-week feature is not a two-week commitment. It is the start of everything that feature will ask of you afterwards.

Look for evidence of the problem before enthusiasm for the solution

People can be genuinely excited about an idea and still not need it enough to change their behaviour. So before a roadmap commitment, look for evidence that the underlying problem is already costing someone something. Are customers creating workarounds, repeating the same support request, paying for another solution, delaying an important task, abandoning a workflow, or asking for help in ways that show the problem has consequence?

Stated interest matters. It can help you understand the problem and the language people use around it. It just should not carry more weight than it deserves. The stronger the commitment you are about to make, the more I would want to see evidence that the problem is real outside the meeting room.

Make “not now” a real decision

Some ideas are good ideas at the wrong moment. That distinction matters because organisations often make refusal unnecessarily dramatic. An idea is either approved or it disappears into a graveyard backlog nobody trusts.

A better “not now” has a reason and a trigger. Write down why you are not proceeding, record what would need to change for the decision to be reconsidered, and set a point to look again if the conditions are likely to move. That turns refusal from a judgement on the person who proposed the idea into a decision the organisation can revisit intelligently. It also stops the same idea returning every six months with its history mysteriously erased.

Revisit the things that already got a yes

The hardest work is not always deciding what enters the roadmap. It is deciding what is allowed to stay there. Once a project has a team, a sponsor and a date, momentum starts doing some of the decision-making for us, and continuation becomes the default.

So periodically ask of work already in flight: knowing what we know now, would we start this again? A confident yes is useful. A hesitant yes is useful too. I would not automatically treat hesitation as a stop signal, but I would treat it as information. What changed? Which part of the original case weakened? Are we continuing because the evidence improved, or because stopping would now feel awkward? That is a very different conversation from a status update.

Not building is part of building well

Choosing not to build something is not the opposite of ambition. It is how you create room for the things that matter more. As production gets easier, buildability becomes a less useful filter, and the quality of the portfolio increasingly depends on whether teams can make opportunity cost visible, price the full commitment and change their minds when reality changes.

The question is not simply “can we build it?” It is whether this deserves the time, talent, technology and attention it will continue to consume once it exists. The reasoning underneath this runs back to The Worth Building Philosophy.

For consequential decisions where the answer is not obvious, that is exactly the kind of choice Worth Building’s Pressure Test is designed to examine.