v1.0
This commit is contained in:
@@ -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