Compare commits
11 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 mohitagw15856
|
994bf95eba | ||
|
mohitagw15856
|
4accc3407c | ||
|
mohitagw15856
|
4e66c45520 | ||
|
mohitagw15856
|
6947f16685 | ||
|
mohitagw15856
|
c08080a60a | ||
|
mohitagw15856
|
6617faa3ac | ||
|
mohitagw15856
|
0b53f2caa3 | ||
|
mohitagw15856
|
be0349866a | ||
|
mohitagw15856
|
06aae11156 | ||
|
mohitagw15856
|
251994bab1 | ||
|
mohitagw15856
|
bd2c51feb3 |
@@ -0,0 +1,15 @@
|
||||
# These are supported funding model platforms
|
||||
|
||||
github: # Replace with up to 4 GitHub Sponsors-enabled usernames e.g., [user1, user2]
|
||||
patreon: # Replace with a single Patreon username
|
||||
open_collective: # Replace with a single Open Collective username
|
||||
ko_fi: # Replace with a single Ko-fi username
|
||||
tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
|
||||
community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
|
||||
liberapay: # Replace with a single Liberapay username
|
||||
issuehunt: # Replace with a single IssueHunt username
|
||||
lfx_crowdfunding: # Replace with a single LFX Crowdfunding project-name e.g., cloud-foundry
|
||||
polar: # Replace with a single Polar username
|
||||
buy_me_a_coffee: mohit15856
|
||||
thanks_dev: # Replace with a single thanks.dev username
|
||||
custom: # Replace with up to 4 custom sponsorship URLs e.g., ['link1', 'link2']
|
||||
@@ -5,7 +5,15 @@
|
||||
[](https://opensource.org/licenses/MIT)
|
||||
[](https://github.com/mohitagw15856/pm-claude-skills/stargazers)
|
||||
|
||||
> 📖 **Background**: These Skills emerged from my widely-read Medium article ["Claude Skills: The AI Feature That's Quietly Changing How Product Managers Work"](https://medium.com/product-powerhouse/claude-skills-the-ai-feature-thats-quietly-changing-how-product-managers-work-aad5d8d0640a), where I documented how Skills transformed my daily PM workflow, saving 3-4 hours per week.
|
||||
|
||||
> 📖 **Background**: Built across a four-part Medium series:
|
||||
> - [Part 1 — How Skills changed my PM workflow](https://medium.com/product-powerhouse/claude-skills-the-ai-feature-thats-quietly-changing-how-product-managers-work-aad5d8d0640a)
|
||||
> - [Part 2 — The complete 12-skill toolkit](https://medium.com/@mohit15856/12-claude-skills-for-product-managers-the-complete-toolkit-with-skill-files-for-jira-figma-fcc73a4c1e58)
|
||||
> - [Part 3 — Building Skills the right way (official guide)](https://medium.com/@mohit15856/claude-skills-advanced-guide-what-3-months-of-daily-pm-use-actually-taught-me-18324d6ef7bc)
|
||||
> - [Part 4 — Advanced skills based on what top companies want](https://medium.com/product-powerhouse/claude-skills-the-ai-feature-thats-quietly-changing-how-product-managers-work-aad5d8d0640a)
|
||||
>
|
||||
> Product Management Skills for Claude AI — 18 skills across the full PM lifecycle. Save 10+ hours per week.
|
||||
|
||||
|
||||
## What Are These Skills?
|
||||
|
||||
@@ -44,13 +52,64 @@ That's it! Claude now knows your PRD format.
|
||||
| **User Research Synthesis** | Analyze and synthesize research findings | 2-3 hrs/study | [View](skills/user-research-synthesis) |
|
||||
| **Competitive Analysis** | Structured competitive assessments | 1-2 hrs/analysis | [View](skills/competitive-analysis) |
|
||||
|
||||
### Coming Soon 🔜
|
||||
### Discovery & User Research
|
||||
| **User Interview Synthesis** | Synthesise transcripts into structured findings | Notion | [View](skills/user-interview-synthesis) |
|
||||
| **Assumption Mapper** | Risk-rate hidden assumptions in any PRD | Miro | [View](skills/assumption-mapper) |
|
||||
|
||||
### Roadmapping & Prioritisation
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
| **RICE Prioritisation** | Score and rank initiatives objectively | Jira | [View](skills/rice-prioritisation) |
|
||||
| **Roadmap Narrative** | Turn ranked lists into strategic narratives | Notion, Miro | [View](skills/roadmap-narrative) |
|
||||
| **RICE + Impact Matrix** | RICE scoring + strategic alignment combined | Miro, Jira | [View](skills/rice-impact-matrix) |
|
||||
|
||||
### Sprint & Delivery
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
| **Sprint Brief** | Generate sprint briefs from Jira data | Jira, Slack | [View](skills/sprint-brief) |
|
||||
| **Retro Analysis** | Data-grounded retrospective briefs | Jira, Miro | [View](skills/retro-analysis) |
|
||||
|
||||
### Data & Metrics
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
| **Product Health Analysis** | Interpret metrics and surface signals | Analytics | [View](skills/product-health-analysis) |
|
||||
|
||||
### Strategy & Competitive Intel
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
| **Competitor Signal Tracker** | Analyse competitor moves strategically | Notion | [View](skills/competitor-signal-tracker) |
|
||||
|
||||
### Stakeholder Communication
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
| **PRD Template** | Standardized product requirements | — | [View](skills/prd-template) |
|
||||
| **Meeting Notes** | Structured meeting documentation | — | [View](skills/meeting-notes) |
|
||||
| **Stakeholder Update** | Executive status updates | — | [View](skills/stakeholder-update) |
|
||||
| **Executive Update** | Sharp executive briefings | Slack, Teams | [View](skills/executive-update) |
|
||||
|
||||
### Go-to-Market & Launch
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
| **Launch Readiness** | Pre-launch go/no-go assessment | Notion, Jira, Slack | [View](skills/launch-readiness) |
|
||||
|
||||
### Cross-functional Collaboration
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
| **User Research Synthesis** | Analyze and synthesize research findings | Notion | [View](skills/user-research-synthesis) |
|
||||
| **Competitive Analysis** | Structured competitive assessments | — | [View](skills/competitive-analysis) |
|
||||
| **Design Handoff Brief** | PM-to-designer structured briefs | Figma, Notion | [View](skills/design-handoff-brief) |
|
||||
|
||||
### 🧠 Advanced Skills (Part 4 — Role-Based Capabilities)
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
| **Competitive Intelligence Monitor** | Weekly diff-based competitor tracking | Notion, OpenClaw | [View](skills/competitive-intelligence-monitor) |
|
||||
| **Experiment Designer** | A/B test design + results interpretation | Analytics | [View](skills/experiment-designer) |
|
||||
| **Stakeholder Influence Mapper** | Influence strategy + tailored talking points | Slack | [View](skills/stakeholder-influence-mapper) |
|
||||
| **Ambiguity Resolver** | Structures vague briefs into actionable problem statements | Notion | [View](skills/ambiguity-resolver) |
|
||||
| **Multi-Source Signal Synthesiser** | Reconciles user signals across all research channels | Notion, OpenClaw | [View](skills/multi-source-signal-synthesiser) |
|
||||
| **Strategic Narrative Generator** | Roadmap-to-strategy storytelling for executives | Notion | [View](skills/strategic-narrative-generator) |
|
||||
|
||||
|
||||
- Data Analysis Standard
|
||||
- Roadmap Presentation
|
||||
- Quarterly Planning
|
||||
- Product Launch Checklist
|
||||
- Technical Specification Template
|
||||
|
||||
Want a specific Skill? [Request it here](https://github.com/mohitagw15856/pm-claude-skills/issues/new?template=skill-request.md)
|
||||
|
||||
@@ -85,7 +144,7 @@ Want a specific Skill? [Request it here](https://github.com/mohitagw15856/pm-cla
|
||||
|
||||
### Method 2: Clone the Repo
|
||||
|
||||
```bash
|
||||
bash
|
||||
# Clone the repository
|
||||
git clone https://github.com/mohitagw15856/pm-claude-skills.git
|
||||
cd pm-claude-skills
|
||||
@@ -96,7 +155,7 @@ zip -r ../../prd-template.skill .
|
||||
cd ../..
|
||||
|
||||
# Now upload prd-template.skill to Claude
|
||||
```
|
||||
|
||||
|
||||
### Method 3: Direct Download (When Available)
|
||||
|
||||
@@ -190,6 +249,7 @@ A: Yes! MIT license allows commercial use.
|
||||
- 📝 [Original Medium Article](https://medium.com/product-powerhouse/claude-skills-the-ai-feature-thats-quietly-changing-how-product-managers-work-aad5d8d0640a)
|
||||
- 💼 [Connect on LinkedIn](www.linkedin.com/in/mohitaggarwal4)
|
||||
- ✉️ [Email me](mailto:mohit15856@gmail.com)
|
||||
- Writing these up and refining them took a fair few evenings. If they saved you some time, a [coffee](https://buymeacoffee.com/mohit15856) is always appreciated
|
||||
|
||||
## 🙏 Acknowledgments
|
||||
|
||||
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
name: ambiguity-resolver
|
||||
description: Structures vague opportunities and unclear briefs into actionable
|
||||
one-page problem statements. Use when user has a vague brief, undefined problem,
|
||||
unclear opportunity, or says "we need to figure out what to do about X", "can
|
||||
you help me make sense of this", or "I've been asked to look into Y".
|
||||
metadata:
|
||||
author: Mohit Aggarwal
|
||||
version: 1.0.0
|
||||
category: discovery
|
||||
tags: [discovery, strategy, problem-framing, ambiguity]
|
||||
documentation: https://github.com/mohitagw15856/pm-claude-skills
|
||||
---
|
||||
# Ambiguity Resolver Skill
|
||||
|
||||
## Purpose
|
||||
Turn vague briefs and half-formed opportunities into structured, actionable
|
||||
problem statements — so you can reply with clarity instead of asking for three
|
||||
more meetings.
|
||||
|
||||
## Three-Stage Process
|
||||
|
||||
### Stage 1: Reframe
|
||||
- Restate the vague input as 3-5 explicit questions that need answering
|
||||
- Identify the unstated assumptions hidden in the brief
|
||||
- Surface the real decision this feeds into (what will someone do differently
|
||||
once this is resolved?)
|
||||
|
||||
### Stage 2: Scope
|
||||
- Define what is explicitly IN scope
|
||||
- Define what is explicitly OUT of scope (equally important)
|
||||
- Identify the deadline pressure: is this urgent/important, important/not urgent,
|
||||
or unclear?
|
||||
- Name who owns the final decision and who needs to be consulted
|
||||
|
||||
### Stage 3: Action
|
||||
- Define the minimum viable research: 2-3 activities maximum that would give
|
||||
enough signal to move forward with confidence
|
||||
- Time estimate for each activity
|
||||
- What each activity would tell you (and what it wouldn't)
|
||||
- Proposed check-in point: when to regroup before committing to more
|
||||
|
||||
## Output Format
|
||||
|
||||
### Problem Brief: [Opportunity Area]
|
||||
|
||||
**Restated as questions:**
|
||||
1. [Question 1]
|
||||
2. [Question 2]
|
||||
3. [Question 3]
|
||||
|
||||
**Unstated assumptions we should surface:**
|
||||
- [Assumption 1]
|
||||
- [Assumption 2]
|
||||
|
||||
**In scope:** [Clear boundary]
|
||||
**Out of scope:** [Clear boundary]
|
||||
**Decision owner:** [Name/role]
|
||||
**Timeline:** [Real deadline if known, or "unclear — recommend setting one"]
|
||||
|
||||
**Minimum viable research:**
|
||||
| Activity | Time required | What it tells us |
|
||||
|----------|--------------|------------------|
|
||||
| [activity] | [time] | [insight] |
|
||||
|
||||
**Proposed check-in:** After [activity], regroup to decide whether to proceed
|
||||
or pivot.
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
name: assumption-mapper
|
||||
description: Extract and risk-rate all hidden assumptions in a product brief or PRD
|
||||
tool_integration: Miro
|
||||
---
|
||||
# Assumption Mapping Skill
|
||||
|
||||
## Purpose
|
||||
Surface and prioritize the untested assumptions embedded in any product plan before development begins.
|
||||
|
||||
## Process
|
||||
1. Read the provided brief, PRD, or concept description
|
||||
2. Extract all assumptions across four categories:
|
||||
- **Desirability** (do users want this?)
|
||||
- **Feasibility** (can we build it?)
|
||||
- **Viability** (will it sustain the business?)
|
||||
- **Usability** (can users actually use it?)
|
||||
3. For each assumption, score:
|
||||
- Confidence (1-5): How sure are we this is true?
|
||||
- Impact (1-5): How badly does the plan fail if this assumption is wrong?
|
||||
- Priority = Impact minus Confidence (higher score = test this first)
|
||||
4. Output a ranked list with recommended validation methods
|
||||
|
||||
## Output Format
|
||||
|
||||
### Assumption Map: [Feature/Product Name]
|
||||
| Assumption | Category | Confidence | Impact | Priority Score | Recommended Validation |
|
||||
|------------|----------|------------|--------|----------------|----------------------|
|
||||
| [assumption] | [type] | [1-5] | [1-5] | [score] | [method] |
|
||||
|
||||
#### Top 3 Assumptions to Validate First
|
||||
[Detailed recommendations for highest-priority items]
|
||||
|
||||
## Notes
|
||||
- Flag any assumption that scores 4+ on Impact and 2 or below on Confidence as CRITICAL
|
||||
- Suggest specific research methods: usability test, survey, prototype test, data analysis
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
name: competitive-intelligence-monitor
|
||||
description: Continuously monitors competitor signals and surfaces strategic
|
||||
implications for your roadmap. Use when user asks to "monitor competitors",
|
||||
"track competitive landscape", "what are competitors doing this week",
|
||||
"competitive briefing", or "what has changed in the market".
|
||||
metadata:
|
||||
author: Mohit Aggarwal
|
||||
version: 1.0.0
|
||||
category: strategy
|
||||
tags: [strategy, competitive-intel, roadmapping]
|
||||
documentation: https://github.com/mohitagw15856/pm-claude-skills
|
||||
---
|
||||
# Competitive Intelligence Monitor Skill
|
||||
|
||||
## Purpose
|
||||
Turn scattered competitor updates into structured weekly intelligence — not just
|
||||
"what they did" but "what changed since last week and what it means for us."
|
||||
|
||||
## Signal Categories to Monitor
|
||||
- **Product signals:** New features, removals, UX changes, beta programmes
|
||||
- **Pricing signals:** Changes to tiers, free limits, enterprise terms
|
||||
- **Hiring signals:** Job postings revealing strategic bets
|
||||
- **Partnership signals:** Integrations, acquisitions, ecosystem moves
|
||||
- **Messaging signals:** Changes in positioning, audience, value proposition
|
||||
|
||||
## Process
|
||||
|
||||
### First Run (Full Report)
|
||||
1. For each competitor provided, scan all five signal categories
|
||||
2. Categorise each signal found
|
||||
3. Assess: reactive (responding to market) or proactive (setting direction)?
|
||||
4. Rate threat level: High / Medium / Low / Watch
|
||||
5. Connect each signal to a specific item on the provided roadmap
|
||||
6. Recommend response: Accelerate / Deprioritise / Monitor / Investigate
|
||||
|
||||
### Subsequent Runs (Diff Only)
|
||||
1. Compare current signals against previous run summary
|
||||
2. Output ONLY what is new or changed since last run
|
||||
3. Flag if a previously Low signal has escalated to High
|
||||
4. Keep output under 300 words — brevity is the point
|
||||
|
||||
## Output Format
|
||||
|
||||
### Competitive Intelligence Brief — [Date]
|
||||
**New Since Last Run:** [n signals]
|
||||
|
||||
#### 🔴 High Priority
|
||||
**[Competitor]:** [Signal] → [Implication] → [Recommended action + owner]
|
||||
|
||||
#### 🟡 Watch
|
||||
**[Competitor]:** [Signal] → [Why it matters now]
|
||||
|
||||
#### ✅ No Change
|
||||
[Competitors with no new signals this week]
|
||||
|
||||
**This Week's Strategic Summary:**
|
||||
[2 sentences max — what is the overall competitive landscape doing?]
|
||||
|
||||
## OpenClaw Configuration
|
||||
Add to YAML frontmatter for scheduled runs:
|
||||
`schedule: weekly-monday-0800`
|
||||
Persistent memory stores last run summary for diff comparison.
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: competitor-signal-tracker
|
||||
description: Analyse competitor moves and surface strategic implications for your product
|
||||
tool_integration: Notion
|
||||
---
|
||||
# Competitor Signal Tracker Skill
|
||||
|
||||
## Purpose
|
||||
Turn scattered competitor information into structured strategic intelligence — not just "what they did" but "what it means for us."
|
||||
|
||||
## Signal Categories to Track
|
||||
- **Product signals:** New features, removals, UX changes, beta programmes
|
||||
- **Pricing signals:** Changes to tiers, free limits, enterprise terms
|
||||
- **Hiring signals:** Job postings that reveal strategic bets (e.g., hiring ML engineers = AI investment)
|
||||
- **Partnership signals:** Integrations, acquisitions, ecosystem moves
|
||||
- **Messaging signals:** Changes in positioning, target audience, value proposition
|
||||
|
||||
## Process
|
||||
1. For each competitor update provided, categorise the signal type
|
||||
2. Assess: Is this reactive (responding to market) or proactive (setting direction)?
|
||||
3. Rate strategic threat level: High / Medium / Low / Watch
|
||||
4. Connect to your roadmap: does this accelerate, validate, or challenge any of your bets?
|
||||
5. Recommend a response: Accelerate existing initiative / Deprioritise / Monitor / Investigate further
|
||||
|
||||
## Output Format
|
||||
|
||||
### Competitive Intelligence Report — [Date]
|
||||
|
||||
#### [Competitor Name]
|
||||
**Signal:** [What they did]
|
||||
**Signal Type:** [Product / Pricing / Hiring / Partnership / Messaging]
|
||||
**Reactive or Proactive:** [assessment]
|
||||
**Threat Level:** [High / Medium / Low / Watch]
|
||||
**Implication for Us:** [Specific connection to our roadmap or strategy]
|
||||
**Recommended Response:** [Action + owner + timeline]
|
||||
|
||||
#### Strategic Summary
|
||||
[2-3 sentences on the overall competitive landscape shift this week/month]
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
name: design-handoff-brief
|
||||
description: Transform feature briefs into structured design briefs that give designers the context they need
|
||||
tool_integration: Figma, Notion
|
||||
---
|
||||
# Design Handoff Brief Skill
|
||||
|
||||
## Purpose
|
||||
Produce a design brief that sets designers up for success — grounding them in user context and constraints before they open Figma, not after they've gone in the wrong direction.
|
||||
|
||||
## What Designers Actually Need (and PMs Often Skip)
|
||||
- The user's goal, not the feature name
|
||||
- The emotional state of the user at this moment in the journey
|
||||
- What success looks like — how will we know the design worked?
|
||||
- Constraints: technical, legal, brand, accessibility
|
||||
- Edge cases that must be handled
|
||||
- What we're explicitly NOT solving for
|
||||
|
||||
## Process
|
||||
1. Read the feature brief or PRD provided
|
||||
2. Extract user goal (reframe from feature language to user outcome language)
|
||||
3. Identify constraints — technical limitations, brand guidelines, accessibility requirements
|
||||
4. List edge cases the design must handle
|
||||
5. Define success criteria the design should be evaluated against
|
||||
6. Write a "not in scope" section to prevent scope creep in design
|
||||
|
||||
## Output Format
|
||||
|
||||
### Design Brief: [Feature Name]
|
||||
|
||||
**User Goal:** (in the user's words, not ours)
|
||||
"When I [situation], I want to [motivation] so that I can [outcome]."
|
||||
|
||||
**Context & Emotional State:**
|
||||
[Where is the user in their journey? What are they feeling? What just happened?]
|
||||
|
||||
**Design Success Criteria:**
|
||||
- [Criterion 1 — measurable where possible]
|
||||
- [Criterion 2]
|
||||
- [Criterion 3]
|
||||
|
||||
**Constraints:**
|
||||
- Technical: [limitations engineering has flagged]
|
||||
- Brand: [relevant brand guidelines]
|
||||
- Accessibility: [WCAG level required, any specific requirements]
|
||||
- Legal/Compliance: [if applicable]
|
||||
|
||||
**Edge Cases to Design For:**
|
||||
- [Edge case 1]
|
||||
- [Edge case 2]
|
||||
- [Edge case 3]
|
||||
|
||||
**Explicitly Out of Scope:**
|
||||
- [What we are NOT solving in this design iteration]
|
||||
|
||||
**Reference Material:**
|
||||
- User research: [link]
|
||||
- Existing patterns: [Figma component library link]
|
||||
- Competitor examples: [links if relevant]
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
name: executive-update
|
||||
description: Transform detailed product updates into concise executive briefings
|
||||
tool_integration: Slack, Microsoft Teams
|
||||
---
|
||||
# Executive Update Skill
|
||||
|
||||
## Purpose
|
||||
Produce a stakeholder update that busy executives will actually read — structured around what they care about: decisions, risks, and numbers.
|
||||
|
||||
## Executive Communication Principles
|
||||
- Lead with the headline, not the context
|
||||
- Every update should answer: "So what does this mean for the business?"
|
||||
- Flag decisions needed clearly — don't bury asks in paragraphs
|
||||
- Be honest about risks — executives hate surprises more than bad news
|
||||
|
||||
## Process
|
||||
1. Read the full product update provided
|
||||
2. Identify: key metric movements, decisions required, risks to flag, wins to celebrate
|
||||
3. Write in reverse pyramid style — most important first
|
||||
4. Limit to 250 words maximum for the main body
|
||||
5. Add a "Decisions Needed" section with clear options and your recommendation
|
||||
|
||||
## Output Format
|
||||
|
||||
### Product Update — [Date / Sprint / Month]
|
||||
**Headline:** [One sentence on the most important thing]
|
||||
|
||||
**By the Numbers:**
|
||||
- [Metric 1]: [value] ([vs. target / last period])
|
||||
- [Metric 2]: [value] ([vs. target / last period])
|
||||
- [Metric 3]: [value] ([vs. target / last period])
|
||||
|
||||
**Progress This Period:**
|
||||
[3-4 bullet points, outcome-focused not activity-focused]
|
||||
|
||||
**Risks & Watch Items:**
|
||||
[2-3 bullets — be direct, include mitigation]
|
||||
|
||||
**Decisions Needed:**
|
||||
1. [Decision] — Options: [A] or [B] — Recommendation: [your view] — Needed by: [date]
|
||||
|
||||
**What's Next:**
|
||||
[2-3 bullets on next period priorities]
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: experiment-designer
|
||||
description: Designs A/B tests from hypotheses and interprets experiment results
|
||||
with statistical rigour. Use when user says "run an experiment", "design an A/B
|
||||
test", "test this feature", "interpret these results", "was this experiment
|
||||
successful", or "what sample size do I need".
|
||||
metadata:
|
||||
author: Mohit Aggarwal
|
||||
version: 1.0.0
|
||||
category: data-and-metrics
|
||||
tags: [experimentation, data, analytics, ab-testing]
|
||||
documentation: https://github.com/mohitagw15856/pm-claude-skills
|
||||
---
|
||||
# Experiment Designer Skill
|
||||
|
||||
## Purpose
|
||||
Produce rigorous experiment designs from product hypotheses, and interpret
|
||||
results with statistical and practical significance — so you can defend every
|
||||
decision to a sceptical engineering lead or data scientist.
|
||||
|
||||
## Two-Phase Process
|
||||
|
||||
### Phase 1: Experiment Design
|
||||
**Required inputs:** hypothesis, primary metric, current baseline, minimum
|
||||
detectable effect (MDE), available sample size per day.
|
||||
|
||||
**Output:**
|
||||
- Hypothesis restated as: "If we [change], we expect [metric] to [move by X%]
|
||||
because [reason]"
|
||||
- Control and variant definitions
|
||||
- Primary metric (one only)
|
||||
- Secondary guardrail metrics (2-3 max)
|
||||
- Required sample size (calculated from MDE and baseline)
|
||||
- Estimated run time in days
|
||||
- Pre-defined success criteria (before the test runs — no moving goalposts)
|
||||
- Design risk flags: novelty effects, seasonal confounds, multiple testing issues,
|
||||
network effects, sample ratio mismatch risks
|
||||
|
||||
### Phase 2: Results Interpretation
|
||||
**Required inputs:** control results, variant results, p-value or raw numbers,
|
||||
run duration, any anomalies observed.
|
||||
|
||||
**Output:**
|
||||
- Statistical significance assessment (p < 0.05 threshold)
|
||||
- Practical significance: was the lift meaningful for the business, not just real?
|
||||
- Confidence interval interpretation
|
||||
- Confounding factors to investigate
|
||||
- Recommendation: Ship / Iterate / Kill / Run follow-up test
|
||||
- If "Iterate": specific hypotheses to test next
|
||||
|
||||
## Quality Checks
|
||||
- Never interpret results from an underpowered test without flagging it
|
||||
- Always distinguish statistical from practical significance
|
||||
- Flag if test was stopped early (peeking problem)
|
||||
- Note if sample ratio mismatch occurred
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
name: launch-readiness
|
||||
description: Run a comprehensive pre-launch readiness assessment across all functions
|
||||
tool_integration: Notion, Jira, Slack
|
||||
---
|
||||
# Launch Readiness Skill
|
||||
|
||||
## Purpose
|
||||
Ensure nothing falls through the cracks before launch by systematically checking readiness across every function — and producing a clear, evidenced go/no-go recommendation.
|
||||
|
||||
## Readiness Checklist by Function
|
||||
|
||||
### Product & Engineering
|
||||
- [ ] Feature complete against launch spec
|
||||
- [ ] Performance benchmarks met
|
||||
- [ ] Accessibility standards checked
|
||||
- [ ] Edge cases documented and handled
|
||||
- [ ] Rollback plan defined
|
||||
|
||||
### Marketing & Comms
|
||||
- [ ] Launch messaging approved
|
||||
- [ ] Blog post / press release drafted
|
||||
- [ ] Social content prepared
|
||||
- [ ] Email campaigns scheduled
|
||||
- [ ] Landing page live and tested
|
||||
|
||||
### Support & Success
|
||||
- [ ] Support team trained on new feature
|
||||
- [ ] FAQ and help docs published
|
||||
- [ ] Escalation path defined for launch issues
|
||||
- [ ] Customer success briefed (if enterprise)
|
||||
|
||||
### Sales & Partnerships
|
||||
- [ ] Sales enablement materials ready
|
||||
- [ ] Pricing confirmed and communicated
|
||||
- [ ] Partner comms sent (if applicable)
|
||||
|
||||
### Data & Analytics
|
||||
- [ ] Tracking events implemented and verified
|
||||
- [ ] Launch metrics dashboard live
|
||||
- [ ] Baseline metrics captured pre-launch
|
||||
|
||||
## Process
|
||||
1. Review provided launch brief and checklist responses
|
||||
2. Flag any incomplete items as blockers (must fix) or risks (monitor)
|
||||
3. Assess overall readiness and produce go/no-go recommendation with rationale
|
||||
4. If no-go, specify exactly what must be completed and by when
|
||||
|
||||
## Output Format
|
||||
|
||||
### Launch Readiness Assessment: [Feature/Product Name]
|
||||
**Launch Date:** [date]
|
||||
**Overall Status:** ✅ Go / ⚠️ Conditional Go / 🛑 No-Go
|
||||
|
||||
**Blockers (must resolve before launch):**
|
||||
- [item + owner + resolution required by]
|
||||
|
||||
**Risks (monitor closely):**
|
||||
- [item + mitigation plan]
|
||||
|
||||
**Ready Areas:**
|
||||
- [function]: ✅ Ready
|
||||
|
||||
**Recommendation:**
|
||||
[Clear go/no-go with rationale — 3-5 sentences]
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
name: multi-source-signal-synthesiser
|
||||
description: Synthesises user signals from multiple research sources into a
|
||||
unified insight brief, reconciling conflicting feedback. Use when user has data
|
||||
from multiple sources, needs to "make sense of all this user data", "what are
|
||||
users really telling us", "synthesise our research", or has conflicting feedback
|
||||
from different channels.
|
||||
metadata:
|
||||
author: Mohit Aggarwal
|
||||
version: 1.0.0
|
||||
category: discovery
|
||||
tags: [user-research, synthesis, discovery, insights]
|
||||
documentation: https://github.com/mohitagw15856/pm-claude-skills
|
||||
---
|
||||
# Multi-Source Signal Synthesiser Skill
|
||||
|
||||
## Purpose
|
||||
Reconcile user signals from multiple sources — interviews, support tickets, NPS,
|
||||
app reviews, sales calls — into a unified, weighted insight brief that surfaces
|
||||
the underlying need rather than the surface-level request.
|
||||
|
||||
## Source Weighting (default — adapt to your context)
|
||||
- Direct research (interviews, usability tests): weight 5
|
||||
- Support tickets (unprompted pain signals): weight 4
|
||||
- NPS verbatims: weight 3
|
||||
- App store reviews: weight 2
|
||||
- Sales call summaries (filtered through sales lens): weight 2
|
||||
- Anecdote or single report: weight 1
|
||||
|
||||
## Process
|
||||
1. Accept inputs from any combination of the source types above
|
||||
2. Tag each signal by source and apply weight
|
||||
3. Look for CONVERGENCE: same underlying need appearing across 3+ sources
|
||||
4. Look for DIVERGENCE: contradictory signals suggesting user segmentation
|
||||
5. Distinguish surface request from underlying need
|
||||
(e.g. "faster export" may mean "I don't trust the data will be there when
|
||||
I need it")
|
||||
6. Produce ranked insights by weighted frequency
|
||||
|
||||
## Output Format
|
||||
|
||||
### User Signal Synthesis — [Date / Period]
|
||||
**Sources included:** [list]
|
||||
**Total signals processed:** [n]
|
||||
|
||||
#### Insight 1: [Underlying need, not feature request]
|
||||
- **Confidence:** High / Medium / Low (based on source diversity and weight)
|
||||
- **Evidence:** [Signals from each source supporting this]
|
||||
- **Conflicting signals:** [Any contradicting evidence and how to interpret it]
|
||||
- **Product implication:** [Specific, not generic]
|
||||
|
||||
[Repeat for top 3-5 insights]
|
||||
|
||||
#### Divergent Signals (Possible Segmentation)
|
||||
[Where user groups appear to have genuinely different needs]
|
||||
|
||||
#### What the Data Does NOT Tell Us
|
||||
[Gaps that require further research before acting]
|
||||
|
||||
## OpenClaw Configuration
|
||||
Connect to: Notion (research docs), support inbox, NPS tool, app review feed.
|
||||
Schedule: weekly synthesis run, diff output showing new signals only.
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
name: product-health-analysis
|
||||
description: Interpret product metrics against goals and surface actionable signals
|
||||
tool_integration: Google Analytics, Mixpanel
|
||||
---
|
||||
# Product Health Dashboard Skill
|
||||
|
||||
## Purpose
|
||||
Transform raw metrics data into a clear health narrative — what's working, what's not, and what needs immediate attention.
|
||||
|
||||
## Metrics Framework
|
||||
Analyse across four layers:
|
||||
1. **Acquisition** — new users, source quality, CAC trends
|
||||
2. **Activation** — time to first value, onboarding completion rates
|
||||
3. **Engagement** — DAU/MAU, feature adoption, session depth
|
||||
4. **Retention** — D1/D7/D30 retention, churn rate, resurrection rate
|
||||
|
||||
## Process
|
||||
1. For each metric, compare: current period vs. previous period, current vs. target
|
||||
2. Flag anything more than 10% off target as requiring investigation
|
||||
3. Look for correlations — does a drop in activation explain a retention dip 2 weeks later?
|
||||
4. Write a plain-English health summary (no jargon) suitable for sharing with non-data stakeholders
|
||||
5. Recommend top 3 areas for immediate investigation with suggested diagnostic steps
|
||||
|
||||
## Output Format
|
||||
|
||||
### Product Health Report — [Period]
|
||||
**Overall Health:** 🟢 On Track / 🟡 Watch / 🔴 Action Required
|
||||
|
||||
| Metric | Current | Target | vs. Last Period | Status |
|
||||
|--------|---------|--------|-----------------|--------|
|
||||
| [metric] | [value] | [target] | [+/-%] | [🟢/🟡/🔴] |
|
||||
|
||||
**Key Observations:**
|
||||
[3-5 bullet observations written in plain English]
|
||||
|
||||
**Areas Requiring Investigation:**
|
||||
1. [Metric + hypothesis + suggested diagnostic]
|
||||
2. [Metric + hypothesis + suggested diagnostic]
|
||||
3. [Metric + hypothesis + suggested diagnostic]
|
||||
|
||||
**Recommended Actions:**
|
||||
[Specific next steps with owners and timelines]
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
name: retro-analysis
|
||||
description: Analyse sprint delivery data and produce a structured retrospective brief
|
||||
tool_integration: Jira, Miro
|
||||
---
|
||||
# Retrospective Analysis Skill
|
||||
|
||||
## Purpose
|
||||
Generate a data-grounded retrospective brief that separates facts from feelings, so the team spends retro time on solutions rather than debating what happened.
|
||||
|
||||
## Required Inputs
|
||||
- Sprint tickets: planned vs. completed
|
||||
- Carry-over tickets and reasons
|
||||
- Tickets reopened after closing
|
||||
- Any incidents or unplanned work
|
||||
- Sprint velocity vs. historical average
|
||||
|
||||
## Process
|
||||
1. Calculate: completion rate, carry-over rate, unplanned work percentage
|
||||
2. Identify patterns: which ticket types were most likely to carry over? Which caused blockers?
|
||||
3. Note any process or communication breakdowns visible in the data
|
||||
4. Prepare 3 "Start / Stop / Continue" prompts based on the data — not generic, specific to this sprint
|
||||
5. Suggest 1 concrete experiment for the next sprint based on the biggest friction point
|
||||
|
||||
## Output Format
|
||||
|
||||
### Sprint [Number] Retrospective Brief
|
||||
|
||||
**By the Numbers:**
|
||||
- Planned: [n] tickets | Completed: [n] | Carry-over: [n] | Completion rate: [%]
|
||||
- Unplanned work: [n] tickets ([%] of capacity)
|
||||
- Velocity: [points] vs. [average] average
|
||||
|
||||
**What the Data Suggests:**
|
||||
[2-3 observations grounded in the numbers above]
|
||||
|
||||
**Discussion Prompts:**
|
||||
- Start: [specific prompt]
|
||||
- Stop: [specific prompt]
|
||||
- Continue: [specific prompt]
|
||||
|
||||
**Suggested Experiment for Next Sprint:**
|
||||
[One concrete, testable process change]
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
name: rice-impact-matrix
|
||||
description: Score features using RICE and plot against strategic alignment for nuanced prioritisation
|
||||
tool_integration: Miro, Jira
|
||||
---
|
||||
# RICE + Strategic Alignment Skill
|
||||
|
||||
## Purpose
|
||||
Produce a prioritisation output that balances quantitative RICE scoring with qualitative strategic fit — because the highest RICE score isn't always the right next bet.
|
||||
|
||||
## Two-Stage Process
|
||||
|
||||
### Stage 1: RICE Scoring
|
||||
- Reach: Users affected per quarter
|
||||
- Impact: 3/2/1/0.5/0.25 scale
|
||||
- Confidence: 100% / 80% / 50%
|
||||
- Effort: Person-months
|
||||
- RICE = (R × I × C) / E
|
||||
|
||||
### Stage 2: Strategic Alignment Score
|
||||
Rate each initiative against your current strategic priorities (provide these as input):
|
||||
- Directly supports top OKR: +3
|
||||
- Supports secondary OKR: +2
|
||||
- Neutral: +1
|
||||
- Contradicts strategic direction: -1
|
||||
|
||||
### Final Priority Score
|
||||
Combined Score = RICE Score + (Strategic Alignment × 10)
|
||||
|
||||
## Output Format
|
||||
|
||||
### Priority Matrix — [Quarter]
|
||||
| Initiative | RICE Score | Strategic Alignment | Combined Score | Quadrant | Recommendation |
|
||||
|------------|------------|--------------------|--------------------|----------|----------------|
|
||||
| [name] | [score] | [score] | [combined] | [Now/Next/Later/Drop] | [action] |
|
||||
|
||||
#### Quadrant Definitions
|
||||
- **Now:** High RICE + High Strategic Alignment → Build this quarter
|
||||
- **Next:** High RICE + Lower Alignment → Queue for next quarter
|
||||
- **Later:** Lower RICE + High Alignment → Revisit when capacity allows
|
||||
- **Drop:** Low RICE + Low Alignment → Remove from backlog
|
||||
|
||||
#### Recommendations
|
||||
[Top 5 initiatives with rationale for sequencing]
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
name: rice-prioritisation
|
||||
description: Score and rank product initiatives using the RICE framework
|
||||
tool_integration: Jira
|
||||
---
|
||||
# RICE Prioritisation Skill
|
||||
|
||||
## Purpose
|
||||
Apply consistent, criteria-based RICE scoring to a list of features or initiatives to produce an objective prioritisation ranking.
|
||||
|
||||
## RICE Definitions (adapt to your context)
|
||||
- **Reach:** Number of users affected per quarter (use actual DAU/MAU data where available)
|
||||
- **Impact:** Effect on your primary metric — use scale: 3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal
|
||||
- **Confidence:** How certain are we about R and I estimates? 100%=high, 80%=medium, 50%=low
|
||||
- **Effort:** Person-months required across all functions
|
||||
|
||||
## RICE Formula
|
||||
RICE Score = (Reach × Impact × Confidence) / Effort
|
||||
|
||||
## Process
|
||||
1. For each initiative provided, gather or estimate R, I, C, E values
|
||||
2. Flag where estimates are weak and note what data would improve them
|
||||
3. Calculate RICE score for each
|
||||
4. Rank highest to lowest
|
||||
5. Flag any "quick wins" (high RICE score, low effort) and "moonshots" (high impact, high effort)
|
||||
6. Note dependencies between items that affect sequencing
|
||||
|
||||
## Output Format
|
||||
|
||||
### RICE Prioritisation: [Backlog/Quarter]
|
||||
| Initiative | Reach | Impact | Confidence | Effort | RICE Score | Notes |
|
||||
|------------|-------|--------|------------|--------|------------|-------|
|
||||
| [name] | [n] | [score] | [%] | [months] | [score] | [flags] |
|
||||
|
||||
#### Recommended Sequence
|
||||
[Top 5 initiatives with rationale]
|
||||
|
||||
#### Data Gaps to Address
|
||||
[What information would most improve scoring accuracy]
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
name: roadmap-narrative
|
||||
description: Transform a prioritised initiative list into a compelling strategic roadmap narrative
|
||||
tool_integration: Notion, Miro
|
||||
---
|
||||
# Roadmap Narrative Skill
|
||||
|
||||
## Purpose
|
||||
Convert a ranked list of product initiatives into a clear, strategic narrative that connects individual items to company goals and communicates a coherent product direction.
|
||||
|
||||
## Process
|
||||
1. Review the prioritised initiative list and company OKRs provided
|
||||
2. Identify 2-3 strategic themes that group the initiatives naturally
|
||||
3. For each theme, articulate: the problem it addresses, the customer it serves, the metric it moves
|
||||
4. Write a quarter-level narrative that shows progression — how does H1 set up H2?
|
||||
5. Draft an executive summary (3-4 sentences max) that non-technical stakeholders can repeat
|
||||
|
||||
## Output Format
|
||||
|
||||
### Product Roadmap: [Quarter/Half/Year]
|
||||
**Strategic Context:** [1 paragraph: market moment, key challenge, our response]
|
||||
|
||||
#### Theme 1: [Theme Name]
|
||||
- Strategic rationale
|
||||
- Initiatives included
|
||||
- Primary metric impacted
|
||||
- Dependencies
|
||||
|
||||
[Repeat for each theme]
|
||||
|
||||
**Executive Summary (shareable):**
|
||||
[3-4 sentences that could be shared in an all-hands or board update]
|
||||
|
||||
## Tone Guidelines
|
||||
- Avoid jargon — write for a CFO, not an engineer
|
||||
- Lead with customer outcomes, not features
|
||||
- Be honest about what's NOT on the roadmap and why
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
name: sprint-brief
|
||||
description: Generate a structured sprint brief from Jira sprint data and goals
|
||||
tool_integration: Jira, Slack
|
||||
---
|
||||
# Sprint Brief Skill
|
||||
|
||||
## Purpose
|
||||
Produce a clear, scannable sprint brief that every team member — engineer, designer, PM — can read in under three minutes and understand exactly what we're doing and why.
|
||||
|
||||
## Required Inputs
|
||||
- Sprint name and number
|
||||
- Sprint goal (1-2 sentences)
|
||||
- Ticket list with owners
|
||||
- Known dependencies or blockers
|
||||
- Carry-over items from previous sprint
|
||||
|
||||
## Process
|
||||
1. Read sprint goal and check it's specific and measurable — flag if it's too vague
|
||||
2. Group tickets by theme or feature area
|
||||
3. Identify the critical path — which tickets must complete for the sprint goal to be met?
|
||||
4. Flag risks: tickets with unclear acceptance criteria, missing designs, unresolved dependencies
|
||||
5. Note carry-over items and whether they affect this sprint's goal
|
||||
|
||||
## Output Format
|
||||
|
||||
### Sprint [Number] Brief — [Dates]
|
||||
**Sprint Goal:** [1-2 sentences]
|
||||
**Why This Sprint Matters:** [Connect to quarterly OKR in 2-3 sentences]
|
||||
|
||||
**What We're Building:**
|
||||
- [Theme 1]: [tickets and owners]
|
||||
- [Theme 2]: [tickets and owners]
|
||||
|
||||
**Critical Path:** [The 2-3 tickets everything else depends on]
|
||||
|
||||
**Risks to Flag:**
|
||||
- [Risk 1 + mitigation]
|
||||
- [Risk 2 + mitigation]
|
||||
|
||||
**Carry-over from Last Sprint:** [List + impact on current goal]
|
||||
|
||||
**Definition of Done:** [Specific, agreed criteria for sprint success]
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
name: stakeholder-influence-mapper
|
||||
description: Maps stakeholders for a product decision and produces a tailored
|
||||
influence strategy with draft talking points. Use when user needs to "get
|
||||
alignment", "build consensus", "get buy-in from engineering or finance or legal",
|
||||
"present to stakeholders", or "navigate organisational resistance".
|
||||
metadata:
|
||||
author: Mohit Aggarwal
|
||||
version: 1.0.0
|
||||
category: stakeholder-communication
|
||||
tags: [stakeholders, influence, communication, alignment]
|
||||
documentation: https://github.com/mohitagw15856/pm-claude-skills
|
||||
---
|
||||
# Stakeholder Influence Mapper Skill
|
||||
|
||||
## Purpose
|
||||
Turn a product initiative into a structured influence plan — who needs to be
|
||||
aligned, in what order, and exactly what to say to each person in their language.
|
||||
|
||||
## Required Inputs
|
||||
- Initiative description (what you want to do and why)
|
||||
- List of key stakeholders involved (name, role, relationship to initiative)
|
||||
- Timeline pressure (when do you need a decision?)
|
||||
- Any known objections or political context
|
||||
|
||||
## Process
|
||||
1. Build stakeholder map with: role, primary concern, decision authority
|
||||
(blocker / influencer / informed), current stance (supportive / neutral /
|
||||
resistant / unknown)
|
||||
2. Identify the critical path of conversations — who must be won before others
|
||||
3. For each stakeholder, lead with their concern, not your ask
|
||||
4. Prepare one likely objection per stakeholder and a prepared response
|
||||
5. Flag any stakeholders who should NOT be approached until others are aligned
|
||||
|
||||
## Output Format
|
||||
|
||||
### Stakeholder Map: [Initiative Name]
|
||||
|
||||
| Stakeholder | Role | Primary Concern | Authority | Current Stance |
|
||||
|-------------|------|-----------------|-----------|----------------|
|
||||
| [name] | [role] | [concern] | [type] | [stance] |
|
||||
|
||||
### Recommended Conversation Sequence
|
||||
1. **[Name first]** — because [reason they unlock others]
|
||||
2. **[Name second]** — once [first] is aligned
|
||||
[continue...]
|
||||
|
||||
### Talking Points by Stakeholder
|
||||
|
||||
#### [Stakeholder Name]
|
||||
**Lead with:** [Their concern, not your feature]
|
||||
**Your ask:** [One specific thing you need from them]
|
||||
**Likely objection:** [What they'll push back on]
|
||||
**Prepared response:** [How to address it without being defensive]
|
||||
**What success looks like:** [What alignment from them looks like]
|
||||
|
||||
## Notes
|
||||
- Never send the same message to all stakeholders — calibrate every time
|
||||
- Engineering leads want technical feasibility acknowledged first
|
||||
- Finance stakeholders want ROI framing before anything else
|
||||
- Legal/compliance stakeholders want risk mitigation addressed upfront
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
name: strategic-narrative-generator
|
||||
description: Generates the strategic story connecting your roadmap to company
|
||||
goals in a form non-technical stakeholders can repeat. Use when user needs to
|
||||
"explain the roadmap", "present strategy to leadership or the board", "write the
|
||||
why behind the roadmap", "create a narrative for all-hands", or "make the
|
||||
roadmap tell a story".
|
||||
metadata:
|
||||
author: Mohit Aggarwal
|
||||
version: 1.0.0
|
||||
category: roadmapping
|
||||
tags: [strategy, roadmap, executive-communication, narrative]
|
||||
documentation: https://github.com/mohitagw15856/pm-claude-skills
|
||||
---
|
||||
# Strategic Narrative Generator Skill
|
||||
|
||||
## Purpose
|
||||
Turn a prioritised initiative list into a strategic narrative — the story that
|
||||
explains not just what you're building but why, why now, and why this sequence.
|
||||
The kind of narrative a board member can repeat back correctly after one hearing.
|
||||
|
||||
## Required Inputs
|
||||
- Prioritised initiative list (with rough timelines)
|
||||
- Current OKRs or strategic priorities (1-3)
|
||||
- Competitive or market context (optional but improves output significantly)
|
||||
|
||||
## Process
|
||||
1. Read the initiative list and identify 2-3 natural strategic themes
|
||||
2. For each theme: articulate the problem it addresses, the customer it serves,
|
||||
and the metric it moves
|
||||
3. Build the progression narrative: how does Q1 set up Q2? How does H1 set up H2?
|
||||
4. Write executive summary in under 100 words (the version someone can repeat)
|
||||
5. Anticipate the 3 hardest questions a sceptical board member would ask —
|
||||
and draft answers
|
||||
6. Identify what's NOT on the roadmap and why (this builds credibility)
|
||||
|
||||
## Output Format
|
||||
|
||||
### Product Strategy Narrative: [Period]
|
||||
|
||||
**The One-Paragraph Context:**
|
||||
[Market moment + key challenge + our response — for the CFO, not the engineer]
|
||||
|
||||
**Strategic Theme 1: [Name]**
|
||||
- The problem: [customer pain in plain language]
|
||||
- Our response: [initiatives in this theme]
|
||||
- The metric it moves: [specific and measurable]
|
||||
- Why now: [timing rationale]
|
||||
|
||||
**Strategic Theme 2: [Name]**
|
||||
[Same structure]
|
||||
|
||||
**The Progression Story:**
|
||||
[How each quarter sets up the next — this is the narrative arc]
|
||||
|
||||
**Executive Summary (under 100 words — shareable):**
|
||||
[Version someone can quote at a board meeting]
|
||||
|
||||
**Questions to Prepare For:**
|
||||
1. [Hard question] → [Prepared answer]
|
||||
2. [Hard question] → [Prepared answer]
|
||||
3. [Hard question] → [Prepared answer]
|
||||
|
||||
**What's Not on the Roadmap (and Why):**
|
||||
[2-3 items — shows strategic discipline, not just prioritisation]
|
||||
|
||||
## Tone Rules
|
||||
- Write for a CFO, not an engineer
|
||||
- Lead with outcomes, not features
|
||||
- Every sentence should answer "so what?"
|
||||
- Avoid jargon — if you can't say it plainly, the strategy isn't clear enough yet
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: user-interview-synthesis
|
||||
description: Synthesise user interview transcripts into structured research findings
|
||||
tool_integration: Notion
|
||||
---
|
||||
# User Interview Synthesis Skill
|
||||
|
||||
## Purpose
|
||||
Transform raw interview transcripts into a structured synthesis document that surfaces themes, pain points, and actionable insights.
|
||||
|
||||
## Process
|
||||
1. Read all provided transcripts fully before drawing conclusions
|
||||
2. Identify recurring themes (minimum 3 mentions to qualify as a theme)
|
||||
3. Categorize findings into: Pain Points, Workflow Insights, Feature Requests, Delight Moments
|
||||
4. Select 2-3 verbatim quotes per theme that best represent the pattern
|
||||
5. Draft "So What" implications for each theme — what does this mean for the product?
|
||||
|
||||
## Output Format
|
||||
|
||||
### Research Synthesis: [Study Name]
|
||||
**Participants:** [n]
|
||||
**Date Range:** [dates]
|
||||
**Research Questions:** [list]
|
||||
|
||||
#### Theme 1: [Theme Name]
|
||||
- Summary (2-3 sentences)
|
||||
- Supporting quotes
|
||||
- Implication for product
|
||||
|
||||
[Repeat for each theme]
|
||||
|
||||
#### Recommended Next Steps
|
||||
[Specific, actionable recommendations based on findings]
|
||||
|
||||
## Quality Checks
|
||||
- Every theme must be supported by quotes from at least 3 participants
|
||||
- Implications must connect to product decisions, not just observations
|
||||
- Avoid researcher bias — let the data lead
|
||||
Reference in New Issue
Block a user