How to say no to feature requests

"We've added it to the backlog" leaves an important question unanswered: should the customer expect this to happen? Give them the answer your team has actually agreed.

Most teams are not being evasive. They genuinely have not decided, so they send a sentence that commits to nothing and sounds like a commitment. Six months later the customer asks again, and now the conversation is about trust rather than about the feature.

Decide what you are saying no to

There are three ways to not build the thing that was asked for, and they are different promises.

• Adapt. You are addressing the problem another way. Say what you are doing, and say plainly what you are not doing.
• Defer. The need may be real and you are not committing. A defer needs a condition that would bring it back, otherwise it is a silent no.
• Decline. You are not going to do it. Give the reason and any alternative, including its limits.

Whatever you choose, only commit to what has actually been approved internally. A date is a separate decision from a direction, and an estimate is a separate decision again.

*The three cases below are invented, and so are the replies. They are drafts written as examples, not messages that were sent to a real customer, and nothing here suggests the customer stayed as a result.*

Adapt: a live dashboard for weekly reporting

Requested: a real-time dashboard of operational figures.

What the team found: the person doing the asking produces one finance report on Monday mornings. A scheduled export already exists in the example product, and its fields have not yet been checked against the figures they read out. Nothing in the conversation described a decision made during the day.

Decision: adapt. Point them at the scheduled export, and do not plan a dashboard.

Thanks for explaining how you use these numbers. For the Monday report, the scheduled export may already carry the figures you listed, and we can set it to arrive before you start once we have checked that. It won't give you intraday movement — it is yesterday's position, not a live view — and we are not planning a dashboard at the moment. Could we check the export's fields against your report together, so you can see whether anything is missing?

Defer: real-time sync when overnight may be enough

Requested: real-time synchronisation with the customer's other system.

What the team found: the current reconciliation runs overnight. Nobody has yet described a moment where waiting until the morning caused a problem, although two people said the delay "feels slow".

Decision: defer. Ask for the case that overnight cannot cover.

We understand you want the two systems to agree without waiting. Right now they reconcile overnight, and we have not committed to real-time sync — we do not want to imply it is scheduled. It would help us if you could show us one occasion where the overnight update arrived too late and what happened as a result. If there is a confirmed need to act on changes during the day, we will review the approach with our engineers. That review is not a promise to build it.

Decline: payroll inside an operations product

Requested: run payroll from the operations product, so approved hours are not entered twice.

Decision: decline, with the underlying problem acknowledged.

You're trying to avoid entering approved hours twice. We've reviewed the request, and we won't be adding payroll processing. Our team is focused on collecting and approving operational records; payroll calculations and submissions are outside the scope we intend to support. We can check whether the existing approved-hours export would reduce duplicate entry; it would not replace payroll software. If payroll inside this product is essential, we want you to have that clear answer before you make a decision.

That last sentence matters. A customer who needs something you will never build is better off knowing now, and telling them is not the same as losing them badly.

A skeleton you can fill in

We understand you need [outcome] because [situation]. We have decided to [adapt / defer / decline]. The reason is [plain explanation]. [Alternative and its limits, if available.] [Revisit condition, if deferred.] The next agreed step is [action and owner]. [No delivery date committed, if relevant.]

Before you send it, check two things: that the workaround you are offering actually exists and works the way you described, and that the person who owns the decision has agreed to the wording. A reply that offers an alternative nobody has tested does more damage than the original silence.

Where the reasoning lives

The reply is the last step. What makes it writable is having decided, in one place, what the problem is, what you know, what disagrees, and what you are prepared to commit — the [feature request decision template](/blog/feature-request-decision-template) is the version of that you can copy.

For a wider view of understanding the need behind a request, Canny's [guide to saying no to feature requests](https://canny.io/blog/say-no-feature-requests/) is worth reading. The examples above are our own.

If you want to work through one of your own requests, [send it to us](/contact) — or see [how BoB handles it](/product).