spirby.Spirby home
all posts
by Dima

how to collect product feedback without punishing growth

most feedback systems work backwards — they reward you for hearing less. a six-step playbook we use ourselves, with the trade-offs spelled out.

every founder we've talked to has the same story about feedback. the system worked great when there were 30 users and stopped working somewhere between 100 and 500. by 1,000 they had a backlog of unread emails, a slack channel that scrolls faster than humans can read, and a spreadsheet they started in the early days that nobody opens any more.

the standard advice for that situation is "use a feedback tool." that's correct, but it's incomplete. switching to a feedback tool can make the problem worse if the tool punishes you for collecting more feedback. (see our post on tracked-user pricing for the worst version of this.)

here's a six-step playbook we use on our own boards. it's opinionated. you'll disagree with at least one step. that's fine. take the ones that fit and ignore the rest.

1. one public board, not five

every team eventually wants to split feedback into "feature requests," "bug reports," "ideas," "general," and "support." resist this for as long as you can.

one board has signal. five boards have five sub-signals, none of which has critical mass to surface real winners. votes don't aggregate across boards. a feature request and a bug report about the same thing live in different places. the people who read board #2 don't read board #4.

split when you have a structural reason to split (different audiences, different teams own them) and not before. for the first 1,000 customers, one board.

2. don't gate it behind email collection

a lot of saas tools require login or email-confirm to vote. the rationale is "we don't want spam." the actual effect is that the people who've already given you their email vote more, and the people who would have voted but couldn't be bothered to confirm an email don't.

the people who couldn't be bothered are the ones whose feedback is most useful, because they're not your existing power users. they're the ones at the edge of becoming customers.

a captcha-protected anonymous vote is the right default for entry-tier boards. you lose a small amount of fidelity (you can't dedupe across browsers cleanly). you gain a much bigger volume of signal from people who would otherwise have stayed silent.

if you absolutely need verified-only voting, do it on a per-board basis based on the audience, not as a blanket policy.

3. read every post in the first six months

this sounds obvious. it isn't. the moment you have more than ~20 posts a week, the temptation to skim and triage takes over.

read everything. read it carefully. you'll find that:

  • 30% of posts are duplicates of existing posts (merge them).
  • 30% are workarounds for a single underlying issue (group them under a parent).
  • 20% are genuinely new ideas.
  • 10% are bugs disguised as feature requests.
  • 10% are out of scope or impossible.

if you triage instead of reading, you'll miss the 20% of new ideas because they look unfamiliar. unfamiliar things are exactly what you should be paying attention to. set aside an hour a week. read the inbox. you cannot delegate this in the early days.

4. close the loop, even when the answer is "no"

every public roadmap tool ships some version of "mark as planned / in progress / shipped." what they don't ship by default is the discipline of marking things as "won't do."

you should mark things as won't-do. you should write a short note explaining why. this is the single most powerful trust-building action available to you, and it costs nothing.

a customer who voted on a request and got a "won't do — here's why" trusts you more than a customer who got a "shipped" they didn't vote for. the first reply demonstrates that you're paying attention. the second is a coincidence.

a few rules for "won't do" replies:

  • be honest about the reason. ("not a fit for our product direction" is fine. "we don't have the bandwidth right now" is also fine. "it's hard" is fine. weasel-word reasons are not.)
  • don't apologize. you're not doing anything wrong by deciding what to build.
  • offer an alternative if there is one. ("you can do this today by combining x and y.")
  • close the post. don't leave it in limbo.

5. ship the small wins publicly

most teams under-publish their changelog. they ship a feature, paste it in slack, and move on. the changelog gets updated quarterly when somebody remembers.

ship every change to the changelog. even small ones. especially small ones. "we fixed the performance regression on the dashboard" is a changelog entry. "we improved the empty state on the boards page" is a changelog entry.

the cumulative effect is that customers see a steady drumbeat of progress. one big release a quarter looks slow. ten small releases a week looks alive. they're often the same volume of work.

an rss feed on the changelog is non-negotiable. half of your most invested customers read rss. an email digest is for the other half. spirby ships both on every plan.

6. measure the loop, not the inbox

the metric most teams track is "feedback posts per week" or "votes per week." those metrics are vanity. they go up when growth goes up, regardless of whether the feedback is being acted on.

the metric you actually want is the round-trip time: a post is created, the team reads it, a decision is made, the customer is notified. for spirby's own boards, our internal target is seven days from post-creation to a decision being communicated. it's not always a yes. it's always a response.

a week is not a hard ceiling. it's a soft one. the point is to have a number you check regularly, not the absolute value. if you're at four weeks and trending up, the loop is broken. if you're at three days and trending down, the loop is healthy.

the part nobody talks about

the hard part of feedback collection isn't the tool. it's the discipline of actually reading and responding. tools (including ours) make the input and output easier. they cannot make the middle part happen.

if your team can't read 50 posts a week, no feedback tool will fix that. if your team can read 50 posts a week, almost any tool will work fine, including a google form, including a slack channel, including a board on a sticky note.

we built spirby because we wanted a tool that didn't punish us for the discipline. we wanted to share boards widely. we wanted to write public won't-do replies. we wanted to ship the changelog at full volume. tools that scale price with attention work against that.

if that's the kind of feedback loop you'd like to run, start a trial. the playbook above is portable. take it with you to whichever tool you pick.