When to Say No to a Feature Request

A feature is not done when it ships. It is code to maintain, a path to test, a thing to explain in the docs, and a constraint on every change after it. That ongoing cost is invisible in the meeting where the feature is requested, which is why so much gets built that should not have been.

Make the real cost visible

When a request comes in, the useful contribution is an honest total cost: the build, yes, but also the testing, the documentation, the support load, and the drag it puts on future work. “Two days to build, then it touches the checkout flow forever” is a different proposition from “two days”. Whoever owns the roadmap can only decide well if they can see that.

Three questions

Does it serve the core job of the product, or is it a detour? Products that try to do everything do nothing memorably. How many users actually hit this, versus the one loud person asking? Ask for the number, not the anecdote. And what does it cost us later: does it add a special case to a central part of the system that every future change now has to respect?

The answers other than yes

“Not now” is a real answer. The request goes on the list, revisited when the picture is clearer, and often it turns out the need passed. “A smaller version” is often the right answer: the person wants a full workflow, but ninety percent of the value is in one screen of it. Build that, see if the rest is still wanted. “Not in the core product” fits the bespoke request from one customer: offer it as a paid customisation so the cost sits with the customer who wants it, not the whole codebase.

Say no to the shape, not the person

The request usually points at a genuine problem. Decline the specific solution while taking the problem seriously. “We are not going to add a second dashboard, but the thing you cannot find has to be easier to reach, let us fix that” keeps the trust and often lands somewhere better.

Write down what you declined and why

A short note on the requests you turned down saves relitigating them every quarter when someone new asks. It also lets you notice when the same request comes back a fifth time, which is a signal the answer should change.

The habit

A product stays good by what it leaves out as much as what it includes. Saying no is not obstruction. It is the part of the job that keeps the thing focused enough to be worth using.

Common questions

Is it the engineer’s job to say no to features?

It is the team’s job to surface the true cost so whoever owns the roadmap can decide with full information. Engineers own the cost estimate and the maintenance reality.

How do we say no without being obstructive?

Say no to the timing or the shape, not the person. “Not this quarter” or “here is a smaller version that covers the main case” keeps it a conversation.

What if the request comes from a big customer?

Weigh it, but be honest that a bespoke feature for one customer is a long-term cost the whole product carries. Sometimes the answer is a paid customisation, not a core feature.