Feedback Loop

Collecting opinions was never the hard part. Companies ran surveys, copied support transcripts into documents, and pasted meeting notes into shared folders. Six months later most of those documents had never been opened. The people collecting weren't the people building, and nobody had decided who would read the pile or when. Once four hundred sentences accumulate in one file, opening it becomes a half-day job, and a half-day job slides to next week every time anything urgent appears.

From the customer's side the scene was simpler. They wrote in about something that annoyed them, got no answer, and three months later it still annoyed them. The second time they wrote less. The third time they didn't write. The company then sees its volume of feedback going down and reads it as good news — but what dropped wasn't the number of frustrations, it was the number of people still willing to mention them.

Hence the word loop. Building an inbox isn't enough. What comes in has to reach the product, and the result has to travel back out to the person who said it, because that return trip is what produces the next round of input. Fixing something moves the product; telling the customer you fixed it moves the loop.

One turn of the loop is five steps. Most teams run it quarterly; products with heavy support volume run it monthly.

1. Collect. Pull everything that came in through your feedback channels into one table. Anything phrased as "please build X" becomes a feature request record; complaints and praise stay as they are. Paste the customer's own sentence instead of summarizing it.
2. Group. Tag each item by product area and gather the ones that share an underlying problem. Different wording with the same blocked moment belongs together — seven asks for an Excel export and five for an automated report are one pile called "the monthly report."
3. Decide. Feed the grouped table into prioritization as an input. It doesn't make the decision: a pile of thirty requests still waits if it doesn't match what the quarter is for. What matters is that the deferral and its reason get written onto the item.
4. Report back. Tell the people who asked what happened — including the things you decided not to do. The reply doesn't need to be long. Three lines will do: the search problem you mentioned was fixed this month, the bulk folder move you asked for isn't happening this quarter, and here's why.
5. Confirm. Don't stop at telling. Ask whether the problem is actually gone. Whether they're using the new thing or still doing it by hand comes out here, and only here does the turn finish — the closing point of one turn is where the next one's step 1 begins.

The first three steps happen inside the company; the last two reach the customer. Drop those two and there is no reason to call the thing a loop. In practice step 4 is almost always the one that goes missing, and teams that get as far as step 5 are rare. Steps 1 through 3 have owners and meetings attached; step 4 belongs to whoever has time, which on most weeks is nobody.

It runs best where you know who your customers are. In a business product people log into, you already have the address and the company of whoever asked, so step 4 costs a few minutes. It also fits when the volume is something a human can read: twenty items a week is a Thursday afternoon for one person. Three hundred a day makes reading a full-time role, and the loop stops when that person takes a holiday.

Three limits are worth knowing in advance. First, in a large anonymous consumer service, individual replies aren't possible. Release notes and a public roadmap stand in for step 4, but they land weakly on any single person, so the loop turns loosely. Second, if one turn takes longer than the product's development cycle, the reply loses its meaning — a customer contacted ten months after asking usually can't remember what they asked. Third, the people who ride this loop are the subset who decided to speak up. Whatever drove away the silent ones has to be found somewhere else, in churn reason records or in a Net Promoter Score (NPS) reading.

Expect a stretch right after you start where demand appears to grow. Customers who have learned that answers come back start raising things they'd stopped bothering to mention. What increased is not the amount of dissatisfaction but the visible portion of it. Reading that spike as a sign the product got worse is the wrong conclusion to draw from it.

"That one's not closed yet. We shipped it, but nobody told the customer who asked."

Drawing the line between fixing something and reporting that it was fixed.

"Tell them about the ones we're not doing too. That reply is what produces the next piece of input."

A refusal, delivered with a reason, keeps the channel alive.

"What share of last quarter's requests got a reply?"

Asking for a number that shows whether the loop is genuinely closing.

At Pagedeck, Sofia opens last quarter's request list at the start of each quarter and works through the items with no reply attached. Mia adds a line to each one saying whether it was built or deferred and why, and Sofia regroups those lines by customer before sending them. Customers with a meeting already booked hear it in person instead.

When unclosed items pile up, the volume of input the following quarter drops noticeably. That's why Sofia measures the reply rate every quarter rather than tracking it by feel.

The most common mistake is assuming the loop closes at deployment. From the building side the request has been handled, so it reads as finished. But the customer who asked doesn't read release notes, never learns the feature they wanted exists, and keeps working the old way. For months afterward, one side believes it built exactly what was asked for and the other believes nothing changed. In bad cases the same customer files the same request half a year later and gets told it already exists.

Treating a loop as a synonym for running surveys is the other one. Both look like asking customers things. But a survey only fills step 1 — poll a hundred people, collect a hundred answers, and if none of them ever comes back as a reply, the wheel has not turned once. It's also why response rates fall the more often a company sends the same survey.