prd-development by deanpeters/product-manager-skills
npx skills add https://github.com/deanpeters/product-manager-skills --skill prd-development指导产品经理通过结构化方式创建 PRD(产品需求文档),将问题界定、用户研究综合、解决方案定义和成功标准整合成一份连贯的文档。使用此方法,可以从零散的笔记和 Slack 讨论转向清晰、全面的 PRD,从而协调利益相关者、提供工程背景,并作为唯一事实来源——避免模糊性、范围蔓延和“按我脑海中的想法构建”的陷阱。
这不是一份瀑布式规格书——而是一份活的文档,用于捕捉战略背景、客户问题、拟议解决方案和成功标准,并随着交付过程中的学习而不断演进。
PRD(产品需求文档)是一份结构化文档,用于回答:
# [功能/产品名称] PRD
## 1. 执行摘要
- 一段式概述(问题 + 解决方案 + 影响)
## 2. 问题陈述
- 谁有这个问题?
- 问题是什么?
- 为什么这个问题令人痛苦?
- 证据(客户引述、数据、研究)
## 3. 目标用户与角色画像
- 主要角色画像
- 次要角色画像
- 待完成工作
## 4. 战略背景
- 业务目标(OKR)
- 市场机会(TAM/SAM/SOM)
- 竞争格局
- 为什么是现在?
## 5. 解决方案概述
- 高层次描述
- 用户流程或线框图
- 关键功能
## 6. 成功指标
- 主要指标(我们优化的目标)
- 次要指标
- 目标(当前 → 目标)
## 7. 用户故事与需求
- 史诗假设
- 带验收标准的用户故事
- 边界情况、约束条件
## 8. 范围外内容
- 我们不构建什么(以及原因)
## 9. 依赖项与风险
- 技术依赖项
- 外部依赖项(集成、合作伙伴关系)
- 风险与缓解措施
## 10. 待解决问题
- 未解决的决策
- 需要探索的领域
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
当将此工作流作为引导式对话运行时,请使用 workshop-facilitation 作为交互协议。
它定义了:
其他(请指定))此文件定义了工作流序列和特定领域的输出。如果存在冲突,请遵循此文件的工作流逻辑。
使用 template.md 获取完整的填充结构。
此工作流在 2-4 天 内编排 8 个阶段,使用多个组件和交互式技能。
目标: 为快速浏览者撰写一段式概述。
1. 起草执行摘要
格式: “我们为 [角色画像] 构建 [解决方案] 以解决 [问题],这将带来 [影响]。”
示例:
“我们为非技术型小企业主构建一个引导式入门清单,以解决由于缺乏指导而导致用户在最初 24 小时内流失 60% 的问题,这将使激活率从 40% 提高到 60%,并将流失率降低 10%。”
提示: 首先撰写此部分(迫使思路清晰),但最后再完善(在其他部分完成后)。
目标: 用证据界定客户问题。
1. 撰写问题陈述
skills/problem-statement/SKILL.md(组件)skills/discovery-process/SKILL.md 或 skills/problem-framing-canvas/SKILL.md 的探索洞察示例问题陈述:
## 2. 问题陈述
### 谁有这个问题?
注册我们 SaaS 产品的非技术型小企业主(个体创业者,1-10 名员工)。
### 问题是什么?
60% 的用户在最初 24 小时内放弃入门流程,因为他们不知道首先该做什么。他们看到一个没有指导的空仪表板,被众多选项淹没,然后离开。
### 为什么这个问题令人痛苦?
- **用户影响:** 浪费时间(花 30-60 分钟试图弄清楚产品),从未达到“顿悟时刻”,在体验到价值之前就流失了
- **业务影响:** 60% 的激活率 → 高流失率、低生命周期价值、口碑差
### 证据
- **访谈:** 8/10 的流失用户表示“我不知道首先该做什么”(探索访谈,2026 年 2 月)
- **分析:** 60% 的注册用户在 24 小时内完成 0 个操作(Mixpanel,2026 年 1 月)
- **支持工单:** “如何开始?”是排名第一的支持问题(350 张工单/月)
- **客户引述:** “我登录后看到一个空仪表板,心想‘现在怎么办?’我放弃了,又回去用我的电子表格了。”
2. 添加上下文支持(可选)
skills/customer-journey-mapping-workshop/SKILL.md 输出skills/jobs-to-be-done/SKILL.md 输出目标: 定义你为谁构建。
1. 记录角色画像
skills/proto-persona/SKILL.md(组件)输出示例:
## 3. 目标用户与角色画像
### 主要角色画像:个体创业者 Sam
- **职责:** 自由职业顾问,个体创业者
- **公司规模:** 1 人(无 IT 支持)
- **技术熟练度:** 低(使用电子邮件、电子表格、基础 SaaS)
- **目标:** 无需技术专长即可快速从软件中获得价值
- **痛点:** 被复杂的 UI 淹没,没时间看教程,需要即时价值
- **当前行为:** 注册产品,尝试 1 天,如果无法立即见效就流失
### 次要角色画像:小企业主(5-10 名员工)
- **职责:** 所有者兼经营者,管理团队
- **需求:** 快速让团队成员上手
- **与主要角色的区别:** 更能容忍复杂性,愿意投入设置时间
目标: 解释这对业务的重要性以及为什么是现在。
1. 记录业务目标
“此计划支持我们第一季度的 OKR:将流失率从 15% 降低到 8%。改进入门激活直接影响留存率。”
2. 估算市场机会规模(可选)
skills/tam-sam-som-calculator/SKILL.md(交互式)输出“TAM:全球 5000 万家小企业。SAM:500 万家使用 SaaS 工具。SOM:我们目标细分市场中的 50 万家个体创业者。改进入门流程可能解锁 30% 的 SAM(150 万潜在客户)。”
3. 记录竞争格局(可选)
“竞争对手(竞争对手 A、B)有引导式入门流程。我们缺乏指导在退出调查中被引述为流失原因。”
4. 解释“为什么是现在?”
“第四季度流失率激增 15%。入门流程是第一大驱动因素(前 30 天流失率 60%)。解决此问题对于实现留存 OKR 至关重要。”
目标: 描述你要构建什么(高层次,非详细规格)。
1. 撰写解决方案描述
格式: 高层次概述,2-3 段
示例:
我们正在构建一个引导式入门清单,当新用户首次登录时,会逐步引导他们完成核心工作流。
工作原理:
关键功能:
2. 添加用户流程或线框图(可选)
3. 引用故事地图(可选)
skills/user-story-mapping-workshop/SKILL.md 输出目标: 定义如何衡量成功。
1. 定义主要指标
2. 定义次要指标
3. 定义护栏指标
示例:
## 6. 成功指标
### 主要指标
**激活率**(24 小时内完成第一个操作的用户百分比)
- **当前:** 40%
- **目标:** 60%
- **时间线:** 发布后 30 天测量
### 次要指标
- **首次操作时间:** 从 3 天减少到 1 天
- **入门清单完成率:** 80% 的用户完成所有 3 个步骤
- **支持工单:** 将“如何开始?”工单从 350 张/月减少到 175 张/月
### 护栏指标
- **注册转化率:** 保持在 10%(不要给注册流程增加摩擦)
目标: 将解决方案分解为带有验收标准的用户故事。
1. 撰写史诗假设
skills/epic-hypothesis/SKILL.md(组件)示例:
“我们相信,为非技术用户添加引导式入门清单,将使激活率从 40% 提高到 60%,因为用户目前因缺乏指导而流失。我们将在发布后 30 天通过激活率来衡量成功。”
2. 将史诗分解为用户故事
skills/epic-breakdown-advisor/SKILL.md(交互式 - 使用 Richard Lawrence 的 9 种模式)3. 撰写用户故事
skills/user-story/SKILL.md(组件)示例用户故事:
## 7. 用户故事与需求
### 史诗假设
我们相信,为非技术用户添加引导式入门清单,将使激活率从 40% 提高到 60%,因为用户目前因缺乏指导而流失。
### 用户故事
**故事 1:在首次登录时显示入门清单**
作为一名新用户,我希望在首次登录时看到一个引导式清单,以便我知道首先该做什么。
**验收标准:**
- [ ] 当用户首次登录时,出现带清单的模态框
- [ ] 清单显示 3 个步骤:“创建项目”、“邀请团队成员”、“完成任务”
- [ ] 模态框可关闭(关闭按钮)
- [ ] 如果关闭,清单不会再次出现(保存用户偏好)
**故事 2:跟踪清单进度**
作为一名新用户,我希望在完成清单步骤时看到我的进度,以便获得成就感。
**验收标准:**
- [ ] 当用户完成步骤 1 时,“创建项目”旁边出现勾选标记
- [ ] 进度条更新(1/3 → 2/3 → 3/3)
- [ ] 清单在会话间持续存在(如果用户登出再登录)
**故事 3:庆祝清单完成**
作为一名新用户,我希望在完成清单时获得积极反馈,以便对使用产品充满信心。
**验收标准:**
- [ ] 当用户完成所有 3 个步骤时,出现庆祝模态框
- [ ] 消息:“您已准备就绪!以下是下一步建议:[建议的后续操作]”
- [ ] 彩带动画(可选,锦上添花)
4. 记录约束条件与边界情况
目标: 定义你不构建什么以及你依赖什么。
1. 记录范围外内容
示例:
## 8. 范围外内容
**此版本不包含:**
- **高级入门个性化**(例如,每个角色画像不同的清单)——增加复杂性,先测试简单版本
- **嵌入清单的视频教程**——资源密集,先验证清单概念
- **游戏化(徽章、积分)**——锦上添花,专注于核心工作流引导
**未来考虑:**
- 移动端优化的入门流程(目前以桌面端为先)
2. 记录依赖项
示例:
## 9. 依赖项与风险
### 依赖项
- **设计:** 清单 UI 的线框图(预计完成时间:第 1 周)
- **工程:** 无技术依赖项(使用现有的模态框框架)
### 风险与缓解措施
- **风险:** 用户立即关闭清单,从未看到它
- **缓解措施:** 跟踪关闭率;如果 >50%,迭代消息或时机
- **风险:** 清单步骤过于通用,无法引起所有角色画像的共鸣
- **缓解措施:** 从主要角色画像(个体创业者 Sam)开始,稍后个性化
3. 记录待解决问题
示例:
## 10. 待解决问题
- 清单应该是强制性的还是可选的?(决策:可选,可关闭)
- 我们应该对清单与无清单进行 A/B 测试吗?(决策:是,向 50% 的新用户展示)
- 如果用户以乱序完成步骤会发生什么?(决策:允许任何顺序,动态更新清单)
第 1 天:
├─ 阶段 1:执行摘要(30 分钟)
├─ 阶段 2:问题陈述(60 分钟)
│ └─ 使用:skills/problem-statement/SKILL.md
├─ 阶段 3:目标用户与角色画像(30 分钟)
│ └─ 使用:skills/proto-persona/SKILL.md
└─ 阶段 4:战略背景(45 分钟)
└─ 使用:skills/tam-sam-som-calculator/SKILL.md(可选)
第 2 天:
├─ 阶段 5:解决方案概述(60 分钟)
│ └─ 使用:skills/user-story-mapping-workshop/SKILL.md(可选)
├─ 阶段 6:成功指标(30 分钟)
└─ 阶段 7:用户故事与需求(90-120 分钟)
├─ 使用:skills/epic-hypothesis/SKILL.md
├─ 使用:skills/epic-breakdown-advisor/SKILL.md
└─ 使用:skills/user-story/SKILL.md
第 3 天:
├─ 阶段 8:范围外内容与依赖项(30 分钟)
└─ 审查与完善(60 分钟)
└─ 通读完整 PRD,润色,获取反馈
第 4 天(可选):
└─ 利益相关者审查与批准
└─ 向利益相关者展示 PRD,整合反馈
总时间投入:
查看 examples/sample.md 获取完整的 PRD 示例。
迷你示例摘录:
## 2. 问题陈述
- 60% 的试用用户在最初 24 小时内流失
## 6. 成功指标
- 激活率:40% → 60%
症状: 产品经理独自编写 PRD,向团队呈现完成的文档
后果: 没有认同感,团队不理解理由
解决方法: 与设计 + 工程协作完成阶段 7(用户故事);在最终确定前审查 PRD 草案
症状: “我们相信用户有这个问题”(没有数据,没有引述)
后果: 团队质疑问题是否真实存在
解决方法: 使用来自 skills/discovery-process/SKILL.md 的探索洞察;包含客户引述、分析数据、支持工单
症状: PRD 指定确切的 UI、像素尺寸、按钮颜色
后果: 剥夺了设计协作,变成瀑布式规格书
解决方法: 保持阶段 5 的高层次;让设计负责 UI 细节
症状: PRD 定义了问题 + 解决方案,但没有指标
后果: 无法验证功能是否成功
解决方法: 始终在阶段 6 定义主要指标(你优化的目标)
症状: 没有关于不构建什么的部分
后果: 范围蔓延,利益相关者期望未计划的功能
解决方法: 在阶段 8 明确记录范围外内容
阶段 2:
skills/problem-statement/SKILL.md(组件)skills/problem-framing-canvas/SKILL.md(交互式,用于背景)skills/customer-journey-mapping-workshop/SKILL.md(交互式,可选)阶段 3:
skills/proto-persona/SKILL.md(组件)skills/jobs-to-be-done/SKILL.md(组件,可选)阶段 4:
skills/tam-sam-som-calculator/SKILL.md(交互式,可选)阶段 5:
skills/user-story-mapping-workshop/SKILL.md(交互式,可选)阶段 7:
skills/epic-hypothesis/SKILL.md(组件)skills/epic-breakdown-advisor/SKILL.md(交互式)skills/user-story/SKILL.md(组件)技能类型: 工作流 建议文件名: prd-development.md 建议放置位置: /skills/workflows/ 依赖项: 跨 8 个阶段编排 8 个以上的组件和交互式技能
每周安装次数
478
代码库
GitHub 星标数
1.5K
首次出现
2026 年 2 月 12 日
安全审计
安装于
codex438
opencode434
github-copilot431
gemini-cli430
cursor428
kimi-cli426
Guide product managers through structured PRD (Product Requirements Document) creation by orchestrating problem framing, user research synthesis, solution definition, and success criteria into a cohesive document. Use this to move from scattered notes and Slack threads to a clear, comprehensive PRD that aligns stakeholders, provides engineering context, and serves as a source of truth—avoiding ambiguity, scope creep, and the "build what's in my head" trap.
This is not a waterfall spec—it's a living document that captures strategic context, customer problems, proposed solutions, and success criteria, evolving as you learn through delivery.
A PRD (Product Requirements Document) is a structured document that answers:
# [Feature/Product Name] PRD
## 1. Executive Summary
- One-paragraph overview (problem + solution + impact)
## 2. Problem Statement
- Who has this problem?
- What is the problem?
- Why is it painful?
- Evidence (customer quotes, data, research)
## 3. Target Users & Personas
- Primary persona(s)
- Secondary persona(s)
- Jobs-to-be-done
## 4. Strategic Context
- Business goals (OKRs)
- Market opportunity (TAM/SAM/SOM)
- Competitive landscape
- Why now?
## 5. Solution Overview
- High-level description
- User flows or wireframes
- Key features
## 6. Success Metrics
- Primary metric (what we're optimizing for)
- Secondary metrics
- Targets (current → goal)
## 7. User Stories & Requirements
- Epic hypothesis
- User stories with acceptance criteria
- Edge cases, constraints
## 8. Out of Scope
- What we're NOT building (and why)
## 9. Dependencies & Risks
- Technical dependencies
- External dependencies (integrations, partnerships)
- Risks and mitigations
## 10. Open Questions
- Unresolved decisions
- Areas requiring discovery
When running this workflow as a guided conversation, use workshop-facilitation as the interaction protocol.
It defines:
Other (specify) when useful)This file defines the workflow sequence and domain-specific outputs. If there is a conflict, follow this file's workflow logic.
Use template.md for the full fill-in structure.
This workflow orchestrates 8 phases over 2-4 days , using multiple component and interactive skills.
Goal: Write a one-paragraph overview for skimmers.
1. Draft Executive Summary
Format: "We're building [solution] for [persona] to solve [problem], which will result in [impact]."
Example:
"We're building a guided onboarding checklist for non-technical small business owners to solve the problem of 60% drop-off in the first 24 hours due to lack of guidance, which will increase activation rate from 40% to 60% and reduce churn by 10%."
Participants: PM
Duration: 30 minutes
Output: One-paragraph summary
Tip: Write this first (forces clarity), but refine it last (after other sections are complete).
Goal: Frame the customer problem with evidence.
1. Write Problem Statement
skills/problem-statement/SKILL.md (component)skills/discovery-process/SKILL.md or skills/problem-framing-canvas/SKILL.mdExample Problem Statement:
## 2. Problem Statement
### Who has this problem?
Non-technical small business owners (solopreneurs, 1-10 employees) who sign up for our SaaS product.
### What is the problem?
60% of users abandon onboarding within the first 24 hours because they don't know what to do first. They see an empty dashboard with no guidance, get overwhelmed by options, and leave.
### Why is it painful?
- **User impact:** Wastes time (30-60 min trying to figure out product), never reaches "aha moment," churns before experiencing value
- **Business impact:** 60% activation rate → high churn, low LTV, poor word-of-mouth
### Evidence
- **Interviews:** 8/10 churned users said "I didn't know what to do first" (discovery interviews, Feb 2026)
- **Analytics:** 60% of signups complete 0 actions within 24 hours (Mixpanel, Jan 2026)
- **Support tickets:** "How do I get started?" is #1 support question (350 tickets/month)
- **Customer quote:** "I logged in, saw an empty dashboard, and thought 'now what?' I gave up and went back to my spreadsheet."
2. Add Supporting Context (Optional)
skills/customer-journey-mapping-workshop/SKILL.md outputskills/jobs-to-be-done/SKILL.md outputGoal: Define who you're building for.
1. Document Personas
skills/proto-persona/SKILL.md (component) outputExample:
## 3. Target Users & Personas
### Primary Persona: Solo Entrepreneur Sam
- **Role:** Freelance consultant, solopreneur
- **Company size:** 1 person (no IT support)
- **Tech savviness:** Low (uses email, spreadsheets, basic SaaS)
- **Goals:** Get value from software fast without technical expertise
- **Pain points:** Overwhelmed by complex UIs, no time to watch tutorials, needs immediate value
- **Current behavior:** Signs up for products, tries for 1 day, churns if not immediately useful
### Secondary Persona: Small Business Owner (5-10 employees)
- **Role:** Owner-operator, manages team
- **Needs:** Onboard team members quickly
- **Differs from primary:** More tolerant of complexity, willing to invest setup time
Goal: Explain why this matters to the business and why now.
1. Document Business Goals
"This initiative supports our Q1 OKR: Reduce churn from 15% to 8%. Improving onboarding activation directly impacts retention."
2. Size Market Opportunity (Optional)
skills/tam-sam-som-calculator/SKILL.md (interactive) output"TAM: 50M small businesses globally. SAM: 5M using SaaS tools. SOM: 500K solopreneurs in our target segments. Improving onboarding could unlock 30% of SAM (1.5M potential customers)."
3. Document Competitive Landscape (Optional)
"Competitors (Competitor A, B) have guided onboarding. Our lack of guidance is cited as a churn reason in exit surveys."
4. Explain "Why Now?"
"Churn spiked 15% in Q4. Onboarding is the #1 driver (60% churn in first 30 days). Fixing this is critical to hitting retention OKR."
Goal: Describe what you're building (high-level, not detailed spec).
1. Write Solution Description
Format: High-level overview, 2-3 paragraphs
Example:
We're building a guided onboarding checklist that walks new users through core workflows step-by-step when they first log in.
How it works:
Key features:
2. Add User Flows or Wireframes (Optional)
3. Reference Story Map (Optional)
skills/user-story-mapping-workshop/SKILL.md outputGoal: Define how you'll measure success.
1. Define Primary Metric
2. Define Secondary Metrics
3. Define Guardrail Metrics
Example:
## 6. Success Metrics
### Primary Metric
**Activation rate** (% of users completing first action within 24 hours)
- **Current:** 40%
- **Target:** 60%
- **Timeline:** Measure 30 days after launch
### Secondary Metrics
- **Time-to-first-action:** Reduce from 3 days to 1 day
- **Onboarding checklist completion rate:** 80% of users complete all 3 steps
- **Support tickets:** Reduce "How do I get started?" tickets from 350/month to 175/month
### Guardrail Metrics
- **Sign-up conversion rate:** Maintain at 10% (don't add friction to signup)
Goal: Break solution into user stories with acceptance criteria.
1. Write Epic Hypothesis
skills/epic-hypothesis/SKILL.md (component)Example:
"We believe that adding a guided onboarding checklist for non-technical users will increase activation rate from 40% to 60% because users currently drop off due to lack of guidance. We'll measure success by activation rate 30 days post-launch."
2. Break Down Epic into User Stories
skills/epic-breakdown-advisor/SKILL.md (interactive - with Richard Lawrence's 9 patterns)3. Write User Stories
skills/user-story/SKILL.md (component)Example User Stories:
## 7. User Stories & Requirements
### Epic Hypothesis
We believe that adding a guided onboarding checklist for non-technical users will increase activation rate from 40% to 60% because users currently drop off due to lack of guidance.
### User Stories
**Story 1: Display onboarding checklist on first login**
As a new user, I want to see a guided checklist when I first log in, so I know what to do first.
**Acceptance Criteria:**
- [ ] When user logs in for the first time, modal appears with checklist
- [ ] Checklist shows 3 steps: "Create project," "Invite teammate," "Complete task"
- [ ] Modal is dismissible (close button)
- [ ] If dismissed, checklist doesn't reappear (user preference saved)
**Story 2: Track checklist progress**
As a new user, I want to see my progress as I complete checklist steps, so I feel a sense of accomplishment.
**Acceptance Criteria:**
- [ ] When user completes step 1, checkmark appears next to "Create project"
- [ ] Progress bar updates (1/3 → 2/3 → 3/3)
- [ ] Checklist persists across sessions (if user logs out and back in)
**Story 3: Celebrate checklist completion**
As a new user, I want to receive positive feedback when I complete the checklist, so I feel confident using the product.
**Acceptance Criteria:**
- [ ] When user completes all 3 steps, celebration modal appears
- [ ] Message: "You're all set! Here's what to do next: [suggested next actions]"
- [ ] Confetti animation (optional, nice-to-have)
4. Document Constraints & Edge Cases
Goal: Define what you're NOT building and what you depend on.
1. Document Out of Scope
Example:
## 8. Out of Scope
**Not included in this release:**
- **Advanced onboarding personalization** (e.g., different checklists per persona) — Adds complexity, test simple version first
- **Video tutorials embedded in checklist** — Resource-intensive, validate checklist concept first
- **Gamification (badges, points)** — Nice-to-have, focus on core workflow guidance
**Future consideration:**
- Mobile-optimized onboarding (desktop-first for now)
2. Document Dependencies
Example:
## 9. Dependencies & Risks
### Dependencies
- **Design:** Wireframes for checklist UI (ETA: Week 1)
- **Engineering:** No technical dependencies (uses existing modals framework)
### Risks & Mitigations
- **Risk:** Users dismiss checklist immediately, never see it
- **Mitigation:** Track dismissal rate; if >50%, iterate on messaging or timing
- **Risk:** Checklist steps are too generic, don't resonate with all personas
- **Mitigation:** Start with primary persona (Solo Entrepreneur Sam), personalize later
3. Document Open Questions
Example:
## 10. Open Questions
- Should checklist be mandatory or optional? (Decision: Optional, dismissible)
- Should we A/B test checklist vs. no checklist? (Decision: Yes, show to 50% of new users)
- What happens if user completes steps out of order? (Decision: Allow any order, update checklist dynamically)
Day 1:
├─ Phase 1: Executive Summary (30 min)
├─ Phase 2: Problem Statement (60 min)
│ └─ Use: skills/problem-statement/SKILL.md
├─ Phase 3: Target Users & Personas (30 min)
│ └─ Use: skills/proto-persona/SKILL.md
└─ Phase 4: Strategic Context (45 min)
└─ Use: skills/tam-sam-som-calculator/SKILL.md (optional)
Day 2:
├─ Phase 5: Solution Overview (60 min)
│ └─ Use: skills/user-story-mapping-workshop/SKILL.md (optional)
├─ Phase 6: Success Metrics (30 min)
└─ Phase 7: User Stories & Requirements (90-120 min)
├─ Use: skills/epic-hypothesis/SKILL.md
├─ Use: skills/epic-breakdown-advisor/SKILL.md
└─ Use: skills/user-story/SKILL.md
Day 3:
├─ Phase 8: Out of Scope & Dependencies (30 min)
└─ Review & Refine (60 min)
└─ Read full PRD, polish, get feedback
Day 4 (Optional):
└─ Stakeholder Review & Approval
└─ Present PRD to stakeholders, incorporate feedback
Total Time Investment:
See examples/sample.md for full PRD examples.
Mini example excerpt:
## 2. Problem Statement
- 60% of trial users drop off in first 24 hours
## 6. Success Metrics
- Activation rate: 40% → 60%
Symptom: PM writes PRD alone, presents finished doc to team
Consequence: No buy-in, team doesn't understand rationale
Fix: Collaborate on Phase 7 (user stories) with design + eng; review draft PRD before finalizing
Symptom: "We believe users have this problem" (no data, no quotes)
Consequence: Team questions whether problem is real
Fix: Use discovery insights from skills/discovery-process/SKILL.md; include customer quotes, analytics, support tickets
Symptom: PRD specifies exact UI, pixel dimensions, button colors
Consequence: Removes design collaboration, becomes waterfall spec
Fix: Keep Phase 5 high-level; let design own UI details
Symptom: PRD defines problem + solution but no metrics
Consequence: Can't validate if feature succeeded
Fix: Always define primary metric in Phase 6 (what you're optimizing for)
Symptom: No section on what's NOT being built
Consequence: Scope creep, stakeholders expect features not planned
Fix: Explicitly document out of scope in Phase 8
Phase 2:
skills/problem-statement/SKILL.md (component)skills/problem-framing-canvas/SKILL.md (interactive, for context)skills/customer-journey-mapping-workshop/SKILL.md (interactive, optional)Phase 3:
skills/proto-persona/SKILL.md (component)skills/jobs-to-be-done/SKILL.md (component, optional)Phase 4:
skills/tam-sam-som-calculator/SKILL.md (interactive, optional)Phase 5:
skills/user-story-mapping-workshop/SKILL.md (interactive, optional)Phase 7:
skills/epic-hypothesis/SKILL.md (component)skills/epic-breakdown-advisor/SKILL.md (interactive)skills/user-story/SKILL.md (component)Skill type: Workflow Suggested filename: prd-development.md Suggested placement: /skills/workflows/ Dependencies: Orchestrates 8+ component and interactive skills across 8 phases
Weekly Installs
478
Repository
GitHub Stars
1.5K
First Seen
Feb 12, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
codex438
opencode434
github-copilot431
gemini-cli430
cursor428
kimi-cli426
竞品拆解分析工具:使用 inference.sh CLI 进行结构化竞品研究与截图
7,300 周安装