Customer feedback is usually scattered across interviews, support cases, sales calls, surveys, reviews, meetings, and community discussion. Summarizing it is easy; preserving the situation, source, tension, and limits behind each theme is the harder product work.

Strawberry can work across those real systems in the browser and approved apps, follow findings back to the underlying record, and keep customer language separate from team interpretation. Your companion can remember the source boundaries and coding the team accepts without treating old themes as permanent product truth.

Define the product question and sample

Clarify the product area, affected user or customer, period, source set, and decision the synthesis should inform. Decide whether the team is exploring a problem, checking a hypothesis, understanding a change, or reviewing a broader body of feedback.

State what the sample can represent. A few customer conversations can reveal important problems and language; they cannot establish prevalence across the user base.

Want to try it?

Ask your Strawberry companion: “Synthesize this customer feedback into source-linked themes, tensions, examples, evidence gaps, and confidence without jumping straight to roadmap priorities.”

Skill

Synthesize customer feedback

Synthesize approved feedback around a real product question while preserving sources, situations, tensions, gaps, and confidence.

Preserve the situation around the comment

Keep with important feedbackWhy it matters
Source, date, and record linkThe team can inspect the original evidence and its freshness.
User, account, or segment contextThe same words can mean something different for a new user, administrator, or mature customer.
Product flow, platform, and versionBehavior and expectations change across surfaces and releases.
Outcome and workaroundThe impact is often clearer in what the customer could not complete or had to do instead.

Normalize enough to compare evidence without stripping away the context that gives it meaning. Aggregate or redact personal and account data when individual identity is not needed in the broader artifact.

Calibrate before expanding

For a large source set, begin with a small, varied sample across source types, segments, severity, and viewpoints. Review the boundary and proposed coding before the companion expands.

Correct duplicate handling, theme boundaries, missing context, and over-represented sources early. Do not let one vivid anecdote become a repeated pattern merely because it is memorable.

Find themes and tensions

  • The job, goal, or situation the user was in.
  • The friction, workaround, failure, confusion, or unmet expectation.
  • The effect on 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.
  • Counterexamples, conflicting needs, and cases that do not fit the main pattern.

For every material theme, report the evidence base, representative examples, affected situations, tensions, confidence, and what evidence would raise or lower that confidence.

Deliver evidence, not a roadmap

Return the scope, sources, dates, limits, themes, tensions, examples, affected situations, open questions, and missing evidence. Frame product implications as hypotheses or decisions to consider. Stop before roadmap ranking, effort estimates, or automatic prioritization.

Skill

Write a product spec

Turn an accepted product problem into a clear definition, flows, requirements, edge cases, and acceptance criteria.

Skill

Define and review product metrics

Define or review the quantitative measures needed to understand the problem and later outcome.

Official Strawberry skill
Copy skill file Download skill file
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.