Feedback loops: hearing what users mean, not just what they say

The short version. Most products don't lack feedback; they lack a loop. Comments arrive, are nodded at, and evaporate. A working loop has five parts — collect, weigh, decide, change, and close the loop by telling people — and the last part, the one almost everyone skips, is where users turn into advocates.

1. Collect behaviour, not just opinion

What users say is one channel, and the least reliable one. Run at least three: what they say (support messages, reviews, the pilot's friction log — kept verbatim, because paraphrase launders the pain out); what they do (which features get used, where people drop out, what never gets touched — even simple counts will do); and what leavers say. The short conversation with someone who stopped using it is the single most nutritious feedback there is, and nobody enjoys asking for it. Ask anyway: "what did you switch back to?" is one question, and the answer is your real competitor.

2. Weigh feedback by evidence, not volume

Feedback arrives pre-distorted: the loudest voices are not the typical ones, the most recent comment feels the most important, and the person who emails daily is not your market. Correct for it deliberately. Does this request come from people who match your target user? Is it echoed in the behaviour data? Would acting on it serve the job the product is hired for, or just quiet one voice? Three vague mentions of the same friction outweigh one eloquent demand for a feature.

3. Interpret requests as symptoms

Users are excellent at spotting problems and mediocre at prescribing solutions — the request "add an export button" often means "I don't trust your product to keep my data" or "my boss needs a copy". Before building what was asked, ask what the person was trying to do when they asked. Fixing the underlying job usually costs less and satisfies more people than the literal request.

4. Decide on a cadence, in one place

Feedback handled reactively becomes whoever-shouted-last. Put everything in one list, and review it on a rhythm — weekly is plenty early on — deciding each time: what gets fixed now, what waits, what is explicitly declined. Declining is a decision, not a failure; a product that says yes to everything becomes a junk drawer with a login.

5. Close the loop out loud

When feedback changes something, tell the people who raised it — personally if there are few, in a visible "what changed" note as you grow. This is the highest-return, most-skipped step in the entire loop: people who see their feedback land become the users who recruit others, forgive rough edges, and keep telling you the truth. Feedback into silence, meanwhile, simply stops coming — and it stops quietly.

6. Know what feedback cannot decide

The loop refines a direction; it does not choose one. Users pull products toward their existing habits — real improvement often lives a step beyond what any single request describes, and a chorus asking for a faster version of the old way can drown the few showing you the new one. When feedback and vision disagree, that is not noise: it is the moment to re-run a proper test from the testing guide, with a pass mark, and let evidence arbitrate.

The whole thing, on one line

Collect what they do as well as what they say → interview the leavers → weigh by evidence, not volume → treat requests as symptoms → decide on a rhythm → and always, always tell people what their feedback changed.