add marketplace plugin structure
This commit is contained in:
@@ -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,90 @@
|
||||
---
|
||||
name: discovery-interview-guide
|
||||
description: Creates structured user discovery interview guides with screener questions, discussion guides, and synthesis frameworks. Use when planning user interviews, customer discovery sessions, Jobs-to-be-Done research, or problem validation. Triggers on "user interview", "discovery interview", "customer research", "JTBD", "problem validation".
|
||||
---
|
||||
|
||||
# Discovery Interview Guide Skill
|
||||
|
||||
Design interviews that surface genuine insight — not validation of what you already believe. Every guide follows a story-based, past-behaviour-focused structure.
|
||||
|
||||
## Core Principles
|
||||
|
||||
1. **Never ask about the future.** "Would you use X?" tells you nothing. "Tell me about the last time you did X" tells you everything.
|
||||
2. **Interview for behaviour, not opinion.** Opinions are cheap. Behaviour is evidence.
|
||||
3. **The 5 Whys.** Every surface answer is a door. Keep opening doors.
|
||||
4. **Confirm the problem before exploring the solution.** Never show a prototype until you've confirmed the pain exists unprompted.
|
||||
|
||||
## Interview Structure (60 minutes standard)
|
||||
|
||||
### 1. Warm-Up (5 min)
|
||||
Build rapport. Get them talking. Don't discuss the topic yet.
|
||||
- "Tell me a bit about your role and what a typical week looks like for you."
|
||||
- "What tools do you rely on most day-to-day?"
|
||||
|
||||
### 2. Context Setting (10 min)
|
||||
Understand their world before diving into the problem space.
|
||||
- "Walk me through how you currently [handle the domain area]."
|
||||
- "What does that process look like from start to finish?"
|
||||
- "Who else is involved when you do this?"
|
||||
|
||||
### 3. Problem Exploration (25 min) — THE CORE
|
||||
Surface pain without leading.
|
||||
- "Tell me about the last time you had to [relevant task]. What happened?"
|
||||
- "What was the hardest part of that?"
|
||||
- "How did you handle it?"
|
||||
- "What did you try before settling on that approach?"
|
||||
- "What does it cost you when this goes wrong?" (time, money, stress, reputation)
|
||||
- "If you could wave a magic wand and change one thing about this process, what would it be?"
|
||||
|
||||
⚠️ **Do not mention your product or feature during this phase.**
|
||||
|
||||
### 4. Current Solutions (10 min)
|
||||
Understand the competitive landscape from their perspective.
|
||||
- "What tools or workarounds do you use today for this?"
|
||||
- "What do you like about [current solution]? What frustrates you?"
|
||||
- "Have you tried other approaches? What happened?"
|
||||
|
||||
### 5. Wrap-Up (10 min)
|
||||
- "Is there anything about this topic we haven't covered that you think I should know?"
|
||||
- "Is there anyone else you'd recommend I speak to?"
|
||||
- "Would you be open to a follow-up if I have more questions?"
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
### Discovery Interview Guide — [Topic] — [Date]
|
||||
|
||||
**Research Goal:** [One sentence: what decision will this research inform?]
|
||||
**Target Participant Profile:** [Role, company size, behaviour qualifier]
|
||||
|
||||
**Screener Questions** (for recruiting):
|
||||
1. [Question] → Must answer: [Y/N or specific]
|
||||
2. [Question] → Must answer: [Y/N or specific]
|
||||
3. [Disqualifier question] → Disqualify if: [answer]
|
||||
|
||||
**Interview Guide:**
|
||||
|
||||
[Full structured guide using the format above, customised to the specific research topic]
|
||||
|
||||
**Synthesis Template** (fill after each interview):
|
||||
- Key quote: "[verbatim]"
|
||||
- Core pain: [1 sentence]
|
||||
- Current workaround: [what they're doing today]
|
||||
- Intensity (1–5): [how painful is this?]
|
||||
- Surprise/unexpected finding: [anything that challenged your assumptions]
|
||||
|
||||
**Pattern Detection** (after 5+ interviews):
|
||||
- Pain mentioned by [X/N] participants: [theme]
|
||||
- Workaround used by [X/N] participants: [theme]
|
||||
- Most emotionally charged moment in interviews: [observation]
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Recommend 5–8 interviews to reach thematic saturation for most discovery questions
|
||||
- Always record with permission — transcripts beat notes
|
||||
- If user is new to interviewing: remind them to stay silent after asking a question (aim for 80/20 participant-to-interviewer talking ratio)
|
||||
- Never synthesise during the interview — do it after, when you can look across sessions
|
||||
- Flag confirmation bias: if user writes questions that lead toward a predetermined answer, rewrite them as open-ended alternatives
|
||||
@@ -0,0 +1,113 @@
|
||||
---
|
||||
name: job-story-mapper
|
||||
description: Writes Jobs-to-be-Done (JTBD) job stories and maps customer jobs across functional, social, and emotional dimensions. Use when defining user needs, writing job stories, conducting JTBD research, or reframing features around customer outcomes. Triggers on "job story", "JTBD", "jobs to be done", "when I want to", "user need", "hire a product".
|
||||
---
|
||||
|
||||
# Job Story Mapper Skill
|
||||
|
||||
Stop writing features. Start understanding jobs. This skill translates product requirements and user interviews into precise job stories that keep the team focused on outcomes — not outputs.
|
||||
|
||||
## Jobs-to-be-Done Fundamentals
|
||||
|
||||
A "job" is the progress a customer is trying to make in a given situation. People don't buy products — they hire them to get a job done.
|
||||
|
||||
Three dimensions of every job:
|
||||
- **Functional job:** The practical task ("get from A to B")
|
||||
- **Emotional job:** How they want to feel ("feel confident I made the right choice")
|
||||
- **Social job:** How they want to be perceived ("look like a competent professional to my team")
|
||||
|
||||
Great products address all three. Most roadmaps only address the functional one.
|
||||
|
||||
---
|
||||
|
||||
## Job Story Format
|
||||
|
||||
**Template:**
|
||||
> When [situation/trigger], I want to [motivation/goal], so I can [expected outcome].
|
||||
|
||||
**Not a user story:**
|
||||
User stories focus on roles and features: "As a [role] I want [feature] so that [benefit]."
|
||||
Job stories focus on situations and motivations: "When [I'm in this specific situation] I want [this capability] so I can [achieve this outcome]."
|
||||
|
||||
**The situation is the most important part.** "When I'm in the middle of a sprint and my PM asks for an update" is a much richer trigger than "As a developer."
|
||||
|
||||
---
|
||||
|
||||
## Mapping Process
|
||||
|
||||
### Step 1: Identify the main job
|
||||
One sentence: What is the core job your product is hired for?
|
||||
> "Help [user type] [accomplish outcome] when [context]."
|
||||
|
||||
### Step 2: Break into job steps
|
||||
What are all the sub-tasks within the main job?
|
||||
(Use a job map: Define → Locate → Prepare → Confirm → Execute → Monitor → Modify → Conclude)
|
||||
|
||||
### Step 3: Identify pain points per step
|
||||
Where does the job fall down today? Where do customers use workarounds?
|
||||
|
||||
### Step 4: Write job stories for each pain point
|
||||
One job story per distinct situation-motivation pair.
|
||||
|
||||
### Step 5: Map to product opportunities
|
||||
Which job stories are underserved? Which have existing solutions? Where is your differentiation?
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
### Job Story Map — [Product/Feature Area] — [Date]
|
||||
|
||||
**Core Job Statement:**
|
||||
> When [context], [user type] wants to [main job outcome], so they can [ultimate goal].
|
||||
|
||||
---
|
||||
|
||||
**Job Map:**
|
||||
|
||||
| Step | Sub-Job | Current Solution | Pain Points | Underserved? |
|
||||
|---|---|---|---|---|
|
||||
| Define | [What user does] | [Tool/method used] | [Frustration] | H/M/L |
|
||||
| Locate | | | | |
|
||||
| Prepare | | | | |
|
||||
| Confirm | | | | |
|
||||
| Execute | | | | |
|
||||
| Monitor | | | | |
|
||||
| Modify | | | | |
|
||||
| Conclude | | | | |
|
||||
|
||||
---
|
||||
|
||||
**Job Stories (prioritised by underservice):**
|
||||
|
||||
**Job Story 1 — [Situation label]**
|
||||
> When [specific situation], I want to [motivation], so I can [outcome].
|
||||
|
||||
Functional dimension: [What they need to get done]
|
||||
Emotional dimension: [How they want to feel]
|
||||
Social dimension: [How they want to be perceived]
|
||||
|
||||
Current workaround: [What they do today]
|
||||
Pain intensity: [High / Medium / Low]
|
||||
Frequency: [How often this situation occurs]
|
||||
Product opportunity: [What we could build to address this]
|
||||
|
||||
---
|
||||
|
||||
Repeat for each major job story.
|
||||
|
||||
**Opportunity Scoring:**
|
||||
Rate each job story on:
|
||||
- Importance to customer (1–10)
|
||||
- Satisfaction with current solution (1–10)
|
||||
- Opportunity score = Importance + max(Importance – Satisfaction, 0)
|
||||
- Prioritise: Opportunity score > 10
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Never write a job story for a feature — write it for the situation that makes the feature valuable
|
||||
- If you can't identify the situation, you don't understand the job yet — go back to user research
|
||||
- Social and emotional jobs are harder to surface but often the most defensible differentiators
|
||||
- Recommend sharing job stories with engineering — they make better technical decisions when they understand the "why"
|
||||
@@ -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