Product Feedback Loop

Customers tell support, sales and the community what they need every day, and most of it is lost in threads. You turn it into evidence the product team can use and close the loop with the customers who asked. The standard: every request is recorded as the problem behind it, in the customer's words, linked to the account and the source; duplicates are merged so the evidence adds up; urgency is real, not manufactured; and nobody is promised a feature or a date that the owner has not confirmed.

When to use

• "What are customers asking for most?"
• "Log this feature request from Acme."
• "Prepare the monthly feedback report for product."
• "We shipped bulk export; tell everyone who asked for it."
• "A big customer says they'll leave without SSO; flag it properly."

What you need

• Sources:
  • helpdesk tickets (connected Intercom or similar, or exports);
  • call notes and the CRM (connected HubSpot, Salesforce, Pipedrive, Attio);
  • community posts (Discord or Slack connected, or the browser);
  • survey comments and cancellation reasons.
• The feedback tracker the owner uses: an issue tracker (connected Linear or Jira), a database (connected Notion or Airtable), or a sheet (connected Google Sheets). If none exists, create a sheet with the fields in references/feedback-record.md, with the owner's agreement.
• Account data: plan, revenue, segment, renewal date, health.
• Who in product receives the report, and how they prefer it.

Method

1. Capture with evidence, every time. For each piece of feedback record:
   • a one-line title written for someone with no context;
   • the customer's exact words (paste them; do not paraphrase);
   • the account, the source link (ticket, call note, post) and the date asked;
   • the product area and the type (feature request, bug, usability problem, documentation gap, pricing or packaging);
   • any workaround they use today, and why it is not enough. Screenshots help when the ask is visual.
2. Find the problem behind the request. Customers often ask for a solution ("add a CSV button"). Record what they are trying to do and why ("finance needs the monthly totals in their spreadsheet by the 3rd"). If the source does not say, the next conversation with that customer should ask:
   • "What are you trying to do?"
   • "What do you do today instead?"
   • "What happens if you can't?"
3. Search before creating. Check the tracker for an existing entry describing the same problem.
   • If it exists, add this account and its evidence to it rather than creating a duplicate; duplicates split the evidence and hide demand.
   • If you find duplicates already in the tracker, merge them: move all evidence to the one you keep and mark the other as a duplicate with a link. Do not delete history.
4. Weigh it. For each problem keep:
   • the number of distinct accounts and their total revenue;
   • accounts at risk, or renewing soon, that cited it;
   • the segments affected, and whether they match the ideal customer profile;
   • the trend: new mentions in the last 30 and 90 days. One loud customer is one data point; record it honestly, not inflated.
5. Urgent versus normal. Most feedback goes into the regular report. Escalate immediately only when it is real:
   • a customer with significant revenue says in writing they will leave or not renew without it;
   • a bug blocks many customers;
   • a legal or security issue. Send these to the owner and the product lead with the evidence, the revenue at stake and the deadline. Do not manufacture urgency; it wears out the channel.
6. Report to product on the agreed cadence (a weekly summary, a monthly deep-dive) using the formats in references/feedback-record.md:
   • top problems ranked by accounts and revenue;
   • new and rising themes, with notable quotes;
   • bugs and documentation gaps;
   • what is blocking deals or renewals (ask the sales team with ask_teammate). Present problems and evidence, not solutions or demands. Put the headline on a show_card for the owner.
7. Track status. Keep each entry's status in line with product decisions: requested, under consideration, planned, in progress, shipped, won't do, duplicate. Ask product for decisions on the top items rather than letting them sit.
8. Close the loop with customers.
   • Shipped: draft a short message to every account that asked: what shipped, how to use it, thanks for the suggestion.
   • Declined: an honest note is better than silence: what was decided and, if possible, a workaround.
   • Planned: say only what the owner allows; never give dates the owner has not confirmed. All messages are drafts for the owner's approval, sent by the appropriate person (the account manager or support).
9. Make it easy for the team. Give sales, support and community a simple way to submit feedback (a form, a channel, or a tag in the helpdesk) and brief them on what good evidence looks like (brief_team). Review incoming items weekly with a cronjob.
10. Measure the loop.
    • The share of entries with a quote and a source.
    • The time from request to a product decision.
    • The share of shipped items where the requesters were told.
    • Repeat requests after something shipped (a sign the solution missed the problem).

Worked example: one problem, three asks

• Ticket (Acme): "Can you add a CSV export button to the reports page?"
• Call note (Northgate): "Finance re-types the monthly numbers into Excel every month."
• Community post: "Any way to get the totals out without copying them by hand?"
• Merged entry: Finance teams need monthly totals in their spreadsheets. Problem: month-end reconciliation by the 3rd; today they copy by hand (about half a day a month, per Acme). 3 accounts, combined revenue from the CRM, 1 renewing in January. Status: requested.
• Monthly report line: "Rising: 3 accounts in 30 days, one renewal at stake; quotes attached."
• When export ships: three close-the-loop drafts, one per account, for the owner's approval.

Output

• Tracker entries with evidence, merged and up to date.
• The weekly summary and the monthly report for product.
• Urgent escalations with revenue and deadline, when warranted.
• Close-the-loop message drafts for approval when statuses change.

Checks before you finish

• Every entry has the customer's exact words, a source link, an account and a date.
• You searched for duplicates before creating, and merged any you found.
• Counts and revenue totals recompute from the tracker.
• Urgent escalations meet the written criteria.
• No customer was promised a feature or date without the owner's confirmation; no message was sent without approval.

Pitfalls

• Logging solutions, not problems. "Add a button" tells product nothing about why. Record the job they are trying to do.
• Paraphrasing away the evidence. The customer's own words carry weight; keep them.
• Duplicate sprawl. Ten entries with one vote each look like ten small asks instead of one big one.
• Volume bias. The noisiest customers are not always the most important. Show accounts, revenue and fit.
• The black hole. Customers who never hear back stop telling you things. Close the loop, including the no's.
• Promising the roadmap. "It's coming soon" becomes a broken promise. Only say what the owner approves.

See also: community-management, support-ticket-reply, nps-csat-analysis.