What is a product feedback loop?

What are the four steps of a feedback loop?

A product feedback loop has four steps that repeat:

1. Collect. Customers send messages through a widget, a hosted page, an API or email. Each message arrives with enough context to act on.
2. Decide. Someone reads the message and chooses what happens: fix it, plan it, close it or ask a question.
3. Build. The team ships the change, or confirms that an idea has been recorded for later.
4. Tell. The customers who asked hear what happened. This is the step that closes the loop.

The loop is a cycle, not a line. Each release produces new messages, and each message restarts the collect step. The loop works when all four steps happen regularly, not when one of them happens once.

Where does the loop usually break?

Most loops break at one of two points. The first is between collect and decide. Messages arrive, nobody reads them, and the inbox grows until the team stops looking. The second is between build and tell. The change ships, the release notes go out and the people who asked for it never hear that their request was answered.

The third break is less visible. Teams decide without the context they need, so the build step starts from a guess. A bug decided from a message with no page URL can waste a week of reproduction work.

Customers notice all three. When nothing comes back, they stop writing, and the loop has nothing left to run on.

What does a healthy decide step look like?

A healthy decide step gives every new item a status and a reason. The reason can be short, but it should exist. It stops the same question being asked again next month and tells a new team member why an idea was closed.

Set a fixed time for the decision, such as a weekly batch, so items do not wait for a mood. Keep the list of statuses short. The full routine is in how to triage customer feedback, and the meaning of the step itself is in what feedback triage is.

Why does the tell step matter most?

The tell step is the one that turns customers into repeat senders. A customer who hears "this shipped, thanks for the idea" learns that their message had an effect. A customer who never hears back learns that feedback goes nowhere, and most of them will not try again.

Telling customers does not need a campaign. Find the people who asked, using the internal notes and the inbox search, and write a short personal reply. Escuta Produto does not send automatic emails to customers, so you reply from your own email account. Use the internal notes on each item to record who asked and whether they were told, so the step is not forgotten when the release gets busy.

How long should a loop take?

The loop should be as fast as your release rhythm allows, and no faster than your ability to decide well. There is no universal number of days, because a team that ships daily and a team that ships quarterly run different loops. A reasonable test is whether a customer who sends a message can hear back within the same cycle as the next release.

If the loop takes longer than your release cycle, most messages will wait a long time before any change. Shorten the decide step first, because that step is usually the one under the team's control.

How do you keep the loop running in Escuta Produto?

Escuta Produto covers the collect and decide steps in one place. Messages arrive in each product's inbox with the page URL, browser and any user details you pass in. Statuses run from new through planned, in progress and done to closed, so the decide and build steps have a shared record. Use the inbox filters and text search to find the people who asked for a change.

The tell step happens in your own email, because Escuta Produto does not send customer emails. Record the decision in the internal notes, then reply to the people who asked when the status moves to done. For the widget that starts the loop, see what a feedback widget is. For how replies should sound, read how to reply to customer feedback, and the notification documentation explains how Slack or Discord alerts feed the first step.