← Index of work

Who is feedback for? An anatomy of the loop, drawn

July 2026

Every feedback system I've seen obsesses over intake. More channels, more forms, more listening. Intake matters — but it's the easy half. The question that decides whether the system is useful is on the exit side: who reads the mail?

When I was designing Cherry, my feedback-triage tool, I kept coming back to two questions. For every team that consumes customer signal: what is their goal? And: how should the same signal be presented to them? Once I drew the whole thing, most of the design decisions fell out of the picture on their own. Here's the drawing.

SIGNAL IN — every window has a tint FIELD & SALES CALLS why buyers hesitate SUPPORT TICKETS where it hurts today COMMUNITY & SOCIAL loud, self-selected EARLY-ACCESS COHORTS designed signal TELEMETRY what users do, not say THE TRIAGE CORE — one system of record SCREEN real people? representative? — bots, astroturf, venting bias CLASSIFY bug or tradeoff? one-off ticket or capability gap? use case? WEIGH severity · reach · recency · $ at stake — no mystery number PRODUCT goal: what to build next cut: ranked by user pain, by use case RESEARCH / MODEL goal: capability gaps cut: systemic, authentic patterns — not tickets GTM & SALES goal: renew & expand cut: breadth, recency, $ at stake — get ahead SUPPORT goal: respond now cut: sharpest current pain + reply drafts LEADERSHIP goal: strategy calls cut: deliberate trade- offs, cost of keeping permission gate — default-deny MODEL DEVELOPMENT capability signals → training priorities USERS the loop's fuel the silent no voice ≠ no problem "you said, we did" the product changes… …which generates new signal LOOP HEALTH — how you know it's alive: time-to-triage (median and p90) · correction rate falling · roadmap citations at decision time · repeat submitters A funnel moves signal one way and goes quiet. A loop returns something at every edge — closure to users, priorities to builders, new signal to the top. If any return arrow goes dark, the loop is dying and the metrics above will say so before people do.

The sources, and their tints

No source is neutral. Support tickets over-represent what's broken; nobody files a ticket about a feature they love. Community and social are the loudest room, and the loudest room is self-selected — a complaint that dominates one review site but appears nowhere else may be concentrated within a particular segment, however loud it sounds. Telemetry tells you what users do but never why. Early-access cohorts are the one source you get to design — you choose who's in the room and what you ask them, which makes them the closest thing to a controlled experiment the loop has.

The practical rule I landed on: never let one window decide what the weather is. Diversity of sources is the only real defense against mistaking a tint for the truth.

The middle is not a pass-through

A system that just forwards feedback is a mail sorter, and the pile stays a pile — it just arrives sorted. The middle box has three real jobs. Screen: is this from real people, and is it representative? Public reviews get gamed; bots write templated outrage; verified-purchase platforms are harder to fake than anonymous ones. Classify: is this a bug someone should fix, or a deliberate tradeoff the business chose and customers hate — those route to completely different owners. And is it a one-off ticket, or a pattern that says something about what the product is fundamentally not good at yet? Weigh: severity, reach, recency, and revenue at stake as separate, visible dials — never one mystery number, because the moment the score is opaque, nobody trusts the ranking and everyone rebuilds their own spreadsheet.

The exits — feedback is for five different jobs

This was the realization that reorganized the whole design: there is no such thing as presenting feedback to "the company." There are five different jobs, and the same issue looks different to each of them.

Product wants to know what to build next, so it needs issues ranked by user pain and grouped by use case. The research or model team is after something else entirely: systemic, authenticity-screened patterns, because its job is deciding what the product should get better at. Patches are someone else's aisle. GTM wants breadth, recency, and dollars at stake, because its job is walking into a renewal already knowing what the customer will bring up. Support wants the sharpest pain of this exact week, with a decent draft reply attached. And leadership needs a category the other four would misroute: the issues that are deliberate choices — pricing people hate, friction that's profitable — where the decision is strategic and "just fix it" is the wrong instruction.

Same signal. Five renderings. When I built this into Cherry, it became the persona views: one triage, re-weighted per audience, with the weights visible. "High-signal," it turns out, is a property of the reader.

The red arrow

For an AI product, one exit deserves its own color. Some feedback is bigger than a ticket: evidence that the model itself falls short on a whole use case. That kind of signal shouldn't stop at a backlog; it should inform what the model is trained to get better at. It's the highest-leverage arrow in the diagram, and it's also the one that needs a gate: customer data comes with contracts, and not all of it may cross into training. The gate is default-deny — if a record's permissions are unknown, it doesn't cross. The failure mode should always be "we were overly careful," never the other thing.

A funnel goes quiet; a loop comes back

The difference between a feedback funnel and a feedback loop is the return arrows. Users who hear "you said, we did" keep talking; users who feed a silent system stop. The model that improves changes the product, which changes what people say about it, which is new signal — the outer loop. And the dashed circle next to Users matters as much as the solid one: the segments with no voice in your evidence are simply unmeasured. Silence is a gap in coverage, not a verdict.

Drawing this took an afternoon. Building the v1 took longer — Cherry is my working version, with the screening, the classification, the per-team cuts, and the corrections feeding back in. But the diagram came first, and if you're building anything like this, I'd start where I did: at the exit side, with the two questions. What is each reader's goal? How should the same truth be shown to each of them? Everything else is plumbing.