Who Asked for This?

If your audit only asks whether a customer requested each feature, that ticket passes. It could still be worth building for other customers, or because the workaround leaves this one doing tedious manual work. You need a current view of the problem to tell.

If planning only revisits scope and estimates, it can preserve a commitment long after its reason changes. Each conversation settles another detail about how to build the feature while leaving the decision to build it untouched. You can finish exactly what the customer asked for after they’ve stopped needing it.

What the request leaves out

Customer evidence, strategic conviction, and technical investment can each justify work. They need different kinds of support.

A customer request gives you someone to talk to. You still need to understand what they can’t do now, how much that matters, and whether the requested feature would solve it.

A dashboard request might be about getting figures into a report prepared elsewhere. In that case, a better export could solve the problem without another screen to maintain. If the job requires colleagues to share an up-to-date view, an export could leave them passing stale files around. Ask to see the work the customer is trying to finish before choosing either solution.

A strategic bet makes a claim about a need you expect to emerge or a market you intend to enter. Requiring a customer quotation before permitting that work would restrict you to demand customers can already articulate. Make the belief explicit, along with what would make you reconsider it. Uncertainty is legitimate; calling a bet validated when it hasn’t been tested conceals the risk you’re taking.

Technical investment deserves an honest description too. If engineers have to disguise a brittle deployment system as a new feature to get it funded, the roadmap will hide the cost of keeping the product working. Name the failure risk or recurring difficulty, then compare the proposed change with a smaller repair as well as leaving it alone. Nobody needs to request a new deploy script for safer releases to be worth pursuing.

The customer’s name, the strategy label, and the technical explanation tell you where to start evaluating the work. You still have to decide whether it deserves capacity ahead of something else.

The competitive reflex

A competitor’s release gives a request a particularly persuasive origin. You can see the feature. You can demonstrate that your product lacks it. The missing piece is whether that difference matters to the customers you’re trying to serve.

Intercom’s Des Traynor makes this point in Product strategy means saying no: the competitor’s feature could be an experiment, a bad idea, or something they plan to kill. Its existence tells you what they shipped. The result remains unknown from the launch alone.

Copy it without checking the need, and you’re building around their hypothesis about their customers. You inherit the solution without the reasoning that might justify it. Even a successful feature for their product could be a distraction in yours.

Sometimes matching them is the right call. If buyers in a market you’ve deliberately chosen require single sign-on through their company’s existing login system, closing that gap may be a defensible investment. The reason comes from the buyers and your chosen market. The competitor helped you spot it.

Before treating the copy as committed work, ask which customer problem it addresses and what evidence you have that your customers face it.

Give old work a new decision

Basecamp describes a concrete way to prevent stored ideas from becoming automatic commitments. In Ryan Singer’s Shape Up, the candidates for a planning decision are recent proposals or older ones someone deliberately brings back. Support and programmers can keep their own lists of requests and bugs, but those lists don’t feed directly into scheduling. Someone has to advocate for the work again.

The implication is useful even if you keep a conventional backlog: remembering an idea needn’t commit you to building it. Requiring a current advocate makes the question about whether to fund the work today, rather than where it sits in an old queue.

Persistence alone doesn’t establish value. If access to the planning meeting determines which problems return, the process favors whoever can keep lobbying. Give known serious risks an owner and a place in planning even when no customer is asking about them.

A request also differs from a promise made in return. If the business has agreed to deliver the dashboard, its original commercial rationale can weaken while the obligation remains. Include the consequences of changing that agreement in the decision. The person who owns the commitment has to resolve it with the customer; closing the ticket doesn’t do that.

Singer’s account puts the scheduling decision with Basecamp’s CEO, CTO, a senior programmer, and a product strategist. The CEO has the final word on product in that arrangement. No second approval round follows, and scheduled work is protected from routine interruptions. These chapters describe an operating method; they don’t compare its results with those of a conventional backlog.

Your head of product can hold that line if leadership backs the decision. A CEO may own it in a smaller business. A CTO contributes the technical tradeoffs; the title alone doesn’t confer control over sales promises or executive requests. If those commitments can bypass the agreed priorities, a product manager can collect perfect justifications and still have no way to decline the work.

Make this check where a proposal becomes scheduled work. For the dashboard, compare what reporting work would remain under each option and what each would cost to build and maintain. Include the work you’d postpone to do it. If the choice depends on an unknown, a smaller investigation may deserve capacity before either build.

Once the work is committed, leave the team room to execute. Reopen the choice when new evidence materially changes the need, obligation, or cost, rather than asking them to win the same argument at every status update.

If neither the remaining reporting problem nor a delivery commitment justifies the dashboard, it can leave the plan. There’s still a customer to tell, even when there’s nothing left to build.