评估功能是否值得投入：用收入影响、成本结构、ROI…

当要在多个功能间排序、评估高成本功能或向利益相关者论证优先级时，用财务模型给出是否构建的建议。

适用场景

解决思路

1. 交互总则：使用 workshop-facilitation 作为默认交互协议；开场说明会话方式与入口模式（Guided、Context dump、Best guess），一次问一个问题并用平实提示；显示进度标签如 Context Qx/8、Scoring Qx/5；处理中断并支持暂停/继续；决策点给编号建议；常规问题提供 3-5 个可快速选择的编号选项，必要时包含 Other (specify)；如果冲突，以本领域逻辑为准。
2. 收集上下文：让用户提供功能描述（1-2 句）和目标客户群（SMB、mid-market、enterprise、all）；当前业务背景 MRR/ARR 或客户数（预收入）、ARPU/ARPA、月度流失率、毛利率%；约束：开发成本估算（团队规模×时间）、持续 COGS/OpEx 影响；没有精确数字可给估算。若 invocation 已提供内容，直接使用并跳过已覆盖问题。
3. 识别收入关联：让用户选择五类之一或自定义：直接变现、留存改善、转化改善、扩展使能、无直接收入影响。
4. 若直接变现：询问定价、客户采用率（保守/基准/乐观）；计算 Potential Monthly Revenue = Customer Base × Adoption Rate × Price。
5. 若留存改善：询问该功能解决多少流失（如 30% 流失客户提到此缺口）、预期流失降低（如 5%→4% 月度流失）；计算 LTV Impact = Increase in Customer Lifetime × Customer Base × ARPU × Margin。
6. 若转化改善：询问当前 trial-to-paid 转化率、预期提升（如 20%→25%）；计算 Additional MRR = Trial Users × Conversion Lift × ARPU。
7. 若扩展使能：询问扩展机会（升级档、用量增长、加购）、多少客户会扩展；计算 Expansion MRR = Customer Base × Expansion Rate × ARPU Increase。
8. 若无直接收入影响：跳到战略价值评估。
9. 评估成本结构：询问一次性开发成本（工程师数、周/月、估算 $）、持续成本（COGS $/月、OpEx $/月），无则填 $0。
10. 计算成本指标：一次性投资=开发成本；持续月成本=COGS+OpEx；贡献毛利影响=(Revenue - COGS)/Revenue。
11. 成本红旗：若 COGS >20% 预计收入，提示该功能显著稀释毛利；若持续成本相对收入过高，提示考虑是否可持续。
12. 评估约束与时机：让用户选择或描述：时间敏感的竞争威胁、有限预算/团队容量、依赖其他工作、无重大约束。
13. 若竞争威胁：提高战略价值（防流失）并在建议中体现紧迫性。
14. 若容量有限：将 ROI 与 backlog 中其他功能比较，建议 stack ranking。
15. 若依赖：标记依赖风险，建议排期顺序。
16. 若无约束：进入建议。
17. 交付建议：综合收入影响、成本结构、约束、ROI 计算、战略价值评估，提供 3-4 个建议；不要只做功能评分，要结合财务分析与战略判断。
18. 强财务理由建议模式：条件 ROI >3:1（直接变现）或 LTV 影响 >10:1（留存/扩展）、贡献毛利为正、无重大红旗。建议立即构建；给出收入影响（保守/乐观 $/月）、成本（开发 $、持续 COGS/OpEx $/月、净毛利影响 %）、ROI（Year 1 ROI ___:1、回收期 ___ 月）、为什么合理、下一步（与客户研究验证定价/采用假设、构建 MVP 测试核心价值、监控特定指标）。
19. 弱财务但战略构建建议模式：条件 ROI <2:1 或财务影响边际，但战略价值高（competitive、platform、compliance）。建议因战略原因构建（财务理由边际）；陈述财务现实（收入影响 $/月、开发成本 $、ROI ___:1 低于 3:1 阈值）、战略价值（competitive moat/platform enabler/market requirement；防流失到竞品 X；企业段 30% pipeline 需要）；建议构建但密切监控：跟踪采用 vs 预测、衡量流失影响（目标降低 ___%）、6 个月后若采用低则重新评估；风险：机会成本，其他功能可能 ROI 更好。
20. 不构建建议模式：条件 ROI <1:1（直接变现）或 LTV 影响为负、稀释毛利、无有力战略价值。建议不构建——财务不支持；说明收入影响 $/月、开发成本 $、ROI ___:1 低于盈亏平衡、毛利影响从 ___% 稀释到 ___%；替代方案：减少范围（50% 成本做简化版？）、改变变现（能否收费更高/不同？）、降优先级（聚焦更高 ROI 功能如 ___）；需要改变什么：采用率从 ___% 到 ___% ROI 才可行，或开发成本降到 $___ 回收期才可接受。
21. 晚点构建/需要更多数据建议模式：条件假设高度不确定、收入影响依赖未验证假设、中等战略价值。建议晚点构建——先验证假设；列当前不确定性：采用率 ___%（需验证）、流失影响 ___%（假设未证明）、定价未知；验证动作：对 50+ 客户做功能需求调查、做原型并测试支付意愿、访谈流失客户确认此功能是否解决流失原因；决策标准：若 ___% 客户说愿付 $___ 则构建；若流失访谈确认是 top 3 原因则构建；否则降优先级；时间线：花 2-4 周验证，再用真实数据重新评估。
22. 允许后续问题：询问是否要看详细数学拆解、与另一个功能比较、调整假设（定价、采用、成本）、导出建议摘要；可展示详细计算、敏感性分析（采用率 2x/0.5x 会怎样）、并排比较多个功能、为利益相关者导出摘要。
23. 避坑/修正 1：区分收入与利润；用贡献毛利 Revenue × Margin %，而非只看收入。
24. 避坑/修正 2：检查回收期，必须短于平均客户生命周期。
25. 避坑/修正 3：不要高估采用；加购使用保守采用率 10-20%，用支付意愿研究验证。
26. 避坑/修正 4：不要未验证就构建；先访谈流失客户，确认功能针对 top 3 流失原因。
27. 避坑/修正 5：不要忽略机会成本；比较多个功能 ROI，优先最高 ROI，除非战略价值覆盖。
28. 避坑/修正 6：不要把战略价值当借口；明确定义战略（competitive moat、platform enabler、compliance），不符合就不是战略。
29. 避坑/修正 7：不要忽视毛利稀释；计算贡献毛利，若 margin <50% 则重新考虑或收溢价。
30. 避坑/修正 8：不要庆祝虚荣指标；将功能关联收入或留存；参与度是领先指标不是结果。
31. 避坑/修正 9：不要忘记货币时间价值；回收期 >24 个月时用 NPV 折现未来现金流。
32. 避坑/修正 10：不要为吵闹的少数构建；按收入影响或客户分群加权需求；若企业是战略，10 个企业客户 > 100 个 SMB 客户。

适用边界 · 注意事项

• 功能是竞争必需的表配项（table stakes），只需持平而非差异化。
• 影响纯定性（品牌、UX delight），无法衡量留存或收入影响。
• 尚未验证问题（先做 discovery），或功能工作量 <1 周（直接做即可）。