v1.0
This commit is contained in:
@@ -0,0 +1,19 @@
|
||||
{
|
||||
"name": "pm-product-discovery",
|
||||
"version": "1.0.0",
|
||||
"description": "Product discovery skills for PMs: ideation, experiments, assumption testing, feature prioritization, and customer interview synthesis.",
|
||||
"author": {
|
||||
"name": "Paweł Huryn",
|
||||
"email": "pawel@productcompass.pm",
|
||||
"url": "https://www.productcompass.pm"
|
||||
},
|
||||
"keywords": [
|
||||
"product-management",
|
||||
"discovery",
|
||||
"ideation",
|
||||
"experiments",
|
||||
"assumptions"
|
||||
],
|
||||
"homepage": "https://www.productcompass.pm",
|
||||
"license": "MIT"
|
||||
}
|
||||
@@ -0,0 +1,50 @@
|
||||
# pm-product-discovery
|
||||
|
||||
Product discovery skills for PMs: ideation, experiments, assumption testing, feature prioritization, and customer interview synthesis.
|
||||
|
||||
## Overview
|
||||
|
||||
This plugin provides 12 skills and 5 commands for product managers.
|
||||
|
||||
## Skills
|
||||
|
||||
- **analyze-feature-requests** — Analyze and prioritize a list of feature requests by theme, strategic alignment, impact, effort, and risk.
|
||||
- **brainstorm-experiments-existing** — Design experiments to test assumptions for an existing product.
|
||||
- **brainstorm-experiments-new** — Design lean startup experiments (pretotypes) for a new product.
|
||||
- **brainstorm-ideas-existing** — Brainstorm product ideas for an existing product using multi-perspective ideation (PM, Designer, Engineer).
|
||||
- **brainstorm-ideas-new** — Brainstorm feature ideas for a new product in initial discovery.
|
||||
- **identify-assumptions-existing** — Identify risky assumptions for a feature idea in an existing product across Value, Usability, Viability, and Feasibil...
|
||||
- **identify-assumptions-new** — Identify risky assumptions for a new product idea across Value, Usability, Viability, Feasibility, and Go-to-Market.
|
||||
- **interview-script** — Create a structured customer interview script with JTBD probing questions, warm-up, core exploration, and wrap-up sec...
|
||||
- **metrics-dashboard** — Define and design a product metrics dashboard with key metrics, data sources, visualization types, and alert thresholds.
|
||||
- **prioritize-assumptions** — Prioritize assumptions using an Impact × Risk matrix and suggest experiments for each.
|
||||
- **prioritize-features** — Prioritize a backlog of feature ideas based on impact, effort, risk, and strategic alignment.
|
||||
- **summarize-interview** — Summarize a customer interview transcript into a structured template with JTBD, satisfaction signals, and action items.
|
||||
|
||||
## Commands
|
||||
|
||||
- `/pm-product-discovery:brainstorm` — Brainstorm product ideas or experiments from PM, Designer, and Engineer perspectives — for existing or new products
|
||||
- `/pm-product-discovery:discover` — Run a full product discovery cycle — from ideation through assumption mapping to experiment design
|
||||
- `/pm-product-discovery:interview` — Prepare a customer interview script or summarize an interview transcript into structured insights
|
||||
- `/pm-product-discovery:setup-metrics` — Design a product metrics dashboard with North Star metric, input metrics, health metrics, and alert thresholds
|
||||
- `/pm-product-discovery:triage-requests` — Analyze, categorize, and prioritize a batch of feature requests from customers or stakeholders
|
||||
|
||||
## Installation
|
||||
|
||||
```bash
|
||||
/install pm-product-discovery
|
||||
```
|
||||
|
||||
Or use directly:
|
||||
|
||||
```bash
|
||||
cc --plugin-dir /path/to/pm-product-discovery
|
||||
```
|
||||
|
||||
## Author
|
||||
|
||||
Paweł Huryn — [The Product Compass Newsletter](https://www.productcompass.pm)
|
||||
|
||||
## License
|
||||
|
||||
MIT
|
||||
@@ -0,0 +1,122 @@
|
||||
---
|
||||
description: Brainstorm product ideas or experiments from PM, Designer, and Engineer perspectives — for existing or new products
|
||||
argument-hint: "[ideas|experiments] [existing|new] <product or feature description>"
|
||||
---
|
||||
|
||||
# /brainstorm -- Multi-Perspective Ideation
|
||||
|
||||
Generate creative product ideas or experiment designs from three perspectives (PM, Designer, Engineer), tailored to whether you're working on an existing product or building something new.
|
||||
|
||||
## Invocation
|
||||
|
||||
```
|
||||
/brainstorm ideas existing Mobile banking app engagement
|
||||
/brainstorm ideas new AI-powered meal planning for busy parents
|
||||
/brainstorm experiments existing Onboarding flow redesign
|
||||
/brainstorm experiments new Marketplace for freelance designers
|
||||
/brainstorm # interactive mode — asks what you need
|
||||
```
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Determine Mode
|
||||
|
||||
Parse the arguments to identify two dimensions:
|
||||
|
||||
1. **What to brainstorm**: `ideas` (feature concepts) or `experiments` (validation tests)
|
||||
2. **Product stage**: `existing` (continuous discovery) or `new` (initial discovery)
|
||||
|
||||
If either dimension is missing, ask the user. If both are missing, ask:
|
||||
- "Are you brainstorming **ideas** for what to build, or **experiments** to validate assumptions?"
|
||||
- "Is this for an **existing** product or a **new** product concept?"
|
||||
|
||||
### Step 2: Gather Context
|
||||
|
||||
Ask the user for context. Be conversational — ask the most critical question first:
|
||||
|
||||
**For existing products:**
|
||||
- What is the product? Who are current users?
|
||||
- What opportunity area or problem space are you exploring?
|
||||
- Any constraints (technical debt, platform limitations, team capacity)?
|
||||
- What has been tried before?
|
||||
|
||||
**For new products:**
|
||||
- What is the product concept? What problem does it solve?
|
||||
- Who is the target user? What's their current alternative?
|
||||
- What stage are you at? (napkin sketch, validated problem, early prototype)
|
||||
- What are the riskiest assumptions?
|
||||
|
||||
Accept context from uploaded files (PRDs, research docs, strategy decks), pasted text, or conversation.
|
||||
|
||||
### Step 3: Generate Output
|
||||
|
||||
**If brainstorming ideas** — apply the **brainstorm-ideas-existing** or **brainstorm-ideas-new** skill:
|
||||
- Generate ideas from three perspectives: Product Manager (user value, business impact), Designer (UX, delight, accessibility), Engineer (technical innovation, platform leverage, scalability)
|
||||
- For each idea: name, description, target user impact, feasibility assessment
|
||||
- Rank the top 5 ideas with rationale
|
||||
- Flag which ideas could be quick wins vs. strategic bets
|
||||
|
||||
**If brainstorming experiments** — apply the **brainstorm-experiments-existing** or **brainstorm-experiments-new** skill:
|
||||
- For existing products: suggest A/B tests, prototypes, fake-door tests, wizard-of-oz, concierge experiments, and spikes
|
||||
- For new products: create XYZ+S hypotheses and suggest pretotype experiments (landing pages, explainer videos, pre-orders, concierge MVPs)
|
||||
- For each experiment: hypothesis, method, success criteria, effort estimate, expected timeline
|
||||
- Rank by learning-per-effort ratio
|
||||
|
||||
### Step 4: Deepen and Iterate
|
||||
|
||||
After presenting initial results, offer:
|
||||
- "Want me to **detail** any of these ideas into a fuller spec?"
|
||||
- "Should I **identify assumptions** behind the top ideas?" (chains into the `identify-assumptions-existing` or `identify-assumptions-new` skill)
|
||||
- "Want to **design experiments** to validate the top ideas?" (chains into experiment mode)
|
||||
- "Should I **prioritize** these against your current backlog?" (chains into the `prioritize-features` skill)
|
||||
|
||||
## Output Format
|
||||
|
||||
### For Ideas:
|
||||
```
|
||||
## Brainstorm: [Product/Feature Area]
|
||||
**Mode**: Ideas for [existing/new] product
|
||||
**Context**: [1-2 sentence summary]
|
||||
|
||||
### PM Perspective
|
||||
1. **[Idea Name]** — [description] | Impact: [H/M/L] | Effort: [H/M/L]
|
||||
2. ...
|
||||
|
||||
### Designer Perspective
|
||||
1. **[Idea Name]** — [description] | Impact: [H/M/L] | Effort: [H/M/L]
|
||||
2. ...
|
||||
|
||||
### Engineer Perspective
|
||||
1. **[Idea Name]** — [description] | Impact: [H/M/L] | Effort: [H/M/L]
|
||||
2. ...
|
||||
|
||||
### Top 5 Recommendations
|
||||
| Rank | Idea | Why | Quick Win? |
|
||||
|------|------|-----|------------|
|
||||
|
||||
### Next Steps
|
||||
[What to do with these ideas]
|
||||
```
|
||||
|
||||
### For Experiments:
|
||||
```
|
||||
## Experiment Design: [Product/Feature Area]
|
||||
**Mode**: Experiments for [existing/new] product
|
||||
|
||||
### Hypotheses
|
||||
1. **[Hypothesis]** — XYZ format: [X]% of [Y] will [Z] within [S timeframe]
|
||||
|
||||
### Recommended Experiments
|
||||
| # | Experiment | Tests Hypothesis | Method | Effort | Timeline |
|
||||
|---|-----------|-----------------|--------|--------|----------|
|
||||
|
||||
### Experiment Details
|
||||
[For each experiment: setup, success criteria, risks, what you'll learn]
|
||||
```
|
||||
|
||||
## Notes
|
||||
|
||||
- For existing products, ground ideas in current user behavior and validated problems
|
||||
- For new products, focus on desirability and feasibility risks first
|
||||
- If the user uploads a research doc or interview transcript, extract insights before brainstorming
|
||||
- Encourage breadth first, then depth — generate many ideas before evaluating
|
||||
@@ -0,0 +1,131 @@
|
||||
---
|
||||
description: Run a full product discovery cycle — from ideation through assumption mapping to experiment design
|
||||
argument-hint: "<product or feature idea>"
|
||||
---
|
||||
|
||||
# /discover -- Full Discovery Cycle
|
||||
|
||||
Run a structured product discovery process that moves from divergent thinking to focused validation. This command chains multiple skills into a single end-to-end workflow.
|
||||
|
||||
## Invocation
|
||||
|
||||
```
|
||||
/discover Smart notification system for our project management tool
|
||||
/discover New product: AI writing assistant for non-native speakers
|
||||
/discover # asks what you're discovering
|
||||
```
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Understand the Discovery Context
|
||||
|
||||
Determine whether this is:
|
||||
- **Existing product** — continuous discovery on a known product with real users
|
||||
- **New product** — initial discovery for a concept without validated demand
|
||||
|
||||
Ask the user:
|
||||
- What are you exploring? (product idea, feature area, opportunity space)
|
||||
- What do you already know? (prior research, customer feedback, data)
|
||||
- What decisions will this discovery inform? (build/kill, prioritize, pivot)
|
||||
|
||||
Accept context from uploaded files (research, PRDs, transcripts, data), links, or conversation.
|
||||
|
||||
### Step 2: Brainstorm Ideas (Divergent Phase)
|
||||
|
||||
Apply the **brainstorm-ideas-existing** or **brainstorm-ideas-new** skill:
|
||||
|
||||
- Generate ideas from PM, Designer, and Engineer perspectives
|
||||
- Present the top 10 ideas with brief rationale
|
||||
- Ask the user to select 3-5 ideas to carry forward, or accept all
|
||||
|
||||
**Checkpoint**: "Here are 10 ideas. Which ones should we stress-test? Pick 3-5, or I can carry all forward."
|
||||
|
||||
### Step 3: Identify Assumptions (Critical Thinking Phase)
|
||||
|
||||
For each selected idea, apply the **identify-assumptions-existing** or **identify-assumptions-new** skill:
|
||||
|
||||
- Surface assumptions across risk categories:
|
||||
- **Value**: Will users want this?
|
||||
- **Usability**: Can users figure it out?
|
||||
- **Feasibility**: Can we build it?
|
||||
- **Viability**: Does the business case work?
|
||||
- **Go-to-Market** (new products only): Can we reach and convert users?
|
||||
- Use devil's advocate multi-perspective analysis
|
||||
- Compile a master list of all assumptions across all ideas
|
||||
|
||||
### Step 4: Prioritize Assumptions (Focus Phase)
|
||||
|
||||
Apply the **prioritize-assumptions** skill:
|
||||
|
||||
- Map assumptions on an Impact × Risk matrix
|
||||
- Identify the "leap of faith" assumptions — high impact, high uncertainty
|
||||
- Rank assumptions by test priority
|
||||
- Group related assumptions that can be tested together
|
||||
|
||||
**Checkpoint**: "Here are your riskiest assumptions. Which ones feel most critical to validate first?"
|
||||
|
||||
### Step 5: Design Experiments (Validation Phase)
|
||||
|
||||
For the top-priority assumptions, apply **brainstorm-experiments-existing** or **brainstorm-experiments-new** skill:
|
||||
|
||||
- Design 1-2 experiments per critical assumption
|
||||
- For existing products: A/B tests, fake doors, prototypes, user tests, data analysis
|
||||
- For new products: XYZ hypotheses, pretotypes, landing pages, concierge MVPs
|
||||
- Include success criteria, timeline, and effort for each
|
||||
- Sequence experiments by dependency and effort
|
||||
|
||||
### Step 6: Create Discovery Plan
|
||||
|
||||
Compile everything into a discovery plan document:
|
||||
|
||||
```
|
||||
## Discovery Plan: [Topic]
|
||||
|
||||
**Date**: [today]
|
||||
**Product Stage**: [existing/new]
|
||||
**Discovery Question**: [what we're trying to learn]
|
||||
|
||||
### Ideas Explored
|
||||
[Summary of brainstormed ideas with brief descriptions]
|
||||
|
||||
### Selected Ideas for Validation
|
||||
[3-5 ideas carried forward with rationale]
|
||||
|
||||
### Critical Assumptions
|
||||
| # | Assumption | Category | Impact | Uncertainty | Priority |
|
||||
|---|-----------|----------|--------|-------------|----------|
|
||||
|
||||
### Validation Experiments
|
||||
| # | Tests Assumption | Method | Success Criteria | Effort | Timeline |
|
||||
|---|-----------------|--------|-----------------|--------|----------|
|
||||
|
||||
### Experiment Details
|
||||
[For each experiment: hypothesis, setup, measurement, decision criteria]
|
||||
|
||||
### Discovery Timeline
|
||||
Week 1: [experiments]
|
||||
Week 2: [experiments]
|
||||
Week 3: [analysis and decision]
|
||||
|
||||
### Decision Framework
|
||||
- If [experiment] succeeds → proceed to [next step]
|
||||
- If [experiment] fails → [pivot/kill/investigate further]
|
||||
```
|
||||
|
||||
Save the plan as a markdown file to the user's workspace.
|
||||
|
||||
### Step 7: Offer Next Steps
|
||||
|
||||
- "Want me to **create a PRD** for the top idea?"
|
||||
- "Should I **design an interview script** to supplement these experiments?"
|
||||
- "Want me to **set up metrics** to track the experiments?"
|
||||
- "Should I **estimate effort** and create user stories for the MVP?"
|
||||
|
||||
## Notes
|
||||
|
||||
- This is a 15-30 minute structured workflow — let the user know upfront
|
||||
- At each checkpoint, the user can redirect, skip, or go deeper
|
||||
- If the user has research data, pull insights from it before brainstorming
|
||||
- The discovery plan should be a living document — offer to update it as experiments run
|
||||
- For new products, emphasize desirability validation before feasibility
|
||||
- For existing products, check if there's usage data that can inform assumptions
|
||||
@@ -0,0 +1,169 @@
|
||||
---
|
||||
description: Prepare a customer interview script or summarize an interview transcript into structured insights
|
||||
argument-hint: "[prep|summarize] <topic or transcript>"
|
||||
---
|
||||
|
||||
# /interview -- Customer Interview Prep & Summary
|
||||
|
||||
Two modes: **prep** creates a structured interview script before you talk to customers, **summarize** extracts insights after you've done the interview.
|
||||
|
||||
## Invocation
|
||||
|
||||
```
|
||||
/interview prep Onboarding experience for enterprise users
|
||||
/interview summarize [paste transcript or upload file]
|
||||
/interview # asks which mode you need
|
||||
```
|
||||
|
||||
## Modes
|
||||
|
||||
---
|
||||
|
||||
### Prep Mode
|
||||
|
||||
Create a structured interview script tailored to your research question.
|
||||
|
||||
#### Workflow
|
||||
|
||||
**Step 1: Understand the Research Goal**
|
||||
|
||||
Ask the user:
|
||||
- What are you trying to learn? (specific research question)
|
||||
- Who are you interviewing? (segment, role, relationship to product)
|
||||
- How much time do you have? (15 min, 30 min, 60 min)
|
||||
- What decisions will this research inform?
|
||||
|
||||
**Step 2: Generate Interview Script**
|
||||
|
||||
Apply the **interview-script** skill:
|
||||
|
||||
- Follow "The Mom Test" principles — ask about their life, not your idea
|
||||
- No leading questions, no pitching, focus on past behavior and real situations
|
||||
- Structure the script in sections:
|
||||
|
||||
```
|
||||
## Interview Script: [Research Topic]
|
||||
|
||||
**Research Question**: [what we're trying to learn]
|
||||
**Target Participant**: [who]
|
||||
**Duration**: [X] minutes
|
||||
|
||||
### Warm-up (3-5 min)
|
||||
[Rapport-building questions, role/context understanding]
|
||||
|
||||
### Core Exploration (15-40 min)
|
||||
[JTBD probing, past behavior, current workflow, pain points]
|
||||
- For each question: the question + why you're asking it + follow-up prompts
|
||||
|
||||
### Specific Topics (5-10 min)
|
||||
[Targeted questions about specific features or concepts — if needed]
|
||||
|
||||
### Wrap-up (3-5 min)
|
||||
[Open-ended closing, referral ask, next steps]
|
||||
|
||||
### Note-Taking Template
|
||||
[Pre-formatted template to capture insights during the interview]
|
||||
|
||||
### Red Flags to Watch For
|
||||
[Signs the conversation is going off-track or the participant is being polite rather than honest]
|
||||
```
|
||||
|
||||
**Step 3: Customize and Review**
|
||||
|
||||
- Adjust question count to fit the time slot
|
||||
- Add probing questions for specific hypotheses the user wants to test
|
||||
- Flag questions that might lead the witness
|
||||
- Offer a printable version (markdown file saved to workspace)
|
||||
|
||||
---
|
||||
|
||||
### Summarize Mode
|
||||
|
||||
Transform an interview transcript into structured, actionable insights.
|
||||
|
||||
#### Workflow
|
||||
|
||||
**Step 1: Accept the Transcript**
|
||||
|
||||
Accept in any format:
|
||||
- **Pasted text**: Raw transcript or notes
|
||||
- **Uploaded file**: Document, text file, or meeting notes export
|
||||
- **Audio summary**: If the user describes what was said (not a full transcript)
|
||||
|
||||
If the input is rough notes rather than a full transcript, work with what's available and note the limitations.
|
||||
|
||||
**Step 2: Extract and Structure**
|
||||
|
||||
Apply the **summarize-interview** skill:
|
||||
|
||||
Parse the transcript to identify:
|
||||
- **Participant profile**: Role, experience level, segment, context
|
||||
- **Jobs to Be Done**: What the participant is trying to accomplish
|
||||
- **Current workflow**: How they solve the problem today
|
||||
- **Pain points**: Frustrations, workarounds, time sinks
|
||||
- **Satisfaction signals**: What works well, moments of delight
|
||||
- **Quotes**: Verbatim quotes that capture key insights (with timestamps if available)
|
||||
- **Surprises**: Anything unexpected or that contradicts assumptions
|
||||
- **Feature reactions**: If specific features/concepts were discussed, capture reactions
|
||||
|
||||
**Step 3: Generate Interview Summary**
|
||||
|
||||
```
|
||||
## Interview Summary
|
||||
|
||||
**Participant**: [anonymized profile — role, segment, experience]
|
||||
**Date**: [if known]
|
||||
**Duration**: [if known]
|
||||
**Interviewer**: [if known]
|
||||
|
||||
### Key Insights
|
||||
1. **[Insight]** — [supporting evidence/quote]
|
||||
2. **[Insight]** — [supporting evidence/quote]
|
||||
3. ...
|
||||
|
||||
### Jobs to Be Done
|
||||
- **Primary JTBD**: [When I..., I want to..., so I can...]
|
||||
- **Related JTBDs**: [additional jobs]
|
||||
|
||||
### Current Workflow
|
||||
[How the participant currently solves the problem, step by step]
|
||||
|
||||
### Pain Points
|
||||
| Pain Point | Severity | Quote |
|
||||
|-----------|----------|-------|
|
||||
|
||||
### Satisfaction Signals
|
||||
| What Works | Why | Quote |
|
||||
|-----------|-----|-------|
|
||||
|
||||
### Notable Quotes
|
||||
> "[quote]" — on [topic]
|
||||
|
||||
### Assumptions Validated / Invalidated
|
||||
| Assumption | Status | Evidence |
|
||||
|-----------|--------|----------|
|
||||
|
||||
### Action Items
|
||||
- [ ] [Follow-up action from this interview]
|
||||
- [ ] [Research question to explore further]
|
||||
|
||||
### Raw Notes
|
||||
[If helpful, include annotated key sections]
|
||||
```
|
||||
|
||||
Save the summary as a markdown file.
|
||||
|
||||
**Step 4: Connect to Broader Research**
|
||||
|
||||
Offer:
|
||||
- "Want me to **compare this with other interview summaries** you've done?"
|
||||
- "Should I **update assumptions** based on what this participant said?"
|
||||
- "Want me to **extract personas** from multiple interviews?"
|
||||
|
||||
## Notes
|
||||
|
||||
- In prep mode, always include "why you're asking" annotations — they help the interviewer stay on track
|
||||
- In summarize mode, distinguish between what the participant *said* vs. what they *did* (behavioral > stated)
|
||||
- Flag contradictions within the same interview (says one thing, describes doing another)
|
||||
- If the transcript mentions competitor products, capture competitive intelligence
|
||||
- For summarize mode, if multiple transcripts are provided, synthesize across them with cross-participant patterns
|
||||
@@ -0,0 +1,119 @@
|
||||
---
|
||||
description: Design a product metrics dashboard with North Star metric, input metrics, health metrics, and alert thresholds
|
||||
argument-hint: "<product or feature area>"
|
||||
---
|
||||
|
||||
# /setup-metrics -- Product Metrics Dashboard Design
|
||||
|
||||
Design a comprehensive metrics framework for your product or feature — from selecting the right North Star to defining alert thresholds that catch problems early.
|
||||
|
||||
## Invocation
|
||||
|
||||
```
|
||||
/setup-metrics SaaS project management tool
|
||||
/setup-metrics New checkout flow we just launched
|
||||
/setup-metrics # asks what you're measuring
|
||||
```
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Understand What to Measure
|
||||
|
||||
Ask the user:
|
||||
- What product or feature area are you setting up metrics for?
|
||||
- What stage is it in? (pre-launch, recently launched, mature)
|
||||
- What are the current business goals or OKRs?
|
||||
- Do you have existing metrics? What's missing or broken?
|
||||
- What analytics tools are you using? (helps tailor implementation advice)
|
||||
|
||||
### Step 2: Define the Metrics Framework
|
||||
|
||||
Apply the **metrics-dashboard** skill:
|
||||
|
||||
**North Star Metric:**
|
||||
- Identify the single metric that best captures the value your product delivers to users
|
||||
- Validate against criteria: measures value delivery, is a leading indicator, is actionable
|
||||
- Define the metric precisely (formula, data source, time window)
|
||||
|
||||
**Input Metrics (3-5):**
|
||||
- Identify the levers that drive the North Star
|
||||
- Each input metric should be directly actionable by a team
|
||||
- Map the causal chain: Input → North Star → Business Outcome
|
||||
|
||||
**Health Metrics (3-5):**
|
||||
- Metrics that should stay stable — if they degrade, something is wrong
|
||||
- Examples: error rates, latency, support ticket volume, NPS, churn rate
|
||||
- Define "healthy" ranges and degradation thresholds
|
||||
|
||||
**Counter-Metrics (1-2):**
|
||||
- Metrics that could indicate you're optimizing the wrong way
|
||||
- Example: if North Star is "daily active users", counter-metric is "session quality" to prevent empty engagement
|
||||
|
||||
### Step 3: Design Alert Thresholds
|
||||
|
||||
For each metric:
|
||||
|
||||
| Metric | Green | Yellow | Red | Check Frequency |
|
||||
|--------|-------|--------|-----|----------------|
|
||||
| [metric] | [healthy range] | [warning] | [critical] | [daily/weekly] |
|
||||
|
||||
- **Yellow**: Investigate — something may be off
|
||||
- **Red**: Act immediately — page someone or escalate
|
||||
|
||||
### Step 4: Create Dashboard Spec
|
||||
|
||||
```
|
||||
## Metrics Dashboard: [Product/Feature]
|
||||
|
||||
**North Star**: [metric name]
|
||||
**Definition**: [precise formula]
|
||||
**Current value**: [if known]
|
||||
**Target**: [goal]
|
||||
|
||||
### Input Metrics
|
||||
| Metric | Definition | Owner | Target | Current |
|
||||
|--------|-----------|-------|--------|---------|
|
||||
|
||||
### Health Metrics
|
||||
| Metric | Healthy Range | Yellow Threshold | Red Threshold |
|
||||
|--------|-------------|-----------------|---------------|
|
||||
|
||||
### Counter-Metrics
|
||||
| Metric | Why It Matters | Watch For |
|
||||
|--------|---------------|-----------|
|
||||
|
||||
### Metrics Tree
|
||||
North Star: [metric]
|
||||
├── Input: [metric 1] → driven by [team/action]
|
||||
├── Input: [metric 2] → driven by [team/action]
|
||||
├── Input: [metric 3] → driven by [team/action]
|
||||
└── Counter: [metric] → watch for [degradation signal]
|
||||
|
||||
### Implementation Notes
|
||||
- Data sources: [where each metric comes from]
|
||||
- Refresh frequency: [real-time / hourly / daily]
|
||||
- Tool recommendations: [based on user's stack]
|
||||
|
||||
### Review Cadence
|
||||
- **Daily**: Glance at North Star and health metrics
|
||||
- **Weekly**: Review input metrics trends, discuss in team standup
|
||||
- **Monthly**: Deep dive — are inputs driving the North Star as expected?
|
||||
- **Quarterly**: Reassess the metrics framework itself
|
||||
```
|
||||
|
||||
Save as a markdown file to the user's workspace.
|
||||
|
||||
### Step 5: Offer Next Steps
|
||||
|
||||
- "Want me to **write SQL queries** to compute these metrics?"
|
||||
- "Should I **create OKRs** based on this metrics framework?"
|
||||
- "Want me to **build a cohort analysis** to set realistic baselines?"
|
||||
- "Should I **set up a weekly metrics review template**?"
|
||||
|
||||
## Notes
|
||||
|
||||
- A good North Star is rare — most teams pick vanity metrics. Push for a metric that captures *user value delivered*, not just engagement
|
||||
- Input metrics should be MECE (mutually exclusive, collectively exhaustive) in explaining the North Star
|
||||
- If the product is pre-launch, define metrics now but note that baselines will need calibration after launch
|
||||
- Counter-metrics prevent Goodhart's Law — when a metric becomes a target, it ceases to be a good metric
|
||||
- Recommend starting with fewer metrics, well-instrumented, over a sprawling dashboard nobody checks
|
||||
@@ -0,0 +1,120 @@
|
||||
---
|
||||
description: Analyze, categorize, and prioritize a batch of feature requests from customers or stakeholders
|
||||
argument-hint: "<feature requests as text, file, or paste>"
|
||||
---
|
||||
|
||||
# /triage-requests -- Feature Request Triage
|
||||
|
||||
Take a pile of feature requests — from support tickets, sales calls, surveys, or Slack — and turn them into a prioritized, actionable backlog.
|
||||
|
||||
## Invocation
|
||||
|
||||
```
|
||||
/triage-requests # asks for input
|
||||
/triage-requests [paste a list of requests]
|
||||
/triage-requests [upload a CSV/spreadsheet]
|
||||
```
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Accept Feature Requests
|
||||
|
||||
Accept requests in any format:
|
||||
- **Pasted text**: List of requests, one per line or paragraph
|
||||
- **Uploaded file**: CSV, Excel, or text file with request data
|
||||
- **Structured data**: If the input has columns (requester, request, date, etc.), preserve them
|
||||
|
||||
If no input is provided, ask the user to paste or upload their feature requests.
|
||||
|
||||
Parse each request to extract:
|
||||
- The core ask (what the user wants)
|
||||
- Context (who asked, when, why — if available)
|
||||
- Frequency signals (how many people asked for similar things)
|
||||
|
||||
### Step 2: Gather Prioritization Context
|
||||
|
||||
Ask the user (conversationally, not all at once):
|
||||
- What is the product? What stage is it in?
|
||||
- What are the current strategic goals or OKRs? (helps assess alignment)
|
||||
- Any constraints to consider? (team size, technical debt, upcoming deadlines)
|
||||
- Are there segments whose requests should carry more weight? (enterprise, churning users, power users)
|
||||
|
||||
### Step 3: Categorize and Analyze
|
||||
|
||||
Apply the **analyze-feature-requests** skill:
|
||||
|
||||
- **Theme clustering**: Group similar requests into themes (e.g., "reporting & analytics", "collaboration", "mobile experience")
|
||||
- **Request count per theme**: How many unique requests map to each theme
|
||||
- **Strategic alignment**: Rate each theme against stated goals (High/Medium/Low/None)
|
||||
- **Segment analysis**: Which user segments are driving which themes
|
||||
- **Sentiment signals**: Are requests accompanied by frustration, churn threats, or delight?
|
||||
|
||||
### Step 4: Prioritize
|
||||
|
||||
Apply the **prioritize-features** skill:
|
||||
|
||||
For each theme (and the top individual requests within each theme):
|
||||
|
||||
| Factor | Assessment |
|
||||
|--------|-----------|
|
||||
| **Impact** | How many users affected? How severely? |
|
||||
| **Strategic alignment** | Does it serve current goals? |
|
||||
| **Effort estimate** | T-shirt size (S/M/L/XL) |
|
||||
| **Risk** | What happens if we don't do this? |
|
||||
| **Revenue signal** | Is this tied to deals, retention, or expansion? |
|
||||
|
||||
Rank themes and produce a prioritized list.
|
||||
|
||||
### Step 5: Generate Triage Report
|
||||
|
||||
```
|
||||
## Feature Request Triage Report
|
||||
|
||||
**Date**: [today]
|
||||
**Requests analyzed**: [count]
|
||||
**Themes identified**: [count]
|
||||
|
||||
### Theme Summary
|
||||
| # | Theme | Requests | Top Ask | Alignment | Impact | Effort | Priority |
|
||||
|---|-------|----------|---------|-----------|--------|--------|----------|
|
||||
|
||||
### Priority 1: Act Now
|
||||
[Themes/requests to include in near-term planning]
|
||||
- **[Theme]**: [X] requests — [why it's urgent]
|
||||
- Top requests: [list]
|
||||
- Recommended action: [build / prototype / investigate]
|
||||
|
||||
### Priority 2: Plan Next
|
||||
[Themes worth planning but not urgent]
|
||||
|
||||
### Priority 3: Collect More Signal
|
||||
[Themes with potential but insufficient evidence]
|
||||
|
||||
### Priority 4: Decline or Defer
|
||||
[Requests that don't align with strategy — with rationale]
|
||||
|
||||
### Notable Individual Requests
|
||||
[High-value one-off requests that didn't cluster into themes]
|
||||
|
||||
### Patterns and Insights
|
||||
- [Key insight about what users are telling you]
|
||||
- [Segment-specific patterns]
|
||||
- [Gaps between what users ask for and underlying needs]
|
||||
```
|
||||
|
||||
Save the report as a markdown file to the user's workspace.
|
||||
|
||||
### Step 6: Offer Next Steps
|
||||
|
||||
- "Want me to **create user stories** for the top-priority items?"
|
||||
- "Should I **brainstorm solutions** for any of these themes?"
|
||||
- "Want me to **design experiments** to validate demand before building?"
|
||||
- "Should I **draft a stakeholder update** summarizing this analysis?"
|
||||
|
||||
## Notes
|
||||
|
||||
- If the user provides a CSV with columns, preserve the data structure and enrich it
|
||||
- Look for the need behind the request — "add dark mode" might really mean "reduce eye strain during long sessions"
|
||||
- Flag requests that conflict with each other (e.g., "simplify the UI" vs. "add more configuration options")
|
||||
- If request volume is large (50+), summarize themes first and offer to drill into specific themes on request
|
||||
- Output the enriched data as a downloadable CSV if the input was structured data
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
name: analyze-feature-requests
|
||||
description: "Analyze and prioritize a list of feature requests by theme, strategic alignment, impact, effort, and risk. Use when reviewing customer feature requests, triaging a backlog, or making prioritization decisions. Triggers: analyze feature requests, prioritize features, triage backlog, feature request analysis, customer requests."
|
||||
---
|
||||
|
||||
## Analyze Feature Requests
|
||||
|
||||
Categorize, evaluate, and prioritize customer feature requests against product goals.
|
||||
|
||||
### Context
|
||||
|
||||
You are analyzing feature requests for **$ARGUMENTS**.
|
||||
|
||||
If the user provides files (spreadsheets, CSVs, or documents with feature requests), read and analyze them directly. If data is in a structured format, consider creating a summary table.
|
||||
|
||||
### Domain Context
|
||||
|
||||
Never allow customers to design solutions. Prioritize **opportunities (problems)**, not features. Use **Opportunity Score** (Dan Olsen) to evaluate customer-reported problems: Opportunity Score = Importance × (1 − Satisfaction), normalized to 0–1. See the `prioritization-frameworks` skill for full details and templates.
|
||||
|
||||
### Instructions
|
||||
|
||||
The user will describe their product goal and provide feature requests. Work through these steps:
|
||||
|
||||
1. **Understand the goal**: Confirm the product objective and desired outcomes that will guide prioritization.
|
||||
|
||||
2. **Categorize requests into themes**: Group related requests together and name each theme.
|
||||
|
||||
3. **Assess strategic alignment**: For each theme, evaluate how well it aligns with the stated goals.
|
||||
|
||||
4. **Prioritize the top 3 features** based on:
|
||||
- **Impact**: Customer value and number of users affected
|
||||
- **Effort**: Development and design resources required
|
||||
- **Risk**: Technical and market uncertainty
|
||||
- **Strategic alignment**: Fit with product vision and goals
|
||||
|
||||
5. **For each top feature**, provide:
|
||||
- Rationale (customer needs, strategic alignment)
|
||||
- Alternative solutions worth considering
|
||||
- High-risk assumptions
|
||||
- How to test those assumptions with minimal effort
|
||||
|
||||
Think step by step. Save as markdown or create a structured output document.
|
||||
|
||||
---
|
||||
|
||||
### Further Reading
|
||||
|
||||
- [Kano Model: How to Delight Your Customers Without Becoming a Feature Factory](https://www.productcompass.pm/p/kano-model-how-to-delight-your-customers)
|
||||
- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course)
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
name: brainstorm-experiments-existing
|
||||
description: "Design experiments to test assumptions for an existing product. Suggests prototypes, A/B tests, spikes, and other low-effort validation methods. Use when you have assumptions to validate, need experiment ideas before full implementation, or want to test a feature idea cheaply. Triggers: experiment design, test assumptions, validate idea, prototype test, A/B test ideas."
|
||||
---
|
||||
|
||||
## Design Experiments (Existing Product)
|
||||
|
||||
Design low-effort experiments to test product assumptions before committing to full implementation.
|
||||
|
||||
### Context
|
||||
|
||||
You are helping a product team design experiments for **$ARGUMENTS**. The team has a feature idea and assumptions that need validation.
|
||||
|
||||
If the user provides files (PRDs, assumption lists, designs), read them first.
|
||||
|
||||
### Instructions
|
||||
|
||||
The user will describe their idea and assumptions. Work through these steps:
|
||||
|
||||
1. **Clarify the idea and assumptions**: Confirm what the team wants to build and what they need to validate.
|
||||
|
||||
2. **Suggest experiments** for each assumption. Consider methods like:
|
||||
- First-click testing or task completion with a prototype
|
||||
- Feature stubs or fake door tests
|
||||
- Technical spikes
|
||||
- A/B tests on production (with risk mitigation)
|
||||
- Wizard of Oz approaches
|
||||
- Survey-based validation (behavioral, not opinion-based)
|
||||
|
||||
3. **Key principles to follow**:
|
||||
- Measure actual behavior, not users' opinions
|
||||
- Test responsibly — don't put users or the business at risk
|
||||
- For production tests (e.g., A/B tests), explain risk mitigation strategies
|
||||
- Aim for maximum validated learning with minimal effort
|
||||
|
||||
4. **For each experiment**, specify:
|
||||
- **Assumption**: What do we believe?
|
||||
- **Experiment**: What exactly will we do to validate it?
|
||||
- **Metric**: What will be measured?
|
||||
- **Success threshold**: The expected value if we are right
|
||||
|
||||
Think step by step. Present experiments in a clear table or structured format. Save as markdown if substantial.
|
||||
|
||||
---
|
||||
|
||||
### Further Reading
|
||||
|
||||
- [Testing Product Ideas: The Ultimate Validation Experiments Library](https://www.productcompass.pm/p/the-ultimate-experiments-library)
|
||||
- [Assumption Prioritization Canvas: How to Identify And Test The Right Assumptions](https://www.productcompass.pm/p/assumption-prioritization-canvas)
|
||||
- [What Is Product Discovery? The Ultimate Guide Step-by-Step](https://www.productcompass.pm/p/what-exactly-is-product-discovery)
|
||||
- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course)
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
name: brainstorm-experiments-new
|
||||
description: "Design lean startup experiments (pretotypes) for a new product. Creates XYZ hypotheses and suggests low-effort validation methods like landing pages, explainer videos, and pre-orders. Use when validating a new product idea, creating pretotypes, or testing market demand. Triggers: lean startup experiment, pretotype, XYZ hypothesis, validate new product, test market demand."
|
||||
---
|
||||
|
||||
## Design Lean Startup Experiments (New Product)
|
||||
|
||||
Create XYZ hypotheses and design pretotype experiments to validate a new product concept with minimal effort.
|
||||
|
||||
### Context
|
||||
|
||||
You are helping validate a new product concept: **$ARGUMENTS** using lean startup methodology.
|
||||
|
||||
If the user provides files (market research, landing page mockups), read them first.
|
||||
|
||||
### Instructions
|
||||
|
||||
1. **Create an XYZ Hypothesis** in the form: "At least X% of Y will do Z"
|
||||
- **X%**: The percentage of the target market expected to engage
|
||||
- **Y**: The specific target market (e.g., "mid-size luxury sedan buyers")
|
||||
- **Z**: How they will engage with the product
|
||||
|
||||
2. **Suggest 2-3 pretotype experiments** to test the hypothesis with minimal effort. Consider:
|
||||
- **Landing Page**: Test interest by measuring sign-ups or clicks
|
||||
- **Explainer Video**: Test understanding and appeal through engagement metrics
|
||||
- **Email Campaign**: Test demand through response and click-through rates
|
||||
- **Pre-Order / Waitlist**: Test willingness to pay through skin-in-the-game commitment
|
||||
- **Concierge / Manual MVP**: Deliver the service manually to test value
|
||||
|
||||
3. **Key principles** (Alberto Savoia, *The Right It*):
|
||||
- **Skin-in-the-Game**: Test willingness to pay — not just interest. Real commitment (time, money, reputation) is the only reliable signal.
|
||||
- **Your Own Data (YODA)**: Collect your own data through experiments rather than relying on Others' Data (ODP) like market reports or analogies. "The market for your idea does not care about the market for someone else's idea."
|
||||
- Measure actual behavior, not users' opinions
|
||||
|
||||
4. **For each experiment**, specify the hypothesis being tested, the method, the metric, and the success threshold.
|
||||
|
||||
Think step by step. Save as markdown if substantial.
|
||||
|
||||
---
|
||||
|
||||
### Further Reading
|
||||
|
||||
- [How to Build the Right Product with Alberto Savoia (ex-Innovator at Google)](https://www.productcompass.pm/p/how-to-build-the-right-product-with)
|
||||
- [Testing Product Ideas: The Ultimate Validation Experiments Library](https://www.productcompass.pm/p/the-ultimate-experiments-library)
|
||||
- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course)
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
name: brainstorm-ideas-existing
|
||||
description: "Brainstorm product ideas for an existing product using multi-perspective ideation (PM, Designer, Engineer). Use when a PM wants to generate new feature ideas, brainstorm solutions for an identified opportunity, or ideate with a product trio. Triggers: brainstorm ideas, ideate features, new ideas existing product, product trio ideation, feature brainstorm."
|
||||
---
|
||||
|
||||
## Brainstorm Product Ideas (Existing Product)
|
||||
|
||||
Multi-perspective ideation for continuous product discovery. Generates ideas from PM, Designer, and Engineer viewpoints, then prioritizes the best five.
|
||||
|
||||
### Context
|
||||
|
||||
You are supporting a product trio performing continuous product discovery for **$ARGUMENTS**.
|
||||
|
||||
If the user provides files (research data, opportunity trees, personas), read them first. If they mention a product URL, use web search to understand the product.
|
||||
|
||||
### Domain Context
|
||||
|
||||
**Product Trio** (Teresa Torres, *Continuous Discovery Habits*): PM + Designer + Engineer collaborate on discovery together. "Best ideas often come from engineers." Discovery is not linear — loop back if experiments fail. Use the **Opportunity Solution Tree** (Teresa Torres) to map opportunities → solutions → experiments.
|
||||
|
||||
### Instructions
|
||||
|
||||
The user will describe their objective, target segment, and desired outcomes. Work through these steps:
|
||||
|
||||
1. **Understand the opportunity**: Confirm the product, objective, market segment, and desired outcomes. Ask for clarification if anything is ambiguous.
|
||||
|
||||
2. **Ideate from three perspectives** — generate 5 ideas each from:
|
||||
- **Product Manager**: Focus on business value, strategic alignment, and customer impact
|
||||
- **Product Designer**: Focus on user experience, usability, and delight
|
||||
- **Software Engineer**: Focus on technical possibilities, data leverage, and scalable solutions
|
||||
|
||||
3. **Prioritize the top 5 ideas** across all perspectives based on:
|
||||
- Strategic alignment with the stated objective
|
||||
- Potential impact on desired outcomes
|
||||
- Feasibility and effort required
|
||||
- Differentiation from existing solutions
|
||||
|
||||
4. **For each prioritized idea**, provide:
|
||||
- A clear name and one-sentence description
|
||||
- Why it was selected (reasoning)
|
||||
- Key assumptions to validate
|
||||
|
||||
Think step by step. Present ideas in a clear, structured format.
|
||||
|
||||
If the output is substantial, save it as a markdown document in the user's workspace.
|
||||
|
||||
---
|
||||
|
||||
### Further Reading
|
||||
|
||||
- [What Is Product Discovery? The Ultimate Guide Step-by-Step](https://www.productcompass.pm/p/what-exactly-is-product-discovery)
|
||||
- [Product Trio: Beyond the Obvious](https://www.productcompass.pm/p/product-trio)
|
||||
- [The Extended Opportunity Solution Tree](https://www.productcompass.pm/p/the-extended-opportunity-solution-tree)
|
||||
- [Product Model First Principles: Product Discovery, Product Delivery, and Product Culture In Depth](https://www.productcompass.pm/p/product-model-first-principles-discovery-deliver)
|
||||
- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course)
|
||||
@@ -0,0 +1,46 @@
|
||||
---
|
||||
name: brainstorm-ideas-new
|
||||
description: "Brainstorm feature ideas for a new product in initial discovery. Generates ideas from PM, Designer, and Engineer perspectives. Use when starting product discovery for a new product, exploring features for a startup idea, or doing initial ideation. Triggers: new product ideas, startup features, initial discovery, new product brainstorm."
|
||||
---
|
||||
|
||||
## Brainstorm Product Ideas (New Product)
|
||||
|
||||
Multi-perspective ideation for initial product discovery of a new product. Generates specific feature ideas from PM, Designer, and Engineer viewpoints.
|
||||
|
||||
### Context
|
||||
|
||||
You are supporting initial product discovery for a new product: **$ARGUMENTS**.
|
||||
|
||||
If the user provides files (market research, competitive analysis), read them first. Use web search to understand the market if needed.
|
||||
|
||||
### Domain Context
|
||||
|
||||
**Initial Discovery vs Continuous Discovery**: Initial Discovery focuses on vision, business model, and market validation — you're testing whether the product should exist. Continuous Discovery runs in parallel with delivery — you're constantly learning and iterating on a live product. This skill is for **initial discovery**.
|
||||
|
||||
### Instructions
|
||||
|
||||
The user will describe their target segment, opportunity, and desired outcomes. Work through these steps:
|
||||
|
||||
1. **Understand the opportunity**: Confirm the product concept, target market segment, and what the users want to achieve.
|
||||
|
||||
2. **Ideate from three perspectives** — generate 5 specific feature ideas each from:
|
||||
- **Product Manager**: Focus on market fit, value creation, and competitive advantage
|
||||
- **Product Designer**: Focus on user experience, onboarding, and engagement
|
||||
- **Software Engineer**: Focus on technical innovation, API integrations, and platform capabilities
|
||||
|
||||
3. **Prioritize the top 5 ideas** across all perspectives. For a new product, weight heavily toward:
|
||||
- Core value delivery (does it solve the primary problem?)
|
||||
- Speed to validate (can we test this quickly?)
|
||||
- Differentiation potential
|
||||
|
||||
4. **For each prioritized idea**, provide reasoning and key assumptions to test.
|
||||
|
||||
Think step by step. Save substantial output as a markdown document.
|
||||
|
||||
---
|
||||
|
||||
### Further Reading
|
||||
|
||||
- [Startup Canvas: Product Strategy and a Business Model for a New Product](https://www.productcompass.pm/p/startup-canvas)
|
||||
- [Product Innovation Masterclass](https://www.productcompass.pm/p/product-innovation-masterclass) (video course)
|
||||
- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course)
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
name: identify-assumptions-existing
|
||||
description: "Identify risky assumptions for a feature idea in an existing product across Value, Usability, Viability, and Feasibility. Uses multi-perspective devil's advocate thinking. Use when stress-testing a feature idea, doing risk assessment, or preparing for assumption mapping. Triggers: identify assumptions, risk assessment, devil's advocate, assumption mapping, feature risks, what could go wrong."
|
||||
---
|
||||
|
||||
## Identify Assumptions (Existing Product)
|
||||
|
||||
Devil's advocate analysis to surface risky assumptions across four risk areas.
|
||||
|
||||
### Context
|
||||
|
||||
You are stress-testing a feature idea for **$ARGUMENTS**.
|
||||
|
||||
If the user provides files (designs, PRDs, research), read them first.
|
||||
|
||||
### Instructions
|
||||
|
||||
The user will describe their product, objective, market segment, and feature idea. Work through these steps:
|
||||
|
||||
1. **Think from three perspectives** about why this feature might fail:
|
||||
- **Product Manager perspective**: Business viability, market fit, strategic alignment
|
||||
- **Designer perspective**: Usability, user experience, adoption barriers
|
||||
- **Engineer perspective**: Technical feasibility, performance, integration challenges
|
||||
|
||||
2. **Identify assumptions across four risk areas**:
|
||||
- **Value**: Will it create value for customers? Does it solve a real problem?
|
||||
- **Usability**: Will users figure out how to use it? Is the learning curve acceptable?
|
||||
- **Viability**: Can marketing, sales, finance, and legal support it?
|
||||
- **Feasibility**: Can it be built with existing technology? Are there integration risks?
|
||||
|
||||
3. **For each assumption**, note:
|
||||
- What specifically could go wrong
|
||||
- How confident you are (High/Medium/Low)
|
||||
- Suggested way to test it
|
||||
|
||||
Think step by step. Be thorough but constructive — the goal is to strengthen the idea, not kill it.
|
||||
|
||||
---
|
||||
|
||||
### Further Reading
|
||||
|
||||
- [Assumption Prioritization Canvas: How to Identify And Test The Right Assumptions](https://www.productcompass.pm/p/assumption-prioritization-canvas)
|
||||
- [How to Manage Risks as a Product Manager](https://www.productcompass.pm/p/how-to-manage-risks-as-a-product-manager)
|
||||
- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course)
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
name: identify-assumptions-new
|
||||
description: "Identify risky assumptions for a new product idea across 8 risk categories including Go-to-Market, Strategy, and Team. Uses multi-perspective analysis. Use when launching a new product, evaluating startup risks, or assessing a new product concept. Triggers: new product risks, startup assumptions, GTM risk, launch risk assessment, new product viability."
|
||||
---
|
||||
|
||||
## Identify Assumptions (New Product)
|
||||
|
||||
Comprehensive risk identification across 8 categories — extending the 4 core product risks (Teresa Torres, *Continuous Discovery Habits*) with Ethics, Go-to-Market, Strategy & Objectives, and Team risks that are critical for new products.
|
||||
|
||||
### Context
|
||||
|
||||
You are evaluating assumptions for a new product: **$ARGUMENTS**.
|
||||
|
||||
If the user provides files (business plans, research), read them first.
|
||||
|
||||
### Domain Context
|
||||
|
||||
**The 4 core product risks** (Teresa Torres, *Continuous Discovery Habits*): Value, Usability, Viability, Feasibility.
|
||||
|
||||
**For new products, extend to 8 risk categories.** Good teams assume at least three-quarters of their ideas won't perform as they hope.
|
||||
|
||||
### Instructions
|
||||
|
||||
The user will describe the product concept, target segment, and feature idea. Work through these steps:
|
||||
|
||||
1. **Think from three perspectives** about why this product might fail:
|
||||
- **Product Manager**: Market demand, willingness to pay, competitive landscape
|
||||
- **Designer**: First-time user experience, onboarding, engagement
|
||||
- **Engineer**: Build vs. buy decisions, scalability, technical debt
|
||||
|
||||
2. **Identify assumptions across 8 risk categories**:
|
||||
|
||||
- **Value**: Will it create value for customers? Will they keep using it?
|
||||
- **Usability**: Will people figure out how to use it? Can we onboard them fast enough? Will it increase cognitive load?
|
||||
- **Viability**: Can we sell/monetize/finance it? Is it worth the cost? Can we support customers and help them succeed? Can we scale? Will it be compliant?
|
||||
- **Feasibility**: Can we do it with the current technology? Is this integration possible? Can it be efficient? Can we scale it?
|
||||
- **Ethics**: Should we do it at all? Are there any ethical considerations? Will it pose a risk for our customers?
|
||||
- **Go-to-Market** (especially critical for new products): Can we market it? Do we have the required channels? Can we convince customers to try it? Is this the right messaging for this channel? Is this the right time? Is this the right way to launch it?
|
||||
- **Strategy & Objectives**: What are our assumptions? Can others copy our strategy? Have we considered political, economic, legal, technological, and environmental factors? Are those the best problems to solve?
|
||||
- **Team**: How well will the team work together? Do we have the right people? Do we have the right tools? Will the entire team stay with us long enough?
|
||||
|
||||
3. **For each assumption**, rate confidence and suggest a test.
|
||||
|
||||
Think step by step. Save as markdown.
|
||||
|
||||
---
|
||||
|
||||
### Further Reading
|
||||
|
||||
- [Assumption Prioritization Canvas: How to Identify And Test The Right Assumptions](https://www.productcompass.pm/p/assumption-prioritization-canvas)
|
||||
- [What Is Product Discovery? The Ultimate Guide Step-by-Step](https://www.productcompass.pm/p/what-exactly-is-product-discovery)
|
||||
- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course)
|
||||
@@ -0,0 +1,105 @@
|
||||
---
|
||||
name: interview-script
|
||||
description: "Create a structured customer interview script with JTBD probing questions, warm-up, core exploration, and wrap-up sections. Follows 'The Mom Test' principles — no leading questions, no pitching, focus on past behavior. Use when preparing for user interviews, creating interview guides, or planning discovery research. Triggers: interview script, interview guide, user interview questions, discovery interview, customer interview prep, how to interview users."
|
||||
---
|
||||
|
||||
## Customer Interview Script
|
||||
|
||||
Create a structured interview script that surfaces real insights, not just opinions. Follows "The Mom Test" principles — ask about their life, not your idea.
|
||||
|
||||
### Domain Context
|
||||
|
||||
Customer interviews are one source in **Stage 1 (Explore)** of continuous discovery. Other sources: stakeholder interviews, usage analytics, data analytics, surveys, market trends, SEO/SEM analysis. The PM needs direct access to users, stakeholders, engineers, and designers — "without proxies." The **Product Trio** (PM + Designer + Engineer — Teresa Torres) should work together on discovery, not just the PM alone.
|
||||
|
||||
### Context
|
||||
|
||||
You are preparing a customer interview script for research on **$ARGUMENTS**.
|
||||
|
||||
If the user provides files (personas, hypothesis lists, product briefs, or previous interview notes), read them first.
|
||||
|
||||
### Instructions
|
||||
|
||||
1. **Clarify research objectives**:
|
||||
- What specific questions does the team need answered?
|
||||
- What decisions will this research inform?
|
||||
- What assumptions need validation?
|
||||
|
||||
2. **Create the interview script** with these sections:
|
||||
|
||||
### Opening (2-3 min)
|
||||
- Introduce yourself and the purpose (learning, not selling)
|
||||
- Set expectations: "There are no right or wrong answers. We're here to learn from your experience."
|
||||
- Ask permission to record (if applicable)
|
||||
- Confirm time available
|
||||
|
||||
### Warm-Up: Context & Background (5 min)
|
||||
- "Tell me about your role and what a typical day/week looks like."
|
||||
- "How long have you been doing [activity related to the product area]?"
|
||||
- Goal: Build rapport and understand their context
|
||||
|
||||
### Core Exploration: Jobs to Be Done (15-20 min)
|
||||
|
||||
**Current situation and behavior** (past tense, specific instances):
|
||||
- "Walk me through the last time you [did the thing we're exploring]. What happened?"
|
||||
- "What tools or methods did you use?"
|
||||
- "How long did it take? Who else was involved?"
|
||||
|
||||
**Pain points and frustrations** (observe, don't lead):
|
||||
- "What was the hardest part about that?"
|
||||
- "If you could wave a magic wand, what would change?"
|
||||
- "What have you tried to solve this? What happened?"
|
||||
|
||||
**Desired outcomes** (their words, not yours):
|
||||
- "What does 'good' look like for you in this area?"
|
||||
- "How would you know if this was working well?"
|
||||
|
||||
**Willingness to pay / priority** (skin in the game):
|
||||
- "How much time/money do you currently spend on this?"
|
||||
- "Have you looked for a better solution? What did you find?"
|
||||
- "What would you give up to have this solved?"
|
||||
|
||||
### Probing Techniques
|
||||
Use these when you hit an interesting thread:
|
||||
- **"Tell me more about that"** — opens up any topic
|
||||
- **"Why?"** (asked gently, 2-3 times) — gets to root causes
|
||||
- **"Can you give me a specific example?"** — moves from opinions to facts
|
||||
- **"What happened next?"** — follows the story
|
||||
- **"How did that make you feel?"** — captures emotional intensity
|
||||
|
||||
### The Mom Test Rules
|
||||
- Ask about **their life**, not your idea
|
||||
- Ask about **the past**, not the future ("Would you use X?" is useless)
|
||||
- **Talk less, listen more** — aim for 80/20 split
|
||||
- **Never pitch** during the interview
|
||||
- Look for **strong emotions** — they signal real pain or delight
|
||||
- **Compliments are noise** — "That sounds cool!" tells you nothing
|
||||
|
||||
### Wrap-Up (3-5 min)
|
||||
- "Is there anything I didn't ask that you think is important?"
|
||||
- "Who else should I talk to about this?"
|
||||
- Thank them for their time
|
||||
- Share next steps (if any)
|
||||
|
||||
3. **Customize the script**: Adapt questions to the specific product area, persona, and research objectives. Add or remove sections based on the interview length available.
|
||||
|
||||
4. **Include a note-taking template**:
|
||||
```
|
||||
Participant: [Name / ID]
|
||||
Date: [Date]
|
||||
Key Jobs: [What they're trying to accomplish]
|
||||
Current Solution: [What they use today]
|
||||
Biggest Pain: [Their #1 frustration]
|
||||
Desired Outcome: [What success looks like]
|
||||
Willingness to Pay: [How much they invest / would invest]
|
||||
Surprise Finding: [Something unexpected]
|
||||
Follow-up: [Next steps]
|
||||
```
|
||||
|
||||
Save as markdown. Include both the script and the note-taking template.
|
||||
|
||||
---
|
||||
|
||||
### Further Reading
|
||||
|
||||
- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate)
|
||||
- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course)
|
||||
@@ -0,0 +1,94 @@
|
||||
---
|
||||
name: metrics-dashboard
|
||||
description: "Define and design a product metrics dashboard with key metrics, data sources, visualization types, and alert thresholds. Use when creating a metrics dashboard, defining KPIs, setting up product analytics, or building a data monitoring plan. Triggers: metrics dashboard, product dashboard, KPI dashboard, analytics setup, what to track, product metrics, monitoring."
|
||||
---
|
||||
|
||||
## Product Metrics Dashboard
|
||||
|
||||
Design a comprehensive product metrics dashboard with the right metrics, visualizations, and alert thresholds.
|
||||
|
||||
### Context
|
||||
|
||||
You are designing a metrics dashboard for **$ARGUMENTS**.
|
||||
|
||||
If the user provides files (existing dashboards, analytics data, OKRs, or strategy docs), read them first.
|
||||
|
||||
### Domain Context
|
||||
|
||||
**Metrics vs KPIs vs NSM**: Metrics = all measurable things. KPIs = a few key quantitative metrics tracked over a longer period. North Star Metric = a single customer-centric KPI that is a leading indicator of business success.
|
||||
|
||||
**4 criteria for a good metric** (Ben Yoskovitz, *Lean Analytics*): (1) Understandable — creates a common language. (2) Comparative — over time, not a snapshot. (3) Ratio or Rate — more revealing than whole numbers. (4) Behavior-changing — the Golden Rule: "If a metric won't change how you behave, it's a bad metric."
|
||||
|
||||
**8 metric types**: Vanity vs Actionable (only actionable metrics change behavior), Qualitative vs Quantitative (WHAT vs WHY — you need both; never stop talking to customers), Exploratory vs Reporting (explore data to uncover unexpected insights), Lagging vs Leading (leading indicators enable faster learning cycles, e.g. customer complaints predict churn).
|
||||
|
||||
**5 action steps**: (1) Audit metrics against the 4 good-metric criteria. (2) Update dashboards — ensure all key metrics are good ones. (3) Identify vanity metrics — be careful how you use them. (4) Classify leading vs lagging indicators. (5) Pick one problem and dig deep into the data.
|
||||
|
||||
For case studies and more detail: [Are You Tracking the Right Metrics?](https://www.productcompass.pm/p/are-you-tracking-the-right-metrics) by Ben Yoskovitz
|
||||
|
||||
### Instructions
|
||||
|
||||
1. **Identify the metrics framework** — organize metrics into layers:
|
||||
|
||||
**North Star Metric**: The single metric that best captures core value delivery
|
||||
|
||||
**Input Metrics** (3-5): The levers that drive the North Star
|
||||
|
||||
**Health Metrics**: Guardrails that ensure overall product health
|
||||
|
||||
**Business Metrics**: Revenue, cost, and unit economics
|
||||
|
||||
2. **For each metric, define**:
|
||||
|
||||
| Metric | Definition | Data Source | Visualization | Target | Alert Threshold |
|
||||
|---|---|---|---|---|---|
|
||||
| [Name] | [Exact calculation: numerator/denominator, time window] | [Where the data comes from] | [Line chart / Bar / Number / Funnel] | [Goal value] | [When to trigger an alert] |
|
||||
|
||||
3. **Design the dashboard layout**:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────┐
|
||||
│ NORTH STAR: [Metric] — [Current Value] │
|
||||
│ Trend: [↑/↓ X% vs last period] │
|
||||
├──────────────────┬──────────────────────────┤
|
||||
│ Input Metric 1 │ Input Metric 2 │
|
||||
│ [Sparkline] │ [Sparkline] │
|
||||
├──────────────────┼──────────────────────────┤
|
||||
│ Input Metric 3 │ Input Metric 4 │
|
||||
│ [Sparkline] │ [Sparkline] │
|
||||
├──────────────────┴──────────────────────────┤
|
||||
│ HEALTH: [Latency] [Error Rate] [NPS] │
|
||||
├─────────────────────────────────────────────┤
|
||||
│ BUSINESS: [MRR] [CAC] [LTV] [Churn] │
|
||||
└─────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
4. **Set review cadence**:
|
||||
- **Daily**: Operational health (errors, latency, critical flows)
|
||||
- **Weekly**: Input metrics and engagement trends
|
||||
- **Monthly**: North Star, business metrics, OKR progress
|
||||
- **Quarterly**: Strategic review and metric recalibration
|
||||
|
||||
5. **Define alerts**:
|
||||
- What thresholds trigger investigation?
|
||||
- Who gets alerted and through what channel?
|
||||
- What's the expected response time?
|
||||
|
||||
6. **Recommend tools** based on the user's context:
|
||||
- Amplitude, Mixpanel, PostHog for product analytics
|
||||
- Looker, Metabase, Mode for SQL-based dashboards
|
||||
- Datadog, Grafana for operational health
|
||||
|
||||
Think step by step. Save the dashboard specification as a markdown document.
|
||||
|
||||
---
|
||||
|
||||
### Further Reading
|
||||
|
||||
- [The Ultimate List of Product Metrics](https://www.productcompass.pm/p/the-ultimate-list-of-product-metrics)
|
||||
- [The North Star Framework 101](https://www.productcompass.pm/p/the-north-star-framework-101)
|
||||
- [The Product Analytics Playbook: AARRR, HEART, Cohorts & Funnels for PMs](https://www.productcompass.pm/p/the-product-analytics-playbook-aarrr)
|
||||
- [AARRR (Pirate) Metrics: The 5-Stage Framework for Growth](https://www.productcompass.pm/p/aarrr-pirate-metrics)
|
||||
- [The Google HEART Framework: Your Guide to Measuring User-Centric Success](https://www.productcompass.pm/p/the-google-heart-framework)
|
||||
- [Funnel Analysis 101: How to Track and Optimize Your User Journey](https://www.productcompass.pm/p/funnel-analysis)
|
||||
- [Are You Tracking the Right Metrics?](https://www.productcompass.pm/p/are-you-tracking-the-right-metrics)
|
||||
- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course)
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
name: opportunity-solution-tree
|
||||
description: "Build an Opportunity Solution Tree (OST) to structure product discovery — map a desired outcome to opportunities, solutions, and experiments. Based on Teresa Torres' Continuous Discovery Habits. Use when structuring discovery work, mapping customer opportunities to solutions, or deciding what to build next. Triggers: opportunity solution tree, OST, discovery tree, Teresa Torres, opportunity mapping, what to build next."
|
||||
---
|
||||
|
||||
## Opportunity Solution Tree (OST)
|
||||
|
||||
A visual framework for structuring continuous product discovery. Connects a desired **outcome** to customer **opportunities**, possible **solutions**, and **experiments** to validate them.
|
||||
|
||||
### Domain Context
|
||||
|
||||
The **Opportunity Solution Tree** (Teresa Torres, *Continuous Discovery Habits*) is the backbone of modern product discovery. It prevents teams from jumping to solutions by forcing them to first map the opportunity space.
|
||||
|
||||
**Structure (4 levels):**
|
||||
|
||||
1. **Desired Outcome** (top) — The measurable business or product outcome the team is pursuing. Should be a single, clear metric (e.g., "increase 7-day retention to 40%"). This comes from your OKRs or product strategy.
|
||||
|
||||
2. **Opportunities** (second level) — Customer needs, pain points, or desires discovered through research. These are problems worth solving — not features. Frame them from the customer's perspective: "I struggle to..." or "I wish I could..." Prioritize using Opportunity Score: **Importance × (1 − Satisfaction)** (Dan Olsen, *The Lean Product Playbook*). Normalize Importance and Satisfaction to 0–1.
|
||||
|
||||
3. **Solutions** (third level) — Possible ways to address each opportunity. Generate multiple solutions per opportunity — don't commit to the first idea. The **Product Trio** (PM + Designer + Engineer) should ideate together. "Best ideas often come from engineers."
|
||||
|
||||
4. **Experiments** (bottom) — Fast, cheap tests to validate whether a solution actually addresses the opportunity. Use assumption testing (Value, Usability, Viability, Feasibility risks). Prefer experiments with "skin-in-the-game" (Alberto Savoia) over opinion-based validation.
|
||||
|
||||
**Key principles:**
|
||||
|
||||
- **One outcome at a time.** Don't try to solve everything. Focus the tree on a single desired outcome.
|
||||
- **Opportunities, not features.** "Never allow customers to design solutions. Prioritize opportunities (problems), not features."
|
||||
- **Compare and contrast.** Always generate at least 3 solutions per opportunity before choosing. Avoid the "first idea" trap.
|
||||
- **Discovery is not linear.** Loop back if experiments fail. Kill solutions that don't validate. Explore new branches.
|
||||
- **Continuous, not periodic.** Update the tree weekly as you learn from interviews, analytics, and experiments.
|
||||
|
||||
### Instructions
|
||||
|
||||
You are helping a product team build an Opportunity Solution Tree for **$ARGUMENTS**.
|
||||
|
||||
### Input Requirements
|
||||
- A desired outcome or business metric to improve
|
||||
- Customer research data (interviews, surveys, analytics, feedback)
|
||||
- Optionally: existing opportunities or solution ideas to organize
|
||||
|
||||
### Process
|
||||
|
||||
1. **Define the desired outcome** — Confirm or help articulate a single, measurable outcome at the top of the tree.
|
||||
|
||||
2. **Map opportunities** — From provided research, identify 3-7 customer opportunities (needs/pains). Group related opportunities. Frame each from the customer's perspective.
|
||||
|
||||
3. **Prioritize opportunities** — Use Opportunity Score or qualitative assessment to rank. Focus on the top 2-3.
|
||||
|
||||
4. **Generate solutions** — For each prioritized opportunity, brainstorm 3+ solutions from PM, Designer, and Engineer perspectives.
|
||||
|
||||
5. **Design experiments** — For the most promising solutions, suggest 1-2 fast experiments. Specify: hypothesis, method, metric, success threshold.
|
||||
|
||||
6. **Visualize the tree** — Present the full OST in a clear hierarchical format.
|
||||
|
||||
Think step by step. Save as markdown if substantial.
|
||||
|
||||
---
|
||||
|
||||
### Further Reading
|
||||
|
||||
- [The Extended Opportunity Solution Tree](https://www.productcompass.pm/p/the-extended-opportunity-solution-tree)
|
||||
- [What Is Product Discovery? The Ultimate Guide Step-by-Step](https://www.productcompass.pm/p/what-exactly-is-product-discovery)
|
||||
- [Product Trio: Beyond the Obvious](https://www.productcompass.pm/p/product-trio)
|
||||
- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course)
|
||||
@@ -0,0 +1,48 @@
|
||||
---
|
||||
name: prioritize-assumptions
|
||||
description: "Prioritize assumptions using an Impact × Risk matrix and suggest experiments for each. Use when you have a list of assumptions to triage, need to decide what to test first, or want to apply assumption prioritization canvas. Triggers: prioritize assumptions, assumption matrix, what to test first, risk assessment, assumption canvas."
|
||||
---
|
||||
|
||||
## Prioritize Assumptions
|
||||
|
||||
Triage assumptions using an Impact × Risk matrix and suggest targeted experiments.
|
||||
|
||||
### Context
|
||||
|
||||
You are helping prioritize assumptions for **$ARGUMENTS**.
|
||||
|
||||
If the user provides files with assumptions or research data, read them first.
|
||||
|
||||
### Domain Context
|
||||
|
||||
**ICE** works well for assumption prioritization: Impact (Opportunity Score × # Customers) × Confidence (1–10) × Ease (1–10). Opportunity Score = Importance × (1 − Satisfaction), normalized to 0–1 (Dan Olsen). **RICE** splits Impact into Reach × Impact separately: (R × I × C) / E. See the `prioritization-frameworks` skill for full formulas and templates.
|
||||
|
||||
### Instructions
|
||||
|
||||
The user will provide a list of assumptions to prioritize. Apply the following framework:
|
||||
|
||||
1. **For each assumption**, evaluate two dimensions:
|
||||
- **Impact**: The value created by validating this assumption AND the number of customers affected (in ICE: Impact = Opportunity Score × # Customers)
|
||||
- **Risk**: Defined as (1 - Confidence) × Effort
|
||||
|
||||
2. **Categorize each assumption** using the Impact × Risk matrix:
|
||||
- **Low Impact, Low Risk** → Defer testing until higher-priority assumptions are addressed
|
||||
- **High Impact, Low Risk** → Proceed to implementation (low risk, high reward)
|
||||
- **Low Impact, High Risk** → Reject the idea (not worth the investment)
|
||||
- **High Impact, High Risk** → Design an experiment to test it
|
||||
|
||||
3. **For each assumption requiring testing**, suggest an experiment that:
|
||||
- Maximizes validated learning with minimal effort
|
||||
- Measures actual behavior, not opinions
|
||||
- Has a clear success metric and threshold
|
||||
|
||||
4. **Present results** as a prioritized matrix or table.
|
||||
|
||||
Think step by step. Save as markdown if the output is substantial.
|
||||
|
||||
---
|
||||
|
||||
### Further Reading
|
||||
|
||||
- [Assumption Prioritization Canvas: How to Identify And Test The Right Assumptions](https://www.productcompass.pm/p/assumption-prioritization-canvas)
|
||||
- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course)
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
name: prioritize-features
|
||||
description: "Prioritize a backlog of feature ideas based on impact, effort, risk, and strategic alignment. Recommends top 5 features with rationale. Use when prioritizing a feature backlog, making scope decisions, or ranking product ideas. Triggers: prioritize features, feature ranking, backlog prioritization, which features first, scope decision."
|
||||
---
|
||||
|
||||
## Prioritize Feature Backlog
|
||||
|
||||
Evaluate and rank a backlog of feature ideas to identify the top 5 to pursue.
|
||||
|
||||
### Context
|
||||
|
||||
You are helping prioritize features for **$ARGUMENTS**.
|
||||
|
||||
If the user provides files (spreadsheets, backlogs, opportunity assessments), read and analyze them directly.
|
||||
|
||||
### Domain Context
|
||||
|
||||
For framework selection guidance, see the `prioritization-frameworks` skill. Key recommendations:
|
||||
|
||||
**Opportunity Score** (Dan Olsen, *The Lean Product Playbook*) is recommended for evaluating customer problems: Opportunity Score = Importance × (1 − Satisfaction), normalized to 0–1. High Importance + low Satisfaction = best opportunities. Prioritize **problems (opportunities)**, not solutions.
|
||||
|
||||
**ICE** is recommended for quick scoring of initiatives: Impact (Opportunity Score × # Customers) × Confidence × Ease. **RICE** adds Reach as a separate factor for larger teams.
|
||||
|
||||
### Instructions
|
||||
|
||||
The user will describe their product objective, desired outcomes, and provide feature ideas. Work through these steps:
|
||||
|
||||
1. **Understand priorities**: Confirm the product objective and success metrics.
|
||||
|
||||
2. **Evaluate each feature** against:
|
||||
- **Impact**: How much does it move the needle on desired outcomes? Consider Opportunity Score if customer data is available.
|
||||
- **Effort**: How much development, design, and coordination is required?
|
||||
- **Risk**: How much uncertainty exists? What assumptions need testing?
|
||||
- **Strategic alignment**: How well does it fit the product vision and current goals?
|
||||
|
||||
3. **Recommend the top 5 features** with:
|
||||
- Clear ranking (1-5)
|
||||
- Brief rationale for each selection
|
||||
- Key trade-offs considered
|
||||
- What was deprioritized and why
|
||||
|
||||
4. **Present as a prioritization table** if helpful.
|
||||
|
||||
Think step by step. Save as markdown if the output is substantial.
|
||||
|
||||
---
|
||||
|
||||
### Further Reading
|
||||
|
||||
- [Kano Model: How to Delight Your Customers Without Becoming a Feature Factory](https://www.productcompass.pm/p/kano-model-how-to-delight-your-customers)
|
||||
- [The Product Management Frameworks Compendium + Templates](https://www.productcompass.pm/p/the-product-frameworks-compendium)
|
||||
- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course)
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
name: summarize-interview
|
||||
description: "Summarize a customer interview transcript into a structured template with JTBD, satisfaction signals, and action items. Use when processing customer interview recordings or transcripts, synthesizing discovery interviews, or creating interview summaries. Triggers: summarize interview, customer interview notes, interview summary, discovery interview, user interview."
|
||||
---
|
||||
|
||||
## Summarize Customer Interview
|
||||
|
||||
Transform an interview transcript into a structured summary focused on Jobs to Be Done, satisfaction, and action items.
|
||||
|
||||
### Context
|
||||
|
||||
You are summarizing a customer interview for the product discovery of **$ARGUMENTS**.
|
||||
|
||||
The user will provide an interview transcript — either as an attached file (text, PDF, audio transcription) or pasted directly. Read any attached files first.
|
||||
|
||||
### Instructions
|
||||
|
||||
1. **Read the full transcript** carefully before summarizing.
|
||||
|
||||
2. **Fill in the summary template** below. Use "-" if information is unavailable. Replace numeric values with qualitative descriptions if needed (e.g., "not satisfied").
|
||||
|
||||
3. **Use clear, simple language** — a primary school graduate should be able to understand the summary.
|
||||
|
||||
### Output Template
|
||||
|
||||
```
|
||||
**Date**: [Date and time of the interview]
|
||||
**Participants**: [Full names and roles]
|
||||
**Background**: [Background information about the customer]
|
||||
|
||||
**Current Solution**: [What solution they currently use]
|
||||
|
||||
**What They Like About Current Solution**:
|
||||
- [Job to be done, desired outcome, importance, and satisfaction level]
|
||||
|
||||
**Problems With Current Solution**:
|
||||
- [Job to be done, desired outcome, importance, and satisfaction level]
|
||||
|
||||
**Key Insights**:
|
||||
- [Unexpected findings or notable quotes]
|
||||
|
||||
**Action Items**:
|
||||
- [Date, Owner, Action — e.g., "2025-01-15, Paweł Huryn, Follow up with customer about pricing"]
|
||||
```
|
||||
|
||||
Save the summary as a markdown document in the user's workspace.
|
||||
|
||||
---
|
||||
|
||||
### Further Reading
|
||||
|
||||
- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate)
|
||||
- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course)
|
||||
Reference in New Issue
Block a user