Build a shared view of product feedback
Combine support requests, discussions, and development tasks, group them by topic, and explain recurring problems.
How this works
Combine support requests, discussions, and development tasks, group them by topic, and explain recurring problems. Use this after feedback is already available across support, discussions and development records and the team needs an analytical view of recurring problems. The focus is interpretation and evidence, not simply collecting comments.
Extract distinct observations, group them by the customer problem they describe, and connect related themes to known product work. Count unique observations and accounts separately. AI proposes clusters; product reviewers verify membership and decide what deserves investigation.
Before you start
Feedback snapshot
Select sources, time window and permitted customer context.
Product taxonomy
Obtain current areas, journeys and known issue identifiers.
Counting rules
Agree duplicate, account and conversation definitions before reporting frequency.
Prepare the inputs
- feedback_records
- Required
ID, text, date, channel and account reference
Retain original text and source access restrictions.
- product_context
- Required
features, journeys and known issues
Distinguish current behavior from planned work.
- analysis_scope
- Required
period, audience and questions
Do not generalize beyond the collected sample.
- deduplication_rules
- Required
message, conversation and account rules
Preserve links between duplicates and their representative record.
Implementation, step by step
Prepare the analytical sample
- Normalize records and identify repeated messages or cross-posted incidents.
- Record source coverage and unavailable channels before counting themes.
Checkpoint: A deduplicated sample manifest exists.
Extract observations
- Separate one message into distinct problems, requests or positive observations.
- Keep the original wording and customer context attached to each observation.
Checkpoint: Atomic observations remain traceable.
Propose and review themes
- Group observations by underlying need rather than shared keywords alone.
- Inspect representative and borderline examples and split mixed clusters.
Checkpoint: Each theme has a coherent definition.
Analyze connections
- Compare themes across journeys, account segments and known development tasks.
- Compute counts deterministically and distinguish accounts, mentions and incidents.
Checkpoint: The summary explains prevalence within the sample.
Prepare product decisions
- Draft investigation questions, contradictory evidence and relevant issue links.
- Keep prioritization with the team and avoid claiming frequency proves value.
Checkpoint: A reviewable insights brief is ready.
Decisions along the way
One outage produces many comments
Count the incident separately from the number of affected accounts.
Theme mixes different needs
Split it and retain the parent relationship.
Rare problem has severe impact
Describe severity evidence separately from frequency.
What you will produce
feedback-themes.csv
CSVA reviewable analytical grouping.
Include: theme_id · definition · observation_ids · account_count · issue_links
product-insights.md
MarkdownA brief for investigation and prioritization.
Include: theme · evidence · counterexamples · questions · coverage
Check the result
- Sample cluster members and borderline records against the theme definition.
- Recompute counts from unique IDs.
- Verify source coverage and sample limits are stated.
- Check no generated theme is presented as an approved roadmap priority.
When something goes wrong
Customer IDs cannot be reconciled
Report mention counts and mark account counts unavailable.
Translation changes meaning
Retain original text and request bilingual review for the affected observation.
Existing issue link is uncertain
Mark it as a candidate connection rather than a confirmed duplicate.
A worked example
SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT
Request
Synthetic: analyze feedback for checkout.
Inputs
Five messages describe one outage from two accounts; three other accounts independently request saved payment methods.
Expected result
Synthetic result: report one outage incident affecting two known accounts and a separate saved-payment theme from three accounts. Do not rank the outage as five independent customer needs.
Run a small pilot
Start small
Analyze one month's feedback for a single product area.
Record the baseline
Record manual grouping time and reviewer corrections.
Agree success criteria
Agree theme coherence and counting accuracy before recurring reporting.
Stop or revise
Stop prevalence claims when duplicate or account identity handling is unreliable.
Keep the scope clear
- Feedback frequency does not determine business priority or represent all customers.
- Use customer context only within the permissions of the original records.
Check before using
Check group membership and source examples; mention frequency alone does not determine priority.
Business activities
- Resolve customer questions
- Plan products and business changes
FROM A RECIPE TO YOUR WORKFLOW
Bring the company context together.
This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.
For this recipe: Support requests · User conversations · Product tasks and changes
Start with one recurring task, agree which sources to use, and review the first result with your team.
Discuss this workflow