A weekly feedback review template

The 30-minute agenda

Run the same agenda every week. A predictable structure keeps the meeting short, and it makes this week's numbers easy to compare with last week's.

Minutes	Step	Output
0 to 5	Look at the 30-day chart and the average rating	One sentence on the trend
5 to 15	Read new bugs and decide each status	Bugs marked planned, in progress or closed
15 to 22	Read new ideas and search for repeats	Canonical request list updated
22 to 26	Read praise and note what to protect	Praise saved for copy and regression checks
26 to 30	Assign replies and close what needs no action	A named owner for every reply

If you run short of time, protect the bug and reply steps. Those affect customers soonest, and ideas can wait a week.

Roles for a small team

You can run this alone. A team should split the roles:

• Reader: opens the inbox, reads each item and summarizes it.
• Decider: sets the status and says yes, no or later.
• Engineering contact: estimates effort for bugs and planned items.
• Replier: owns the replies and sends them from their own email.

A solo founder covers all four roles. Write each decision in the internal note while you read, so the next review starts from a clean record. For a larger team, rotate the reader role so everyone reads the inbox and hears what customers are saying.

Prepare before the meeting

Preparation takes about ten minutes and saves the meeting:

1. Open the inbox filtered to status new, or export the product's feedback as CSV.
2. Check the 30-day chart and the average rating for the week.
3. Note any release that shipped since the last review, because bugs often follow a release.
4. Bring last week's canonical request list, so duplicates are caught early.

Keep this preparation list in the same place each week, such as a pinned document or the first page of your sheet. A checklist that always sits in the same spot is far more likely to get done in a busy week.

What the meeting must produce

Every meeting ends with four outputs. If one is missing, the meeting did not finish:

• A status set on every item you read.
• A one-sentence trend note for the week.
• An owner and a date for each reply that matters.
• A short list of requests you decided against, each with a reason written down. The wording for saying no is in how to say no to a feature request.

Copyable checklist

Paste this into a document and tick the boxes during the meeting:

• Open the inbox filtered to status new
• Read every bug and set its severity and status
• Search the inbox for repeats of each new idea
• Update the canonical request list and the distinct customer counts
• Save praise you may use, after asking permission
• Close items that need no action, with an internal note
• Check the 30-day chart and the average rating
• Assign an owner and a date to every reply

Adjust the review for several products

Run one review per product, or one review that rotates through products. With several products, keep the agenda the same and rotate the order each week, so the product at the bottom of the list still gets attention. Keep the time box: two products in 30 minutes means about 15 minutes each, and bugs still come first in each block. Note how long each block really takes for two weeks. If bugs regularly run over, shorten the ideas block to one pass and move deeper discussion to a separate session.

If you run a larger portfolio, the routine is described in a feedback routine for running five products.

Run the review in Escuta Produto

1. Filter the product inbox to status new, and read the items in the list.
2. Use the type filter to separate bugs from ideas, and work the bugs first.
3. Set each item's status as you decide. The statuses are new, planned, in progress, done and closed.
4. Write the decision in the internal note, so the next review starts from it.
5. Keep Slack or Discord alerts on for awareness, using the notifications docs. The meeting is where decisions happen, not the alert.

When a planned item ships, the next step is to tell the people who asked. The steps are in how to tell customers their request shipped, and the status meanings are in how to design a feedback status workflow.