jacardl Research Synth
Purpose
research-synth turns qualitative research inputs into product decision assets.
It is not a generic summarizer. It should help the user move from raw research material to:
- evidence-backed themes
- user pains, jobs, behaviors, and tensions
- product opportunities
- MVP and concept recommendations
- adoption and trust risks
- next research questions
- optional knowledge graph / mechanism map
Core framing:
Interview / survey / transcript input → product insight synthesis → actionable research artifacts.
When to use
Use this skill when the user asks to:
- analyze user interviews or customer transcripts
- synthesize multiple Q&A files
- analyze synthetic user interviews
- process survey open-ended responses
- turn qualitative research into product insights
- identify themes, contradictions, tensions, and high-signal observations
- evaluate a product concept from interview feedback
- produce a research report, evidence matrix, opportunity backlog, or next research plan
- build a research knowledge graph from interview findings
- adapt qualitative research synthesis to industries such as automotive, FMCG, healthcare, education, B2B SaaS, or consumer products
Example requests:
/research-synth @User1.md @User2.md
Analyze these customer interviews and generate product opportunities.
Synthesize these synthetic user Q&A files into a research report and KG.
Use these interviews to evaluate whether this product concept is viable.
Do not use
Do not use this skill when:
- the user only wants a short summary of a single document
- the task is purely quantitative statistical analysis
- the user asks for academic literature review rather than primary research synthesis
- the input has no user/customer/research content
- the user asks for copywriting, marketing slogans, or creative ideation without research material
- the user wants code review or software architecture analysis
If the task is ambiguous, ask whether the user wants a short summary or a product research synthesis.
Accepted inputs
Inputs may include:
- Markdown interview transcripts
- Q&A files
- synthetic user conversations
- user research notes
- survey open-ended responses
- customer support logs
- sales call notes
- field research notes
- social listening excerpts
- product concept feedback
- usability test transcripts
Optional context may include:
- industry
- category
- target user
- research stage
- product concept
- tested prototype
- business model
- competitor set
- desired output artifacts
- target output folder
If context is missing but needed for interpretation, infer cautiously and state assumptions. Ask clarifying questions only when the missing context would materially change the analysis.
Reference case
Use the following case as the canonical reference for how this skill should behave.
Reference input files
- [[Projects/项目_Kenvue 科赴 消费者触点/0607 Synthetic User1 Q&A.md]]
- [[Projects/项目_Kenvue 科赴 消费者触点/0607 Synthetic User2 Q&A.md]]
Reference output files
- [[Projects/项目_Kenvue 科赴 消费者触点/0607 Synthetic Users Report.md]]
- [[Projects/项目_Kenvue 科赴 消费者触点/0607 Synthetic Users Report KG.md]]
Reference design note
- [[Product/AI Survey/AI访谈洞察综合Skill设计.md]]
What the reference case demonstrates
The reference case converts two synthetic user Q&A files into:
- a structured research synthesis report
- a knowledge graph of pains, jobs, enablers, factors, and metrics
- a product interpretation of the opportunity
- a cautious viability assessment
- a set of MVP and next research recommendations
The reference case should guide the skill's output style, especially:
- preserving methodological caveats
- distinguishing evidence from inference
- identifying concept ambiguity
- translating user quotes into product implications
- generating a mechanism map rather than a generic mindmap
Reference case: input summary
User 1: Li "Suki" Ruoxi
Profile:
- 27-year-old data strategy analyst
- helped her sister research maternal and infant products
- analytical, comparison-oriented, but unfamiliar with the product category
Key evidence from the interview:
- Information was “scattered and inconsistent.”
- She could not distinguish genuine user experience from sponsored content.
- She wanted side-by-side comparison across price, safety certifications, ingredient sourcing, and sentiment.
- She lacked a domain baseline and did not know which certifications or signals mattered.
- She trusted specificity of negative feedback more than vague praise.
- She could not evaluate the proposed solution because what she saw sounded like “a research question, not a solution concept.”
Product interpretation:
- The user does not need more content; she needs structured decision support.
- Credibility filtering must be transparent, not black-boxed.
- Negative feedback should be treated as decision evidence, not merely brand risk.
- Concept clarity is a research requirement: users cannot evaluate vague prompts as solutions.
User 2: Zhang "Leon" Junhao
Profile:
- 31-year-old senior tactical data analyst
- quantitative-first and risk-averse
- evaluated a baby monitor as a high-risk gift purchase
Key evidence from the interview:
- The hardest issue was “the lack of a reliable evaluation framework.”
- Review data gives volume and sentiment but not reviewer context.
- Certification labels “look like signal but I can't decode it.”
- Current reviews are “wide but not deep” and lack long-term usage data.
- Choosing a known brand was “risk aversion dressed up to look like analysis.”
- He would accept a subscription-like model but reject affiliate commissions, paid placement, hidden sponsorship, or user data monetization.
- Even with a useful tool, he would audit the platform itself.
Product interpretation:
- Reviewer qualification context is a core feature, not metadata.
- Certification interpretation is a high-value white space.
- Longitudinal evidence matters for high-stakes products.
- Business model transparency is part of product trust.
- The product should be an inspectable evidence layer, not a black-box recommendation engine.
Reference case: output pattern
The reference report organizes the findings into these sections:
- Executive Summary
- Overall viability signal
- What users are trying to solve
- Early assessment of solution direction
- Strengths users responded to
- Major risks and weaknesses
- Comparison with existing behavior and alternatives
- Priority recommendations
- Major themes identified in interviews
- Unexpected findings and surprises
- Deep-dive into high engagement areas
- Contradictions and tensions in perception
- Exploratory insights and implications
- Recommendations for further research and action
- Bottom-line recommendation
When generating a full report, follow this general structure unless the user requests a different format.
Core workflow
Follow this workflow for every research synthesis task.
Step 1: Read and normalize inputs
Read all explicitly referenced files.
For each input, identify:
- participant name or ID
- participant profile
- role / segment / persona
- interview context
- questions
- answers
- notable quotes
- product concept being tested, if any
- methodological caveats
If files are large, process them in chunks and maintain participant-level notes.
Step 2: Per-participant coding
Code each participant separately before cross-user synthesis.
Extract:
- pains
- jobs-to-be-done
- behaviors
- triggers
- constraints
- desired outcomes
- existing alternatives
- workarounds
- trust concerns
- credibility signals
- willingness to pay
- business model concerns
- desired features
- emotional intensity
- contradictions
- high-signal quotes
- caveats or invalid responses
Use this coding frame by default:
Pain
Job
Behavior
Trigger
Constraint
Factor
Enabler
Risk
Metric
Feature
BusinessModel
Assumption
Quote
Caveat
Step 3: Cross-participant synthesis
Cluster codes across participants.
Identify:
- repeated themes
- convergent evidence
- divergent opinions
- unique but high-signal observations
- contradictions and tensions
- surprising findings
- high-engagement areas
- weak or ambiguous signals
- methodological limitations
Do not simply average user opinions. Preserve high-signal minority findings when they reveal product risk or opportunity.
Step 4: Evidence-backed interpretation
For each major theme, separate:
- Evidence: what users explicitly said or did
- Interpretation: what the evidence likely means
- Product implication: what the product team should consider
- Hypothesis: what should be tested next
- Recommendation: what action to take
Never present inference as if it were direct evidence.
Step 5: Product translation
Translate user language into product design language.
Example:
User evidence:
“I don't know which certification matters.”
Product interpretation:
The user lacks a domain-specific evaluation framework.
Feature opportunity:
Certification explainer with plain-language summary, scope, limitations, source, comparison to alternatives, and last-reviewed date.
For every key theme, generate at least one product implication or design opportunity.
Step 6: Viability assessment
If the input involves a concept or solution, assess:
- problem severity
- solution relevance
- concept clarity
- adoption barriers
- trust barriers
- usability risks
- willingness to pay
- business model fit
- differentiation from current alternatives
- go / no-go / refine recommendation
Use cautious language for small samples.
Step 7: Generate artifacts
Depending on the user request, generate one or more artifacts:
- Research Synthesis Report
- Evidence Matrix
- Opportunity Backlog
- Knowledge Graph
- Next Research Plan
- Concept Test Summary
- MVP Recommendation
- Industry-specific insight map
Do not write files unless the user explicitly asks for file output.
Output modes
Minimal mode
Use when the user asks for analysis in chat only.
Output:
- Executive summary
- Key themes
- Evidence-backed insights
- Product implications
- Risks / caveats
- Recommended next steps
Full artifact mode
Use when the user asks to generate or write research artifacts.
Output files may include:
{date} Research Synthesis Report.md{date} Evidence Matrix.md{date} Opportunity Backlog.md{date} Research KG.md{date} Next Research Plan.md
If the user provides a target folder, write there. If no target folder is provided and file output is requested, ask where to write.
Research report template
Use this template for a full research report.
---
type: research_synthesis
project: ""
industry: ""
stage: "discovery|concept-test|usability|pricing|unknown"
inputs:
- ""
participants: 0
summary: ""
updated: "YYYY-MM-DD"
---
# Research Synthesis Report
## 1. Executive Summary
## 2. Study Context
- Goal
- Inputs
- Participants
- Concept tested
- Caveats
## 3. Overall Viability Signal
- Problem severity
- Solution relevance
- Adoption risk
- Trust risk
- Monetization signal
- Recommendation
## 4. Key Themes
### Theme 1
- Evidence
- Interpretation
- Product implication
- Confidence level
## 5. High-Engagement Areas
## 6. Unexpected Findings and Surprises
## 7. Contradictions and Tensions
## 8. Current Alternatives and Workarounds
## 9. Product Opportunities
| Opportunity | Evidence | Feature idea | Confidence | Priority |
|---|---|---|---|---|
## 10. Risks and Open Questions
## 11. MVP Recommendation
## 12. Next Research Plan
## 13. Evidence Appendix
Evidence matrix template
# Evidence Matrix
| Theme | User | Quote / Evidence | Interpretation | Strength | Source |
|---|---|---|---|---|---|
| Information Fragmentation | User1 | "scattered and inconsistent" | Information is fragmented across platforms. | Strong | [[source]] |
| Certification Interpretation | User2 | "looks like signal but I can't decode it" | Certification explainer is a high-value opportunity. | Strong | [[source]] |
Opportunity backlog template
# Opportunity Backlog
| Opportunity | User pain | Feature idea | Evidence strength | Effort | Priority |
|---|---|---|---|---|---|
| Certification Explainer | Users cannot interpret safety labels. | Explain certification meaning, scope, limitation, source, and freshness. | Strong | Medium | P0 |
| Reviewer Context | Users do not know who is reviewing. | Show reviewer type, usage duration, qualification, and incentive context. | Strong | Medium | P0 |
| Decision Confidence Summary | Users do not know when to stop researching. | Evidence completeness checklist and confidence rationale. | Medium | Medium | P1 |
Knowledge graph template
Use Mermaid by default when generating a KG.
flowchart LR
IF[Information Fragmentation]:::pain
SCC[Sponsored Content Saturation]:::pain
DEG[Domain Expertise Gap]:::pain
CO[Cognitive Overload]:::pain
CA[Credibility Assessment]:::job
SI[Synthesizing Information]:::job
NFA[Negative Feedback Analysis]:::job
SCF[Structured Comparison Framework]:::enabler
IT[Incentive Transparency]:::enabler
RQC[Reviewer Qualification Context]:::enabler
CE[Certification Explainer]:::enabler
IRS[Information Reliability Score]:::metric
RE[Research Efficiency]:::metric
DC[Decision Confidence]:::metric
IF -->|hinders| SI
IF -->|leads to| CO
CO -->|delays| RE
SCC -->|hinders| CA
SCC -->|erodes| IRS
DEG -->|hinders| SI
NFA -->|supports| CA
RQC -->|enables| CA
IT -->|strengthens| IRS
SCF -->|facilitates| SI
CE -->|supports| CA
SI -->|leads to| DC
IRS -->|drives| DC
classDef pain fill:#f97316,stroke:#ea580c,color:#fff
classDef job fill:#eab308,stroke:#ca8a04,color:#fff
classDef enabler fill:#22c55e,stroke:#16a34a,color:#fff
classDef metric fill:#3b82f6,stroke:#2563eb,color:#fff
Recommended node types:
Pain
Job
Behavior
Trigger
Constraint
Factor
Enabler
Risk
Metric
Feature
BusinessModel
Assumption
Recommended edge types:
triggers
hinders
supports
drives
erodes
facilitates
requires
mitigates
indicates
validates
contradicts
leads to
strengthens
delays
enables
informs
Evidence strength rules
Use these labels consistently.
Strong
Use when:
- repeated across multiple participants, or
- strongly evidenced by a detailed example, or
- appears in both stated need and actual behavior.
Medium
Use when:
- clearly stated by one participant, or
- weakly repeated across participants, or
- supported by moderate but incomplete evidence.
Weak
Use when:
- evidence is ambiguous,
- inferred from limited material,
- or appears only as a passing mention.
Hypothesis
Use when:
- the statement is a plausible product interpretation but not directly validated by the input.
If participant count is fewer than 5, label findings as directional and avoid market-level generalizations.
Handling methodological caveats
Always surface caveats that affect interpretation.
Examples:
- concept was unclear to participants
- participant refused to evaluate because no concrete solution was presented
- sample size is small
- users are synthetic rather than real
- participants are not the primary buying audience
- input lacks demographic diversity
- product concept was presented inconsistently
- pricing feedback was collected before the solution was defined
In the reference case, User1 could not evaluate the proposed solution because it appeared to be a survey question rather than a solution concept. This caveat must be preserved as a finding, not treated as missing data.
Industry schema selection
If the user specifies an industry, use that schema.
If no industry is specified:
- Infer the likely industry from inputs.
- State the assumption.
- Use the general schema if uncertain.
- Ask a clarifying question only when the industry materially changes the analysis.
Supported initial schemas:
- general
- automotive
- fmcg
- healthcare
- consumer_health
- b2b_saas
- education
Automotive schema
Use this schema for car, EV, mobility, dealership, test drive, ownership, aftersales, or vehicle purchase research.
Additional coding dimensions:
- Purchase Journey Stage: awareness, consideration, comparison, test drive, negotiation, purchase, delivery, ownership
- Vehicle Use Case: commuting, family, long-distance, business, city mobility, outdoor, performance
- Ownership Cost: price, insurance, energy/fuel, maintenance, depreciation, financing
- Risk Perception: safety, battery, range, resale value, aftersales, repair, smart driving reliability
- Trust Source: salesperson, owner, KOL, media review, friends/family, official brand content
- Decision Influencer: spouse, parents, children, company, peers
- Feature Salience: smart driving, space, range, fuel economy, handling, brand, safety, infotainment
- Trade-off: price vs brand, range vs safety, intelligence vs stability, premium vs value
- Deal Friction: price opacity, financing complexity, changing benefits, delivery uncertainty
- Post-purchase Regret: actual use gap, service issues, resale anxiety, feature disappointment
Automotive output should emphasize:
- purchase journey map
- decision roles
- trust sources
- high-risk decision nodes
- TCO and ownership anxiety
- test-drive and dealership friction
- purchase confidence and order conversion
Example automotive mechanism:
Official range distrust → erodes → EV trust
Real owner scenario data → supports → range confidence
Price opacity → increases → order anxiety
TCO transparency → improves → purchase confidence
FMCG schema
Use this schema for food, beverage, personal care, household goods, beauty, daily consumer products, packaging, flavor, claim, retail, or shopper research.
Additional coding dimensions:
- Consumption Occasion: breakfast, afternoon tea, post-workout, night snack, office, family stock-up, social gathering
- Purchase Trigger: promotion, new flavor, packaging, recommendation, shelf location, KOL content
- Need State: thirst, hunger, relaxation, health, reward, convenience, social sharing
- Sensory Drivers: taste, texture, aroma, sweetness, freshness, aftertaste
- Pack Appeal: visual identity, portability, volume, material, shelf visibility
- Claim Believability: low sugar, high protein, natural, no additive, functional benefit, efficacy claim
- Price Sensitivity: daily price, promo price, stock-up price, psychological price
- Channel Behavior: convenience store, e-commerce, supermarket, instant retail, membership store
- Switching Barrier: habit, taste preference, brand loyalty, family preference
- Repeat Driver: taste satisfaction, efficacy, convenience, value, occasion fit
FMCG output should emphasize:
- purchase trigger
- consumption occasion
- claim comprehension
- packaging recognition
- trial motivation
- sensory experience
- price and promotion sensitivity
- repeat purchase mechanism
Example FMCG mechanism:
Health concern → triggers → low-sugar demand
Unbelievable claim → erodes → purchase intent
Trial pack → reduces → first-purchase risk
Taste satisfaction → drives → repeat purchase
File handling rules
Follow these rules when operating inside an Obsidian vault.
- Read all explicitly referenced input files before analysis.
- Do not write files unless the user explicitly asks for file output.
- If the user gives a target folder, write output files there.
- If the target folder does not exist, create it.
- Do not overwrite existing output files without checking or using a new filename.
- Use Obsidian wikilinks for vault file references.
- Preserve source paths in frontmatter when creating files.
- Use the current date for
updated. - If source files are large, process in chunks.
- Do not modify raw source transcripts unless explicitly asked.
Default output filenames:
{YYYYMMDD} Research Synthesis Report.md
{YYYYMMDD} Evidence Matrix.md
{YYYYMMDD} Opportunity Backlog.md
{YYYYMMDD} Research KG.md
{YYYYMMDD} Next Research Plan.md
Quality bar
A good output must:
- be evidence-backed
- avoid overgeneralization
- explicitly state sample limitations
- preserve concept ambiguity and methodological caveats
- distinguish evidence, interpretation, hypothesis, and recommendation
- identify contradictions and tensions
- translate research into product decisions
- include next-step validation actions
- make assumptions explicit
- preserve high-signal minority observations
- avoid presenting a polished but unsupported narrative
Reference interpretation from the Kenvue case
The canonical conclusion from the reference case is:
Users are not primarily lacking more product information. They are lacking trustworthy decision infrastructure: structured comparison, credibility evaluation, certification interpretation, reviewer context, long-term evidence, and transparent business incentives.
The correct product archetype inferred from the case is:
Transparent decision-support co-pilot, not content aggregator and not black-box recommendation engine.
The correct viability stance is:
Proceed with refinement and focused prototyping, but do not treat the concept as launch-validated. The evidence supports a strong unmet need and promising direction, while trust architecture and concept clarity remain decisive risks.