The short version
- Four loops, and the step nearly everyone skips is the last one.
- The last step is telling the person who asked. Without it there's no loop, just a queue.
- A column holding who asked, and the discipline to open it when something ships, is most of the work.
- An anonymous voter has no address, so one loop can't be closed at all.
A feedback loop is only a loop if it closes. Four examples below, written out step by step, and in three of the four the step that gets dropped is the same one, telling the person who asked that the thing happened.
What is a feedback loop?
A sequence that starts with somebody telling you something and ends with them finding out what you did about it.
The second half is the part that makes it a loop, not a funnel. Collecting feedback is a funnel. A loop requires the return trip, and the return trip is unglamorous, easy to postpone and the thing that decides whether anybody sends a second message.
There's a board where the return trip is built in if you want to see it, and the demo is open without an account.
Want the counting done for you? Twenty eight feedback tools, the price and the unit each one bills on, read on one day.
The four loops
| Loop | Where it usually breaks |
|---|---|
| The request loop | Nobody tells the requester it shipped |
| The bug loop | The reporter is never told it was fixed |
| The churn loop | The reason is recorded and never read again |
| The support loop | The recurring question is answered forty times and never fixed |
The request loop
- A customer asks for something.
- It's written down as a situation with a cost.
- Other people see it and agree with it, or don't.
- It's ordered against everything else.
- It's built, or it's declined with a reason.
- The people who asked are told which.
Step six is the one that gets dropped, and it's dropped for a mechanical reason, not a careless one. By the time the thing ships, the record of who asked is in an inbox, a support tool and somebody's notes, and reassembling that list costs more than writing the release note did.
The fix is structural. If the request carries the people who asked for it all the way through, step six is a consequence of step five, not a separate task.
The bug loop
- Somebody reports that something is broken.
- It's reproduced, or it's not.
- It's fixed, or it's accepted as known.
- The reporter is told.
Shorter than the request loop and broken just as often. The person who reported it's the single best tester you'll ever have for the fix, and they're almost never asked.
Here's the version of step four that costs nothing. When the fix ships, the release entry says what was broken and for how long. A reporter reading it recognises their own bug without being contacted individually.
The churn loop
- Somebody cancels.
- They're asked why, in one open question.
- The answer is recorded.
- The answers are read together, in a batch, by somebody who can act.
Step four is the drop, and the reason is that a cancellation reason arrives one at a time, months apart. Individually each one is anecdote. Read forty together, they're the clearest signal the product produces, and almost nobody reads them together.
This loop doesn't close back to the person, because they're gone. It closes to the product, and it's the only loop on this page where that's true.
The support loop
- The same question is asked for the third time.
- Somebody notices that it's the third time.
- The underlying thing is changed, usually a label, not a feature.
- The change is announced, so the people who asked stop having to ask.
Step two is the failure here, not step four. Support queues are organised by ticket, so the third instance of a question looks like a new conversation rather than a recurrence. Anything that lets you count tickets by subject turns the support queue into the cheapest research in the company.
The step most teams skip, and why
Telling the person who asked.
It's skipped for three reasons and none of them is laziness.
The record is scattered. Who asked is in four systems by the time the thing ships.
It feels like marketing. Telling somebody their request shipped reads like an announcement, and teams are shy about announcements.
It's nobody's job. The engineer shipped, the release note got written, and the return trip belongs to no role.
All three are fixed by the same thing, keeping the request, the people who asked and the release in one system, so that closing the loop is the same action as shipping.
How do you do this without a tool?
A column in your request document holding who asked, and the discipline to open it when something ships.
It works at small numbers. It stops working at the point where a request has eleven people on it and they arrived across five months.
How does this product do it?
A request carries the voters on it. When the item reaches the completed column it can be tied to a release, and the release note is generated from the items that shipped, each carrying its heading, its category and the number of people who voted for it.
What the product doesn't do is email everybody about everything. The digest has a floor. A board with too little activity sends nothing, because a notification about one small change trains people to ignore the next one. What gets sent, and when, is a deliberate set of rules, not a firehose.
The changelog page covers the announcement half, and feedback report examples covers reading the queue in a batch.
The public roadmap is the page the fifth step of each loop points at.
14 days, a card at signup, then $9 or $39 a month.
The loop ours cannot close
An anonymous voter has no address, so nothing reaches them when the thing they voted for ships. Anonymous voting buys volume and gives up the reply, and on our own board that trade is a switch, not a fix.