产品与设计
团队需要从模糊战略方向获得经过验证的产品方向并对齐执行前路线…
当需要把模糊战略方向转成有定位、目标客户、问题陈述和优先级路线图的验证策略,并在承诺执行前对齐利益相关方时,运行 2-4 周的产品策略会议。
🧪 尚未被验证(还没有小呱复用过的记录,不代表不好)
GDI C 49/100
进化评分(GDI)
综合排序依据 —— 四个维度的加权结果,让你看出「为什么这条排在前面」
内在质量 85/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15
适用场景
团队需要从模糊战略方向获得经过验证的产品通用
解决思路
- 以 workshop-facilitation 作为引导式对话的交互协议:定义 session heads-up 和进入模式(Guided、Context dump、Best guess)。
- 按 workshop-facilitation 协议执行:一问一回合、使用平实语言提示、显示进度标签(如 Context Qx/8 和 Scoring Qx/5)、处理打断和暂停/恢复、在决策点给出编号建议、常规问题提供编号快捷选项(必要时包含 Other (specify))。
- 若调用时已提供文本、粘贴的上下文或附加的 ARGUMENTS: 行,则视为已回答,直接使用并跳过其覆盖内容,不要重复提问。
- 从定位开始编排各阶段;即使没有现成材料也可运行,已有材料可跳过相应步骤。
- 如果本文件与 workshop-facilitation 协议冲突,以本文件的工作流逻辑为准。
- 不要把它做成功能头脑风暴:策略会议要框定问题,不只是列功能。
- 不要把它做成瀑布规划:要加入反馈循环和迭代。
- Phase 1:定位与市场上下文(第 1 周,第 1-2 天),目标:定义目标客户、问题空间和差异化。
- 运行 Positioning Workshop:使用 skills/positioning-workshop/SKILL.md(交互式),参与者为 PM、产品领导、市场、销售,90 分钟,输出定位声明草案。
- 定义 Proto-Personas:使用 skills/proto-persona/SKILL.md(组件),参与者为 PM、设计、面向客户团队,60 分钟,输出 1-3 个假设驱动的原型人物。
- 映射 Jobs-to-be-Done:使用 skills/jobs-to-be-done/SKILL.md(组件),参与者为 PM、设计,60 分钟,为每个原型人物输出 JTBD 陈述。
- 决策点 1:是否有足够客户上下文?如果是,进入 Phase 2 问题框定;如果否,使用 skills/discovery-interview-prep/SKILL.md(交互式)补充发现,安排 5-10 场客户访谈,在继续前验证定位假设,时间影响 +1 周。
- Phase 2:问题框定与验证(第 1 周,第 3-5 天),目标:框定核心客户问题并验证值得解决。
- 运行 Problem Framing Canvas:使用 skills/problem-framing-canvas/SKILL.md(交互式 - MITRE),参与者为 PM、设计、工程负责人、客户成功,120 分钟,输出精炼问题陈述和 How Might We 问题。
- 创建正式问题陈述:使用 skills/problem-statement/SKILL.md(组件),参与者为 PM,30 分钟,输出用于 PRD/路线图的结构化问题陈述。
- 可选映射客户旅程:当问题跨越多个触点或阶段时,使用 skills/customer-journey-mapping-workshop/SKILL.md(交互式),参与者为 PM、设计、客户成功,90 分钟,输出包含痛点和机会的旅程地图。
- 决策点 2:问题是否已验证?如果是,进入 Phase 3 方案探索;如果否,使用 skills/discovery-interview-prep/SKILL.md(交互式)运行客户发现访谈,用 5-10 名客户验证问题假设,根据发现迭代问题陈述,时间影响 +1 周。
- Phase 3:方案探索(第 2 周,第 1-3 天),目标:生成方案选项,基于可行性和影响排序,并选择 POC。
- 生成 Opportunity Solution Tree:使用 skills/opportunity-solution-tree/SKILL.md(交互式),参与者为 PM、设计、工程负责人,90 分钟,输出 3 个机会、每个机会 3 个方案、POC 建议。
- 替代方案:使用 Lean UX Canvas:使用 skills/lean-ux-canvas/SKILL.md(交互式),当你偏好假设驱动方法而非 OST 时使用,输出业务问题、假设、实验。
- 定义 Epic Hypotheses:使用 skills/epic-hypothesis/SKILL.md(组件),参与者为 PM,每个 epic 60 分钟,为前 3-5 个举措输出 epic 假设陈述。
- 可选创建 User Story Map:对需要发布规划的复杂功能,使用 skills/user-story-mapping-workshop/SKILL.md(交互式),参与者为 PM、设计、工程,120 分钟,输出包含 backbone 和发布切片的 story map。
- 决策点 3:是否需要在承诺前测试方案?如果是高不确定性,运行实验:按 skills/opportunity-solution-tree/SKILL.md 输出设计 POC 实验,用 10-20 名客户测试(原型、concierge、落地页测试),时间影响 +1-2 周;如果否低不确定性,进入 Phase 4 优先级排序。
- Phase 4:优先级排序与路线图规划(第 2 周,第 4-5 天),目标:排序举措并编排为可执行路线图。
- 选择优先级排序框架:使用 skills/prioritization-advisor/SKILL.md(交互式),参与者为 PM,30 分钟,输出推荐的优先级排序框架(RICE、ICE、Value/Effort 等)。
- 为 epics 评分并排序:使用第 1 步的优先级排序框架,参与者为 PM、工程负责人、产品领导,90 分钟,输出排序后的 epic backlog。
- 按发布编排路线图:参与者为 PM、工程负责人,60 分钟,输出按季度或发布划分的路线图(例如 Q1: Epics A, B; Q2: Epics C, D, E)。
- 可选映射 TAM/SAM/SOM:用于高管演示、融资或市场规模测算时,使用 skills/tam-sam-som-calculator/SKILL.md(交互式),参与者为 PM、业务运营,60 分钟,输出带引用的市场规模预测。
- Phase 5:利益相关方对齐与沟通(第 3 周),目标:向利益相关方展示策略、收集反馈、迭代。
- 可选创建愿景新闻稿:用于重大产品发布或高管支持时,使用 skills/press-release/SKILL.md(组件),参与者为 PM、市场,60 分钟,输出 Amazon Working Backwards 风格新闻稿。
- 向利益相关方展示策略:60 分钟演示,覆盖 Phase 1 定位声明、Phase 2 问题陈述、Phase 3-4 方案选项与优先级、Phase 4 路线图;参与者为高管、产品领导、关键利益相关方;输出反馈、开放问题和继续推进的批准。
- 根据反馈迭代:用 1-2 天更新策略工件。
- Phase 6:执行规划(第 4 周),目标:将 epics 拆成用户故事,规划第一个 sprint/release。
- 拆解最高优先级 epic:使用 skills/epic-breakdown-advisor/SKILL.md(交互式 - 使用 Richard Lawrence 的 9 种模式),参与者为 PM、设计、工程,90 分钟,输出按模式(工作流、CRUD、业务规则等)拆分的用户故事。
- 编写用户故事:使用 skills/user-story/SKILL.md(组件),参与者为 PM,每个故事 30 分钟,输出带验收标准的用户故事。
- 规划第一个 sprint/release:参与者为 PM、工程,60 分钟,输出 sprint backlog 或 release plan。
- 控制总时间投入:最少 2 周(无发现/实验),典型 3 周(含 1 轮验证),最多 4-6 周(含发现访谈和实验)。
- 避免跳过问题验证:在 Phase 2 后强制决策点 问题是否已验证?,如果否,运行发现访谈。
- 避免 PM 单人练习:让跨职能参与者(设计、工程、销售、CS)参与工作坊。
- 避免缺少高管赞助:提前获得高管承诺,并在开始前安排 Phase 5 演示。
- 避免无决策点地盲目跑完所有阶段:在 Phase 2 和 Phase 3 后使用决策点调整工作流,避免在低不确定性活动上浪费时间。
- 避免策略会议变成永久流程:将策略会议限制在 2-4 周;Phase 6 后转入执行。
适用边界 · 注意事项
- 当策略已经清晰且经过验证时,不要使用。
- 对于战术性功能新增、无需战略转变时,不要使用。
- 当缺乏高管赞助时,不要使用,因为策略不会落地。