在依据市场反馈评估产品/功能/战略应转向还是坚持时…

当已有验证学习、到达 MVP 后 pivot-or-persevere 检查点、关键假设被市场反馈证伪或利益相关者争论是否改道时，用来记录并支撑转向/坚持决策。

适用场景

解决思路

1. 总结当前状态：记录当前在做什么、做了多久、已投入什么、取得了什么结果，让决策扎根于现实。
2. 呈现证据：汇总所有相关数据，包括指标、用户反馈、实验结果、市场信号；要全面，并同时包含支持坚持和支持改变方向的证据。
3. 回顾假设：重新审视支撑当前方向的原始假设；标出哪些已验证、哪些已证伪、哪些尚未测试。
4. 定义选项：至少写出三个选项，即坚持当前方向 persevere，以及两个或更多不同的转型 pivot 选项；具体描述每个选项会改变什么。
5. 分析每个选项：按关键标准评估每个选项，包括市场机会、竞争优势、团队能力、资源需求、风险；使用证据，不用观点。
6. 做出决策：明确说明选定的方向；解释理由并承认权衡；如果团队有分歧，记录异议。
7. 规划实施：列出下一步，包括即时行动、资源需求、新方向的成功标准、沟通计划。
8. 使用 references/TEMPLATE.md 组织输出；完整的决策文档填写所有模板章节：Overview；Executive Summary；Current State；Evidence Summary；Hypothesis Review；Options Considered；Analysis；Decision；Implementation Plan；Communication Plan；Appendix。
9. 定稿前按质量清单验证：当前状态包含对结果的诚实评估；证据全面而非挑拣；多个选项被公平分析；决策理由清晰且基于证据；实施计划可执行；异议被记录。
10. 参考 references/EXAMPLE.md 中的完整示例。

适用边界 · 注意事项

• 只是报告实验结果、没有附带方向决策时，应使用 measure-experiment-results；技术或架构决策应使用 develop-adr。
• 尚未决定任何方向、只想先探索候选方向时，应使用 define-opportunity-tree；团队需要期末反思仪式时，应使用 iterate-retrospective，pivot call 是决策文档不是复盘。
• 产品尚未构建、问题是是否要构建新想法/功能或是否裁剪范围（build/validate/cut 判断）时，应使用 foundation-build-risk-review；pivot call 针对已发布内容权衡市场反馈。