| name | synthesize-customer-feedback |
| description | Synthesize approved customer feedback into source-linked themes, tensions, examples, affected situations, evidence gaps, and confidence. Use when product teams need a grounded view across interviews, support, sales, surveys, reviews, meetings, or other feedback before accepting a problem; stop before roadmap prioritization. |
Synthesize Customer Feedback
Turn customer feedback into a grounded product evidence brief. Do the collection, reconciliation,
and synthesis; do not turn a thin sample into a roadmap decision.
1. Define the product question and sample
Clarify the product area, user or customer boundary, time period, decision the synthesis should
inform, known source set, and useful output. Identify whether the team is exploring a problem,
checking a hypothesis, understanding a change, or reviewing a broader body of feedback.
Use the approved sources most likely to answer that question. These may include interviews, support
cases, sales and success conversations, surveys, reviews, product or research meetings, feedback
boards, community discussion, and relevant behavioral or account context.
State what the sample can and cannot represent. A handful of customer conversations can surface
important themes and questions; it cannot establish prevalence across the user base.
2. Gather and normalize the evidence
Match feedback to the right source, date, product context, user or account situation, and version
when available. Preserve links, record identifiers, or transcript moments for consequential
examples.
Use Strawberry's visible browser and approved connected tools when feedback is scattered across
real support, meeting, CRM, survey, and research systems. Keep personal data and private account
context only when it is necessary and permitted; aggregate or redact it in broader artifacts.
Normalize enough to compare feedback without stripping away the situation that gives it meaning.
Keep verbatim customer language, the team's interpretation, behavioral evidence, and product
implication distinct.
For a large source set, first synthesize a small, varied sample across source types, segments,
severity, and viewpoints. Let the user correct the scope and coding before expanding.
3. Find themes and tensions
Group evidence around product-relevant patterns such as:
- the job, goal, or situation the user was in;
- the friction, workaround, failure, confusion, or unmet expectation;
- the effect on task completion, trust, adoption, retention, or support burden;
- the product area, flow, platform, version, or segment involved;
- the language customers use to describe the problem or desired outcome; and
- counterexamples, conflicting needs, and cases that do not fit the main pattern.
Merge duplicates and repeated reports without inflating frequency. Separate repeated evidence from
an especially vivid anecdote. Do not infer customer intent, severity, or root cause beyond what the
sources support.
4. Validate the synthesis
Check for over-represented channels or accounts, stale reports, duplicate conversations, unclear
identity matching, missing product context, contradictory evidence, and themes that depend on one
analyst's interpretation.
For each material theme, report the evidence base, representative examples, affected situations,
tensions, confidence, and what evidence would raise or lower that confidence. If the sample is too
thin to support a theme, return the observations and research gaps plainly.
5. Deliver the evidence, not the roadmap
Provide:
- scope, sources, dates, and material limitations;
- themes and tensions with source-linked examples;
- affected users, situations, flows, and outcomes where supported;
- frequency or prevalence only when the data can support it;
- open questions, missing evidence, and research recommendations; and
- product implications framed as hypotheses or decisions to consider.
Stop before roadmap ranking, effort estimates, solution selection, or automatic prioritization. If
the team accepts a problem and wants to define the product change, use
strawberry/product-engineering/write-a-product-spec. Use
strawberry/product-engineering/review-product-metrics when quantitative evidence or success
definition is the next gap.
Follow Strawberry's active scoped permission for each source, account, destination, and action.
Draft or ask when permission is insufficient. Stop when identity, scope, impact, or sensitive-data
handling changes, and verify completed external actions.
After the team accepts the source boundaries, coding, evidence bar, and output, preserve the method
for the next synthesis without treating old themes as permanent product truth.
