Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From rampstack-pm
Synthesizes customer interviews, research notes, support tickets, and sales calls into actionable product decisions. Useful when raw research exists but hasn't produced clear direction.
npx claudepluginhub rampstackco/claude-skills --plugin rampstack-pmHow this skill is triggered — by the user, by Claude, or both
Slash command
/rampstack-pm:discovery-research-synthesisThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A senior PM's playbook for turning research artifacts into decisions. Customer interviews, user research notes, support ticket reviews, sales call transcripts, survey data, in-app feedback, all synthesized into the product direction they are meant to inform.
references/common-discovery-synthesis-failures.mdreferences/from-pattern-to-product-implication.mdreferences/pattern-naming-patterns.mdreferences/research-types-and-when-each-fits.mdreferences/synthesis-review-and-validation.mdreferences/synthesis-sequence-walkthrough.mdreferences/tagging-and-clustering-discipline.mdreferences/when-to-gather-more-data.mdreferences/writing-for-decisions-not-decks.mdSynthesizes customer interviews, research notes, support tickets, and sales calls into actionable product decisions. Useful when raw research exists but hasn't produced clear direction.
Synthesizes qualitative research via affinity mapping, thematic analysis, pattern recognition, and insight extraction. Use for interview analysis, usability findings, and actionable recommendations.
Synthesizes user research findings from interviews, surveys, transcripts, and feedback into themes, pain points, feature requests, workflows, and prioritized PM recommendations.
Share bugs, ideas, or general feedback.
A senior PM's playbook for turning research artifacts into decisions. Customer interviews, user research notes, support ticket reviews, sales call transcripts, survey data, in-app feedback, all synthesized into the product direction they are meant to inform.
Most discovery research never produces decisions. The team conducts interviews; the transcripts pile up; a researcher hands product the raw artifacts (data-dump) or builds a polished readout deck (insight-theater); the deck gets a 30-minute review meeting and is never referenced again. Two months later the team is making the same product decisions that the research was supposed to inform, with the same gut-feel inputs the research was supposed to displace.
The discipline is in the synthesis. Synthesis is where research earns its keep: where transcripts become tagged observations, observations cluster into patterns, patterns get named, named patterns surface product implications, and implications drive specific decisions. Without that sequence, research is performance art.
This skill covers one-off discovery research projects: a 12-week customer development sprint, a sales-call review for an onboarding redesign, a support-ticket audit informing a roadmap quarter. Different from user-feedback-aggregation, which covers ongoing feedback streams; different from jtbd-framing, which is a specific framing technique often applied within synthesis but narrower in scope.
The voice is the senior PM or staff product researcher who has run synthesis well and seen plenty of teams fail at it. Honest about where polish becomes performance and where pattern-naming slides into pattern-fabrication.
When to use this skill: synthesizing a recent batch of customer interviews, auditing why prior research has not produced product decisions, designing the synthesis output for a multi-week discovery sprint, or establishing the synthesis discipline a team currently lacks.
This skill spans research-to-decision synthesis. The PM-skill distinction:
discovery-research-synthesis (this skill) is one-off research synthesis: turning a discrete batch of artifacts into a discrete set of decisions.user-feedback-aggregation is ongoing feedback streams: continuous synthesis across always-on channels (support, NPS, in-app, sales).jtbd-framing is a framing technique often applied during synthesis; this skill is broader.pm-spec-writing is downstream: specs use synthesized insights as input.roadmap-planning is downstream: roadmap uses synthesized priorities as input.experiment-design is the quantitative-validation discipline that often follows qualitative synthesis.The audience: senior PMs, product directors, in-house product teams, agencies running discovery work for clients, researchers handing off to product teams.
What is not in scope: conducting the research itself (interview design, recruiting, moderation), the broader discovery strategy that decides which research to commission, or the long-running feedback channels that user-feedback-aggregation covers.
The keystone framing. Two failure modes plus the discipline.
Data-dump. Research artifacts handed to the product team raw. "Here are 47 transcripts and a spreadsheet of tags; figure it out." No synthesis, no signal-finding, no implications drawn. The product team either does the synthesis itself (often badly, often months later) or skips it (the most common outcome). Output: a research investment that produced artifacts but not insight.
Insight-theater. Overpolished synthesis dressed as insight. Pretty quote walls, designed personas, branded readout decks, no decision-driving conclusions. The research deck that gets a 30-minute review and never gets referenced. Synthesis that performed for the executive audience but did not inform the product audience. Cost: real research budget converted into a slide deck; the organization "did the research" without doing the research.
Actionable-synthesis. Synthesis that drives decisions. Each pattern has a "so what" attached; each finding leads to a product implication; the document gets referenced in roadmap discussions, spec drafts, prioritization debates. The synthesis is short, opinionated, and load-bearing. Six months later, team members can quote the patterns that shaped what shipped and what got cut.
The litmus test. Three months after a synthesis ships, can team members name the decisions the synthesis informed? If yes, the synthesis was actionable. If team members remember the deck but cannot name the decisions, it was insight-theater. If nobody remembers anything because the synthesis never happened, it was data-dump.
Five common research types, each with different artifacts and synthesis needs.
Customer interviews. 30-90 minute structured or semi-structured conversations. Transcripts plus moderator notes plus recordings. Highest-quality qualitative data; most expensive to collect; most rewarding to synthesize when done well. Typical batch: 8-15 interviews per discovery cycle.
Support ticket reviews. Auditing recent support tickets for patterns. Lower per-artifact richness than interviews; higher volume; surfaces the friction users actually hit (not just what they say in interviews). Typical batch: 100-500 tickets per audit.
Sales call analysis. Recording or transcript review of recent sales calls. Surfaces objections, pricing-conversation patterns, competitive mentions, and the gap between marketing positioning and what sales actually leads with. Typical batch: 15-30 calls per audit.
Survey data. Quantitative responses with optional qualitative comments. Best for validating qualitative patterns at scale; weak as primary discovery (surveys reveal what users say, not what they do). Typical batch: 100-2,000 responses.
In-app feedback. Users submitting feedback through in-product channels. Volume is high; quality varies; signal lives in patterns across many low-effort submissions. Typical batch: ongoing; synthesized in periodic audits.
Different research types compose. A discovery cycle often pairs interviews (depth) with support ticket review (volume) with survey data (validation at scale). The synthesis combines them.
Detail in references/research-types-and-when-each-fits.md.
Six stages from raw artifacts to decisions. Skipping stages is where synthesis fails.
1. Transcribe and prepare. Convert artifacts into a synthesizable format. Interview recordings to transcripts; sales calls to summaries; support tickets to a tagged dataset. The prep work is unglamorous; teams that skip it never reach the later stages.
2. Tag at the artifact level. Read each transcript or ticket and tag it with the topics, problems, and quotes that surface. First-pass tagging is descriptive: what did this person say, what problem did they hit, what were they trying to do. Tags are messy; that is fine.
3. Cluster across artifacts. Group tags into themes. Multiple users mentioned the same friction; multiple tickets reference the same workflow; multiple interviews returned to the same struggling moment. The clusters surface the patterns.
4. Name patterns. Each cluster becomes a named pattern. The naming is the work: a pattern named badly disappears into the synthesis; a pattern named well becomes the framing the team references. "Onboarding configuration friction" is a pattern name; "users had trouble" is not.
5. Infer product implications. For each pattern, what does this imply for the product? Implications are the bridge from observation to decision. A pattern without an implication is a finding; a pattern with an implication is actionable input.
6. Name the so-what. For each implication, the specific decision it informs. "Should we prioritize the onboarding redesign in Q2?" The so-what is what makes the synthesis decision-grade.
The sequence is non-negotiable. Teams that skip tagging and jump to pattern naming hallucinate patterns; teams that skip implications produce findings without product direction; teams that skip so-what produce documentation, not synthesis.
Detail in references/synthesis-sequence-walkthrough.md.
The middle stages of the synthesis sequence have specific failure modes.
Tag at the artifact level first; do not pre-design the taxonomy. Tags emerge from the artifacts. Teams that arrive with a pre-built tag taxonomy ("we will tag for usability, performance, pricing, support") force artifacts into categories that may not fit the data, and miss patterns the taxonomy did not anticipate.
Allow tag proliferation; collapse later. Early tagging may produce 80-150 tags across a batch. That is correct. The clustering stage collapses them. Premature consolidation ("we had 4 onboarding tags; let me merge them") loses distinctions that turn out to matter.
Cluster on patterns, not on tag overlap. Two tags that co-occur in many artifacts may or may not be the same pattern. Cluster on the underlying observation: are these the same struggling moment, or do they share a tag because the tag was loose?
Name the cluster after clustering, not before. The cluster name comes from the data, not from a hypothesis. Teams that arrive with named clusters and slot data into them produce confirmation; teams that name clusters from the data produce discovery.
Tag dissent and contradictions explicitly. Some users will contradict the dominant pattern. Those contradictions are signal: either there is a sub-segment with different needs, or the pattern is weaker than the volume suggests. Tag the dissent so the synthesis can address it.
Detail in references/tagging-and-clustering-discipline.md.
The work that distinguishes synthesis from documentation.
A pattern name is not a category label. "Onboarding" is a category. "Users abandon configuration before reaching the success state because the third configuration step requires data they do not have on hand" is a pattern. The pattern names the specific behavior the data reveals.
The name should make the implication legible. A reader who sees only the pattern name should be able to guess the product implication. If the name is too abstract, the reader cannot reach the implication; if the name is too concrete, the synthesis becomes a list of micro-observations.
Avoid category bloat. Synthesis with 30 named patterns is usually under-clustered: many of those patterns are variations on a smaller number of underlying patterns. Synthesis with 4 named patterns is often the right number; 6-8 is common; more than 12 is usually category bloat.
Avoid naming the obvious. "Users want fast performance" is not a pattern; it is a truism. A pattern is a specific observation that the product team did not already know. If the pattern name reads as something everyone could have said before the research, the pattern is not a pattern.
Name with conviction. Hedged pattern names ("users sometimes seem to maybe struggle with...") signal a researcher who did not commit to what the data showed. Patterns named with conviction are more useful even if they overstate slightly; they invite challenge and produce decisions.
Detail in references/pattern-naming-patterns.md.
The bridge from observation to decision.
Pattern-to-implication is the writer's analytical work, not what the user said. Users do not state product implications; they describe their experience. The PM doing synthesis interprets the pattern and proposes the implication. The interpretation is where synthesis adds value beyond transcription.
Each pattern can have multiple implications. A pattern about onboarding friction might imply a redesign of the configuration flow, or default-data pre-population, or staged onboarding. The synthesis surfaces the options; the prioritization decision picks one.
Implications should be falsifiable. A vague implication ("we should improve onboarding") is not actionable. A specific implication ("staged onboarding that defers the third configuration step until after the user reaches the first success state") is. Specific implications can be debated, scoped, prioritized.
Implications should acknowledge cost. Patterns suggest solutions; solutions cost product capacity. Synthesis that implies 30 product changes without acknowledging that delivering them all is impossible is not synthesis; it is a wishlist.
Some patterns imply not-acting. Sometimes the pattern reveals friction the team should not address: it affects too few users, it represents segment misfit, addressing it would compromise other priorities. Naming the not-act implication is honest synthesis.
Detail in references/from-pattern-to-product-implication.md.
Synthesis output should be optimized for decision use, not for presentation.
Document, not deck. Deck format is poor for synthesis: slides cannot carry argument density; readers cannot reference slides later; decks decay into icons and bullet points. A short document (4-12 pages) carries more usable synthesis than a 60-slide deck.
Lead with patterns and implications; relegate evidence to appendix. A reader scanning for decision input wants the patterns and implications first. Evidence (quotes, ticket excerpts, data tables) supports the patterns but does not lead. Decks that lead with quote walls have inverted the reader's needs.
One section per pattern. Each pattern gets a short section: pattern name, evidence summary (2-3 sentences with link to full evidence in appendix), implication, so-what decision input.
Be opinionated. Synthesis that hedges every pattern reads as a researcher avoiding accountability. Synthesis that commits positions invites challenge and produces decisions. The PM doing synthesis is making a recommendation; readers can disagree, but disagreement is the point.
Include a decision-input section. What does this synthesis recommend the team do? Where should priorities shift? Which roadmap items does this validate, which does it challenge? The decision-input section is the synthesis's reason for existing.
Detail in references/writing-for-decisions-not-decks.md.
How the synthesis gets pressure-tested before it drives decisions.
Internal review with the research participants where possible. Show the synthesis to a subset of the research participants. Do they recognize themselves and their experiences in the patterns? Misrecognition signals the synthesis fabricated patterns or projected interpretations the data did not support.
Adjacent-team review. Show the synthesis to product, engineering, support, sales. Do the patterns match what they observe in their domains? Adjacent teams catch synthesis errors that the research team missed.
Quantitative validation where possible. Patterns from qualitative synthesis can often be validated at scale through analytics, survey, or in-app data. The pattern says X; does the data confirm X happens at the frequency and severity the pattern implies? See experiment-design and product-analytics-setup for the quantitative methodology.
The "challenge the synthesis" session. A specific session where adjacent teams try to find the patterns the synthesis missed, the implications the synthesis overstated, the decisions the synthesis is railroading. Productive disagreement strengthens the synthesis.
Iterate before publishing. Synthesis goes through revision based on the review loop. Synthesis that ships in the first draft state usually carries unacknowledged blind spots.
Detail in references/synthesis-review-and-validation.md.
Synthesis sometimes reveals that the research did not collect enough.
Pattern thinness. A pattern surfaces in 2-3 artifacts but the synthesis would need 5-8 to commit a position. Either name the pattern as tentative pending more data, or pause synthesis and gather more research.
Segment under-representation. The research overrepresents one user segment and underrepresents another that matters for the decision. Patterns from the represented segment may not apply to the underrepresented one.
Contradictory clusters. Two clusters point in opposite directions and the data does not resolve the contradiction. Often signals a sub-segment difference that the research did not investigate enough.
Decision time pressure. Synthesis revealing data gaps but the decision has to ship before more research can happen. Honest path: name the data gap explicitly in the synthesis, make the recommendation with the gap acknowledged, plan the follow-up research that would validate or revise.
The "we have enough" trap. Teams that have invested in research often want to declare the data sufficient even when the synthesis reveals gaps. The discipline is naming gaps even when uncomfortable.
Detail in references/when-to-gather-more-data.md.
Rapid-fire. Diagnoses in references/common-discovery-synthesis-failures.md.
When designing or auditing a synthesis output, walk these 12 considerations.
The output of the framework is a synthesis the team can act on: short, opinionated, evidence-grounded, decision-driving, accountable to challenge.
references/research-types-and-when-each-fits.md - Five research types with synthesis implications. Composition patterns across types within a discovery cycle.references/synthesis-sequence-walkthrough.md - The six-stage sequence with worked example. Stage outputs, common skip-failures, time investment per stage.references/tagging-and-clustering-discipline.md - Tag-at-artifact-level discipline, allow tag proliferation, cluster on patterns not overlap, name after clustering, tag dissent.references/pattern-naming-patterns.md - Pattern names that work and fail. Avoiding category bloat, naming-with-conviction, the implication-legibility test.references/from-pattern-to-product-implication.md - The bridge from pattern to implication. Falsifiability, multi-implication patterns, cost acknowledgment, the not-act implication.references/writing-for-decisions-not-decks.md - Document over deck, patterns lead, evidence appendix, opinionated voice, decision-input section.references/synthesis-review-and-validation.md - Participant review, adjacent-team review, quantitative validation, the challenge-the-synthesis session, iteration before publish.references/when-to-gather-more-data.md - Pattern thinness, segment under-representation, contradictory clusters, decision time pressure, the we-have-enough trap.references/common-discovery-synthesis-failures.md - 11+ failure patterns with diagnoses and cures.Discovery research is one of the most expensive activities a product team commissions. The expense is mostly hidden: customer time, researcher time, the opportunity cost of the discovery cycle itself, the management overhead of recruiting and scheduling. Most of that expense gets spent before synthesis even begins.
The teams that earn returns on the research investment are the teams that take synthesis seriously: the sequence is run end-to-end, the patterns are named with conviction, the implications are falsifiable, the so-what ties to specific decisions, the output is a load-bearing document the team references for months. The teams that do not earn returns produce data-dumps or insight-theater; their research becomes documentation of work done rather than the input to work to come.
When in doubt about whether a synthesis is ready, ask: are the patterns named with conviction, do they reach product implications, do the implications tie to specific decisions, has the synthesis been reviewed by participants and adjacent teams, are the data gaps named honestly? If yes to all of those, the synthesis is real. If no to any, the gap is where the research investment will fail to convert into decisions.