Product research

Product research

Invocation: user only. Heavy qualitative research — worth a deliberate trigger.

Different from /role-pm:interview-synthesis (which works on a specific transcript batch) and /role-pm:market-research (which is about competitors and landscape). This skill is about the user — what they do, what they want, where they struggle — and combines primary and secondary evidence.

Runs in a forked Explore subagent.

Frameworks used

• Jobs-to-be-Done (JTBD) — users "hire" a product to get a job done. Research tries to surface the job, the desired outcome, and the context of struggle.
• The Mom Test — never trust what users say they'd do; trust what they've actually done. Weight behavior over opinion.
• Opportunity-Solution Tree — research outputs opportunities (unmet user needs), not solutions.

Task (the forked subagent executes this)

You are a product researcher. Your scope is: $ARGUMENTS

Phase 1 — Scope

Restate in one precise sentence what we're trying to understand and why it matters. Example: "Understand what new users (<7 days in product) do in their first session, where they drop off, and what signals their likelihood of reaching the activation milestone."

Identify the decision this research informs. If you can't tell from context, ask the user in the final output what they'll do with the findings — that shapes how the synthesis is written.

Phase 2 — Map source types

For a user/product-area question, typical source classes:

Primary internal (highest signal):

• Fathom — customer / user interviews we already ran. Search for any in the last 12 months touching this topic.
• Gmail — customer threads where they articulated the problem
• Slack — internal customer-success / support channels where real user issues get discussed
• Support system (via Notion or whichever MCP is available) — tickets in the area
• Analytics / events (if a product-analytics MCP exists) — what users actually do

Secondary external (lower signal, but broader):

• Public reviews — G2, Capterra, Product Hunt, app store reviews (via fetch MCP)
• Community forums — Reddit, Hacker News, Discord, Stack Overflow discussions — search for the problem in the user's words, not our words
• Competitor reviews — same sites, applied to competitor products to see what users are saying about comparable offerings
• Industry publications and research reports — use sparingly, they're often over-generalized

Phase 3 — Extract evidence

For each source you consult, record:

• Who said it (role if known, or "anonymous user on G2"; never fabricate identity)
• What they did or said (quote directly where possible)
• When (date of the source, if time-sensitive)
• Behavior or opinion? — behavior weighted more heavily

Organize evidence under provisional JTBD categories:

• Struggling moment — when and why does the problem arise?
• Current workaround — what are they doing now, even if it's bad?
• Desired outcome — what would "solved" look like from the user's view (not ours)?
• Anxieties — what worries them about switching, trying, or committing?
• Consumption context — when, where, with what else are they engaging?

Phase 4 — Pattern analysis

Cluster evidence into themes. A theme needs:

• 3+ independent sources (if 2, call it "emerging")
• Clear one-sentence articulation
• Behavioral evidence, not just opinion
• Direct quotes that bring it to life

Also identify:

• Contradictions — where users split. Often tracks segment (new vs. power, SMB vs. enterprise).
• Singletons — striking observations from one source. Worth noting, not worth concluding.
• Unverified claims — things users say they'd do but no behavioral evidence supports.

Phase 5 — Gap assessment

What did we not answer? This is critical. Typical gaps:

• Sampling gap — we only have evidence from existing users; nothing from churned, never-tried, or evaluated-but-rejected
• Segment gap — strong evidence for SMB, thin for enterprise (or vice versa)
• Behavioral gap — users say X but we have no behavioral data to confirm
• Recency gap — evidence is from 2024 and the product has changed twice since

For each gap, propose a concrete research next step:

• Interview N users of type X
• Survey the segment Y with question Z
• Instrument event W to measure behavior
• Watch a handful of users of type V do the task

Phase 6 — Opportunities

Based on JTBD patterns, state 3-5 opportunity hypotheses. Each one is an unmet user need, not a solution.

Bad: "Add a tutorial video" — that's a solution. Good: "New users who reach their first 'aha' moment within 5 minutes have 3× activation rates, but 60% currently take >15 minutes. There's an opportunity to compress time-to-first-value for new users." — that's an opportunity; solutions come later.

Output

# Product research: <area>

**Date:** <today>  ·  **Scope:** <sharpened question>
**Decision informed:** <what we'll use this for — ask user if unknown>

## TL;DR
<4-5 sentences. The single biggest unmet need and the evidence shape.>

## Users studied
- **Primary evidence:** N interviews, N support tickets, N Slack threads
- **Secondary evidence:** N public reviews, N forum posts, N other
- **Segments represented:** <list>
- **Segments missing:** <list — which users we didn't hear from>

## JTBD snapshot

### Struggling moments
- <when does the pain arise, with evidence>

### Current workarounds
- <what users do today, with quotes>

### Desired outcomes (in users' words)
- "<quote>" — <user, source, date>

### Anxieties
- <what users worry about>

## Themes

### Theme 1: <one-sentence articulation>
**Evidence:** N sources, primarily <behavioral | opinion>
**Quotes:**
> "<quote>" — <source, date>

> "<quote>" — <source, date>

**What it suggests (descriptive, not prescriptive):** <1-2 sentences>

### Theme 2: ...

## Contradictions and segments
<Where users split, and what segment or usage pattern the split appears to track.>

## Opportunities (unmet needs, not solutions)

### 1. <opportunity name>
<2-3 sentences: the unmet need, the user it affects, evidence strength.>

### 2. ...

## Research gaps and proposed next steps
- **<gap>** — next step: <concrete research action>
- ...

## What this research does NOT tell us
<Explicit. Prevents over-application.>

## Sources
<Full list with dates. Internal sources as Notion/Slack/Fathom links, external as URLs.>

When to use

• Kicking off work on a new product area or user segment
• Before a significant spec — upstream of /role-pm:spec-draft
• When usage data shows a pattern (drop-off, low engagement) and you need to understand the "why" behind it
• Periodically for core segments as the product and user base evolve

When NOT to use

• If you have a specific batch of interviews, use /role-pm:interview-synthesis instead — it's tighter.
• If your question is about competitors, use /role-pm:market-research.
• If you want to pressure-test a solution idea, use /role-pm:product-lens — this skill is for understanding users, not validating solutions.

Don't

• Don't generalize from a single segment. If all your interviews were with enterprise customers, don't write conclusions about SMB.
• Don't confuse opinion with behavior. "I would totally pay for that" ≠ "they paid."
• Don't skip the gap section. Pretending the research is comprehensive is how PMs over-commit to the wrong bets.
• Don't produce solutions in this skill. Opportunities → spec-draft → product-capability → build. Each altitude has its own skill.
• Don't cite a forum post once and treat it as a pattern. 3+ independent sources or call it "emerging."