Most teams do not say no. They say "great idea, I have added it to the backlog", and then nothing happens, forever. The customer does not read that as a maybe. After the second time, they read it as a company that does not listen, and they are right.
A clear no costs you almost nothing. Here is the whole method in one line: name the problem you are not solving, state the decision, give one honest reason, and point at the nearest thing that exists today. Four sentences. In public, where the next twenty people who want the same thing can read it.
Silence does the damage, not the refusal
Think about what the person on the other end can observe. They wrote a request. Nothing visible happened. From where they sit, "we considered it seriously and decided against it" and "nobody ever opened it" look exactly the same.
So they stop writing. That is the real cost, and it is much worse than a disappointed customer: it is a customer who no longer tells you anything. The next time something is missing they will not post about it, they will renew somewhere else and you will find out from the invoice.
A no that is explained is a conversation. A no that is silent is a departure.
The four-part template
Copy this. It works in a support reply, and it works better as a public note on the request itself.
| Part | What it does |
|---|---|
| 1. The problem, in their words | Proves you read it, and separates the job from the feature they proposed. Most disagreements dissolve here. |
| 2. The decision, in plain language | "We are not going to build this." Not "not right now", unless you mean a specific later. |
| 3. One reason | One. A list of five reads as an excuse. Pick the true one, even when it is unflattering. |
| 4. The nearest thing that exists | A workaround, a different feature, an export, a competitor. Somebody still has a problem this morning. |
Three refusals you can adapt today
When you will never build it
You want to work from your phone on site, without carrying a laptop. We are not going to build a native mobile app. It would be a second product to maintain and we would rather put that time into the one you use every day. The web app works on a phone and installs to your home screen, and that is where our mobile effort goes.
Note what it does not say. It does not say "not on the roadmap right now", which invites the same request every quarter. It closes the question, and it does it by explaining the trade-off rather than hiding behind one.
When it is a real later
You need approvals before an invoice goes out. We are not building this before the audit log ships, because approvals without a record of who approved what is the version nobody can use. That work starts after the current release. This request stays open and you will get an email the day it ships.
"Later" is only credible with a condition attached. "After the audit log" is checkable. "Sometime in H2" is not, and the day H2 arrives you have taught your customers that your commitments do not mean much.
When it already exists
You want a weekly summary in your inbox instead of checking the dashboard. This exists, and it is off by default, which is our fault rather than yours. Settings, then Notifications, then Weekly digest. If it does not do what you need once it is on, reply here and we will reopen this.
Half the requests on a mature board are discovery problems wearing a feature costume. Answering them in public is the cheapest documentation you will ever write, because it is indexed under the words a confused customer actually used.
What never to say
- "Great idea!" when you are about to refuse. It reads as sarcasm in the second sentence.
- "We have added it to the backlog." Everyone knows what this means. It means no, without the respect of saying so.
- "Not enough people have asked for it." True and useless. It tells them to go and recruit votes, which is not the argument you want to be having.
- "That is not our vision." Vision is a word for internal meetings. Say the concrete thing the vision implies.
- Nothing at all. The default, and the only genuinely expensive option.
Say it once, in public
A refusal buried in a support thread helps one person. The same refusal written on the request itself answers everyone who arrives later, including the ones who never would have written in, and the ones evaluating you from a search result.
Three things make a public no work rather than sting:
- Keep the votes on the page. Deleting a refused request tells the people who voted that their time was wasted. Leaving the count visible says the decision had a price and you know what it was.
- Sign it and date it. A refusal from "the team" on no particular day feels like policy. From a person, on a date, it feels like a decision, which is what it is.
- Say what would change your mind. One clause is enough. "If this comes up alongside a compliance requirement, we will look again."
Give every no a page of its own
A public board where refusals are visible, dated, and still carry their votes.
When the reply comes back angry
It will, occasionally, and usually from someone who matters. Two rules.
Do not defend the decision twice. You gave one reason. Repeating it louder turns a decision into an argument. Instead, ask the question you should have asked first: what were you doing when you needed this? Nine times out of ten the answer reveals a different, smaller problem you can actually solve this week.
Never reverse a public no in private. If the escalation changes your mind, change it on the request, where the other voters can see it. A quiet exception for the loudest customer is how a roadmap stops meaning anything, and other customers always find out.
What changes after a quarter of this
The requests get better. People who have watched you refuse things clearly start writing the problem instead of the feature, because they have seen that the problem is what gets answered.
The board gets smaller and more useful, because refused items stop being reopened under new names. And the sentence you dreaded writing turns out to be the one customers quote back to you as the reason they trust the product.