closing the loop when the answer is "no" (Spirby blog)

every roadmap tool ships "planned," "in progress," and "shipped." those three are the easy statuses. they're good news. nobody loses sleep over telling a customer the thing they asked for is on the way.

the status that does the real work is the one most teams never use: "won't do." saying no, in public, with your name on it. it's the highest-trust action a public board gives you, and it's the one teams avoid hardest. this post is the long version of step four of the growth-tax playbook: how to actually say no without burning the relationship.

why "no" is the trust move

a customer who voted on a request and got back a clear "won't do — here's why" trusts you more than a customer who got a "shipped" they never voted for.

that sounds backwards. it isn't. the "shipped" they didn't ask for is a coincidence. you'd have built it anyway. the "no" is proof that a human read their specific post, weighed it, and made a call. you can't fake that, and customers know you can't fake it. a no is costly to send, which is exactly why it carries signal.

the alternative to a no isn't a yes. it's silence. and silence is what actually kills boards. a post sits open for fourteen months with no status, no comment, no decision. the customer who wrote it learns the board is a suggestion box wired to nothing. they stop voting. they stop posting. the board looks busy and means nothing.

the three flavors of no

"won't do" gets used for three different decisions, and collapsing them into one label is where a lot of the damage happens. name which one you're sending.

not now. the request is good, it's just not this quarter or this year. the honest version says so: "this is a real gap. it's not on the roadmap for 2026 because we're heads-down on the API. revisit in the new year." don't dress this up as a permanent no, and don't dress a permanent no up as this. customers can tell when "not now" is a polite forever.

not here. the request is legitimate but it's not your product's job. "this is a workflow-automation problem and we're a feedback tool. you can wire it up with a webhook (see the webhooks post), but we're not going to build it natively." this is the most respectful no there is, because it takes the request seriously enough to tell the customer where it actually belongs.

never. it conflicts with the product direction, the pricing model, or a line you've drawn on purpose. "we won't add per-seat pricing tiers. here's why." a clean never is fine. a clean never is better than a vague maybe that strings someone along for a year.

the failure mode is using one label and one tone for all three. a "not now" written like a "never" loses you a customer who'd have happily waited. a "never" written like a "not now" sets up a fight later when you finally admit you were never going to build it.

the anatomy of a good no

four rules, all of them learned the hard way.

be honest about the reason. "not a fit for our direction" is fine. "we don't have the bandwidth and won't for a while" is fine. "this would slow the product down for everyone else" is fine. weasel reasons are not. "great idea, we'll keep it in mind" is a weasel reason. it reads as a no to the customer and as a yes to nobody, and it costs you the credibility a real no would have bought.

don't apologize. you are not doing anything wrong by deciding what to build. "sorry, we can't do this right now" frames a normal product decision as a failure to deliver. it invites the customer to argue you out of it. "we've decided not to build this, here's the reasoning" closes the loop. say it like a decision, because it is one.

offer the alternative if there is one. half of all feature requests are a specific solution bolted onto a real underlying problem. you can decline the solution and still solve the problem. "we won't add a custom-fields builder, but you can tag posts and filter by tag, which covers the reporting case you described." now the no comes with a yes attached.

close the post. a no with the post left open in limbo is not a no. it's a maybe. set the status, write the comment, move on. the worst place a request can live is "we replied but never changed the status," because now the board says one thing and your words say another.

timing: fast no beats slow yes

the instinct is to sit on the hard ones. you don't want to disappoint anyone, so the no-pile grows while the yes-pile ships.

flip it. a no delivered in a week, while the customer still remembers writing the post, lands fine. the same no delivered in eight months reads as "we ignored you for eight months and now we're rejecting you." same decision, completely different relationship, and the only variable is how long you sat on it.

on spirby's own boards the target is the same seven-day round-trip we wrote about before: from a post being created to a decision being communicated. the decision is allowed to be no. it is not allowed to be silence for two quarters.

batch the sweep, don't template the empathy

if you've got a backlog of un-decided posts, don't try to clear it post-by-post in the cracks between other work. it never happens. block an hour, sort by oldest-with-no-status, and walk the list. a "won't-do sweep" once a month beats good intentions every day.

saved reply templates make the sweep survivable. spirby's templates take token substitution — {{post.author_name}}, {{post.title}}, {{board.name}} — so the boilerplate ("thanks for posting on {{board.name}}...") writes itself and you spend your attention on the part that matters: the actual reason.

one caveat, and it's the whole game. template the scaffolding, never the substance. a no that's visibly 100% canned is worse than no reply at all, because it tells the customer a robot closed their post. the token-filled greeting is fine. the sentence explaining why has to be written for that post, by a person. if you can't tell the reason apart from the template, you've templated the wrong layer.

the four ways teams botch it

these all look reasonable in the moment. they all cost trust.

the first is the silent demote. you marked something "planned," then reality changed and you can't ship it. so you quietly flip it back to open and hope nobody notices. they notice. the silent revert is the single fastest way to teach customers that your statuses are theatre. if you have to walk back a planned, say so out loud: "we said planned, we were wrong, here's what changed."

the second is ghosting the unpopular. you happily close the requests you were always going to decline, and leave the genuinely hard ones — the ones from good customers asking for reasonable things you can't do — sitting open forever. those are exactly the ones that need a real no. the easy nos don't build trust. the hard ones do.

the third is the fake-planned. marking something "planned" to make a vocal customer happy, with no intention of building it. this is a no wearing a yes's clothes, and it's worse than a clean no, because now you owe a ship you're never going to make. it converts into a much angrier conversation later.

the fourth is arguing. a customer pushes back on your no. you defend. it becomes a thread. don't. you already gave the reason. "i hear you, and we've made the call for now" is a complete sentence. the board is not a debate you need to win, and winning it publicly costs more than losing it quietly.

the part that doesn't show up in the tool

every feedback tool, ours included, gives you a status for the no (spirby calls it "declined") and a comment box. neither one makes you press the button. the discipline of saying no — clearly, quickly, with your reasoning attached — is yours, not the software's.

we built spirby so that saying no costs you as little friction as possible: statuses that notify the voters, templates that handle the boilerplate, a changelog that makes the yeses loud so the nos feel proportionate. the tool can lower the cost of the no. it can't decide to send it. that part's on you, and it's the part that makes a public roadmap worth running at all.

if you want a board that doesn't punish you for the discipline, start a trial. the playbook above is portable — take it to whatever tool you land on.

how to collect product feedback without punishing growth — the six-step playbook this post drills into.
the 50-vote rule: when to promote feedback to a roadmap — the inverse decision: when the answer is yes.