v1.0

pm-product-discovery/commands/brainstorm.md

@@ -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

pm-product-discovery/commands/discover.md

@@ -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

pm-product-discovery/commands/interview.md

@@ -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

pm-product-discovery/commands/setup-metrics.md

@@ -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

pm-product-discovery/commands/triage-requests.md

@@ -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