关于 feature-investment-advisor
面向产品经理的财务评估技能，用于判断功能是否值得投入。它结合收入影响、开发与持续成本、投资回报和战略价值，形成有计算依据的构建或暂缓建议。
主要功能
- 01分析直接与间接收入影响
- 02估算开发及持续成本
- 03计算 ROI 与利润率影响
- 04评估战略价值和限制
- 05给出构建决策与后续建议
适用场景
- 01比较多个功能的财务回报
- 02评估高成本功能是否值得开发
- 03为构建、采购或合作决策提供依据
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/feature-investment-advisor确认已加载。
附带文件examples/conversation-flow.md
详细介绍
目的
指导产品经理通过财务影响分析，评估是否构建某项功能。通过评估收入关联（直接或间接）、成本结构（开发成本 + 销货成本 + 运营支出）、投资回报率（ROI）和战略价值，做出数据驱动的优先级决策，然后根据计算结果给出可执行的构建或不构建建议。
这不是通用的优先级框架，而是用于功能决策的财务视角，可与其他优先级方法（RICE、价值与投入对比、用户研究）互为补充。在财务影响是关键决策因素时使用。
输入
最适合提供： 你正在考虑的功能，用一两句话说明。 也可以提供： 收入关联（直接或间接）、大致成本数据（开发时间、销货成本、持续运营支出），以及支持构建该功能的战略论据。
随调用一并提供的任何内容——技能名称之后的文本、粘贴的上下文，或附加的 ARGUMENTS: 行——都视为已给出的答案。请使用这些内容，并跳过其中已涵盖的问题，不要重复询问。
没有准备任何信息也没关系。 顾问会先询问功能是什么，以及它如何带来收入或节省成本。
调用示例： Should we build SSO/SAML? Enterprise deals keep stalling on it; est. 2 engineer-months plus ongoing support burden.
核心概念
功能投资框架
系统地从财务角度评估功能：
-
收入关联 — 此功能如何影响收入？
- 直接变现（新套餐、附加项、按用量收费）
- 间接变现（留存、转化、助力客户扩展）
-
成本结构 — 构建和运行此功能需要多少成本？
- 开发成本（一次性投入）
- 销货成本影响（持续的基础设施和处理成本）
- 运营支出影响（持续的支持和维护成本）
-
投资回报率（ROI）计算 — 回报是否值得这笔投入？
- 直接变现：收入影响 / 开发成本
- 留存功能：客户群体整体的生命周期价值（LTV）影响 / 开发成本
- 考虑毛利率，而不只是收入
-
战略价值 — 可能超过纯粹投资回报率考量的非财务价值
- 竞争壁垒（防止客户流失至竞争对手）
- 平台赋能（解锁未来功能）
- 市场定位（企业交易所需）
- 风险降低（合规、安全）
反模式（本框架不是什么）
- 不只是功能评分： 将财务分析与战略判断相结合
- 不只看收入： 考虑利润率、成本和投资回报率，而不只是总收入
- 不忽视留存： 间接收入影响（降低流失率）同样有效
- 不未经验证就构建： 假设你已完成探索；本框架提供的是财务视角
何时使用本框架
适用于以下情况：
- 在收入或留存影响可量化的功能之间确定优先级
- 评估成本较高的功能（开发工作量超过 1 个工程师月）
- 决定自建、购买或合作
- 向利益相关者或领导层说明功能优先级的合理性
- 在直接变现（附加项）与间接变现（留存）之间做选择
不适用于以下情况：
- 功能属于竞争基准线要求（保持竞争力不可或缺）
- 影响纯属定性（品牌、用户体验愉悦感，但没有可衡量的留存效果）
- 尚未验证问题（先进行探索）
- 功能开发工作量不到 1 周（直接构建）
促成工作的权威指南
默认情况下，请使用 workshop-facilitation 作为此技能的交互协议。
其中定义了：
- 会话提示与进入模式（引导、上下文转储、最佳猜测）
- 每轮只问一个问题，并使用通俗易懂的提示
- 进度标签（例如 Context Qx/8 和 Scoring Qx/5）
- 中断处理以及暂停/恢复行为
- 在决策节点提供编号建议
- 常规问题提供编号快速选择项（适用时包含
Other (specify)）
此文件定义了特定领域的评估内容。如有冲突，请遵循此文件中的领域逻辑。
应用
此交互式技能会提出最多 4 个自适应问题，并在决策节点提供3-5 个编号选项。
步骤 0：收集上下文
Agent 提问：
“我们来评估这项功能投资对财务的影响。请提供以下信息：
功能描述：
- 这是什么功能？（1-2 句话）
- 目标客户群体（SMB、中端市场、企业、所有客户）
当前业务背景：
- 当前 MRR/ARR（如果尚未产生收入，则提供客户数量）
- 当前 ARPU/ARPA
- 当前月流失率
- 毛利率 %
限制条件：
- 开发成本估算（团队规模 × 时间）
- 是否会影响持续性 COGS 或 OpEx？
如果没有确切数字，可以提供估算值。”
步骤 1：确定收入关联
Agent 提问：
“此功能如何影响收入？请选择最能描述其收入关联的选项：
- 直接变现（新的收入来源） — 我们将对此收费（新的定价层级、付费附加组件、按使用量收费）
- 提高留存率（降低流失） — 解决导致客户流失的主要原因，留住客户
- 提高转化率（从试用转为付费） — 帮助将免费用户/试用用户转化为付费客户
- 促进扩张（追加销售/交叉销售） — 创造追加销售机会或推动按使用量扩张
- 不直接影响收入 — 仅属于基础必备功能、平台改进或战略价值
请选择一个数字，或描述自定义的收入关联。”
Agent 根据所选选项调整提问：
如果选择 1（直接变现）：
- “您考虑的定价是多少？”
- “您预计有多少比例的客户会采用此功能？”（保守、基准、乐观）
- 计算：
潜在月收入 = 客户群体规模 × 采用率 × 价格
如果选择 2（提高留存率）：
- “此功能可以解决多少比例的客户流失问题？”（例如，“30% 的流失客户表示缺少此功能”）
- “您预计流失率会降低多少？”（例如，“月流失率从 5% 降至 4%”）
- 计算：
LTV 影响 = 客户生命周期延长时间 × 客户群体规模 × ARPU × 利润率
如果选择 3（提高转化率）：
- “当前试用转付费转化率是多少？”
- “预计转化率会提高多少？”（例如，“转化率从 20% 提升至 25%”）
- 计算：
新增 MRR = 试用用户数 × 转化率提升幅度 × ARPU
如果选择 4（促进扩张）：
- “此功能会创造什么扩张机会？”（追加销售层级、使用量增长、附加组件）
- “预计有多少比例的客户会扩张？”
- 计算：
扩张 MRR = 客户群体规模 × 扩张率 × ARPU 增幅
如果选择 5（不直接影响收入）：
- 跳转到战略价值评估
步骤 2：评估成本结构
Agent 提问：
“此功能的成本结构是什么？
开发成本（一次性）：
- 团队规模：___ 名工程师
- 时间估算：___ 周/月
- 预计开发成本：$___
持续性成本（如有）：
- COGS 影响：$___ /月（托管、基础设施、处理）
- OpEx 影响：$___ /月（支持、维护）
如果没有持续性成本，请填写 $0。”
Agent 计算：
- 一次性投资：开发成本
- 每月持续性成本：COGS + OpEx
- 贡献毛利影响：
(收入 - COGS) / 收入
Agent 提示：
- 如果 COGS > 预计收入的 20%：“⚠️ 此功能会显著拉低利润率”
- 如果持续性成本相对于收入较高：“⚠️ 请考虑这是否可持续”
第 3 步：评估约束条件和时间安排
Agent 询问：
“有哪些约束条件或时间安排方面的考虑？
- 面临时间紧迫的竞争威胁 — 竞争对手推出了这项功能；我们正在失去交易
- 预算／团队产能有限 — 本季度我们只能开发一项重要功能
- 依赖其他工作 — 需要先改进平台或开发其他功能
- 没有重大约束 — 我们有足够的产能和灵活性
请选择一个数字，或描述你的约束条件。”
根据选择：
如果选择 1（竞争威胁）：
- 战略价值增加（防止客户流失）
- 在建议中考虑紧迫性因素
如果选择 2（产能有限）：
- 将投资回报率与待办事项中的其他功能进行比较
- 建议进行优先级排序
如果选择 3（存在依赖）：
- 标出依赖风险
- 建议安排实施顺序
如果选择 4（没有约束）：
- 继续提供建议
第 4 步：给出建议
Agent 综合考虑：
- 收入影响（来自第 1 步）
- 成本结构（来自第 2 步）
- 约束条件（来自第 3 步）
- 投资回报率计算
- 战略价值评估
Agent 提供 3–4 条建议：
建议模式 1：财务依据充分
适用情形：
- ROI >3:1（直接变现）或 LTV 影响 >10:1（留存／扩张）
- 贡献利润率为正
- 没有重大风险信号
建议：
“立即开发 — 财务依据充分
收入影响：
- [直接／间接收入影响的计算]
- 保守估算：每月 $___
- 乐观估算：每月 $___
成本：
- 开发：$___
- 持续 COGS／OpEx：每月 $___
- 净利润率影响：___%
ROI：
- 第 1 年 ROI：___:1
- 回本周期：___ 个月
这样做的理由： [根据具体数据给出理由]
后续步骤：
- 通过客户调研验证定价／采用率假设
- 构建 MVP，测试核心价值主张
- 监控[具体指标]以衡量影响”
建议模式 2：财务依据不足，但仍值得开发（战略性考虑）
适用情形：
- ROI <2:1 或财务影响有限
- 但战略价值较高（竞争、平台、合规）
建议：
“出于战略原因开发（财务依据有限）
财务现状：
- 收入影响：每月 $___（较小）
- 开发成本：$___
- ROI：___:1（低于 3:1 的门槛）
战略价值：
- [竞争壁垒／平台赋能／市场要求]
- 防止客户流失至竞争对手 X
- 企业客户群体（销售线索的 30%）所必需
建议： 开发，但要密切监控：
- 跟踪实际采用情况与预测的差异
- 衡量对客户流失的影响（目标：将客户流失率降低 ___%）
- 如果采用率偏低，6 个月后重新评估
风险： 机会成本——其他功能的 ROI 可能更高”
建议模式 3：不予开发（ROI 不佳）
适用情形：
- ROI <1:1（直接变现）或 LTV 影响为负
- 会稀释利润率
- 没有令人信服的战略价值
建议：
“不予开发 — 财务依据不足以支持这项投资
原因：
- 收入影响：每月 $___
- 开发成本：$___
- ROI：___:1（低于盈亏平衡点）
- 利润率影响：毛利率从 ___% 降至 ___%
替代方案：
- 缩小范围 — 能否以 50% 的成本开发更简单的版本？
- 调整变现方式 — 能否提高收费或采用不同的收费方式？
- 降低优先级 — 专注于[替代方案]等 ROI 更高的功能
需要满足的条件：
- 如果采用率从 ___% 提高到 ___%，ROI 就会变得可行
- 如果能将开发成本降至 $___，回本周期就会变得可接受”
建议模式 4：稍后构建 / 需要更多数据
适用情况：
- 假设存在高度不确定性
- 收入影响取决于尚未验证的假设
- 战略价值中等
建议：
"稍后构建 — 先验证假设
当前的不确定性：
- 采用率假设：___%（需要验证）
- 流失率影响：降低 ___%（尚未证实的假设）
- 定价未知
需要验证的事项：
- 针对 50 位以上客户开展功能需求调查
- 制作原型并测试付费意愿
- 采访已流失客户，确认此功能是否能解决其流失原因
决策标准：
- 如果 % 的客户表示愿意支付 $，则构建
- 如果流失客户访谈确认这是排名前三的原因，则构建
- 否则，降低优先级
时间安排：
- 花 2-4 周验证
- 根据实际数据重新评估"
第 5 步：允许提出后续问题
Agent 提供：
"你想要：
- 查看详细的计算过程
- 将此功能与其他功能进行比较
- 调整假设（定价、采用率、成本）
- 导出建议摘要
或者，提出任何后续问题。"
Agent 可以：
- 显示详细计算
- 进行敏感性分析（如果采用率是 2 倍或 0.5 倍，会怎样？）
- 并排比较多个功能
- 导出摘要，供利益相关者参考
示例
示例对话流程请参见 examples/ 文件夹。以下是一些简短示例：
示例 1：直接变现（时间跟踪附加组件）
用户：“我们正在考虑将时间跟踪作为付费附加组件来构建。”
Agent：[收集背景信息]
用户提供：
- 当前情况：1,000 位客户，$500 ARPU，80% 毛利率
- 功能：时间跟踪附加组件，$10/用户/月
- 开发成本：$100K（2 位工程师 × 3 个月）
- 预估采用率：20% 的客户
Agent 计算：
- 每个账户平均有 10 位用户 = 1,000 个账户 × 10 位用户 = 10,000 位用户
- 采用率：20% 的用户 = 2,000 位用户
- 收入：2,000 × $10 = $20K/月 = $240K/年
- 利润率：$240K × 80% = $192K/年毛利
- ROI：$192K / $100K = 第 1 年为 1.92:1
- 回本时间：$100K / $20K = 5 个月
Agent 建议：
"立即构建 — ROI 为正，且回本时间短
收入影响： $240K/年（按保守的 20% 采用率计算） ROI： 第 1 年为 1.92:1，第 2 年为 3.8:1 回本时间： 5 个月
此方案奏效的原因：
- 回本时间短（5 个月），意味着风险较低
- 附加组件收入的毛利率为 80%
- 20% 的采用率估计较为保守（测试付费意愿）
后续步骤：
- 调查客户：谁愿意为时间跟踪功能支付 $10/用户？
- 构建仅包含核心时间跟踪功能的 MVP
- 在全面发布前，邀请 50 位客户参与 Beta 测试
- 跟踪采用率与 20% 目标的差异"
示例 2：留存功能（数据导出）
用户：“客户无法轻松导出数据，导致我们正在流失客户。我们应该构建一套全面的导出功能吗？”
Agent：[收集背景信息]
用户提供：
- 当前：$2M MRR，500 位客户，$4K ARPA，月流失率 5%
- 功能：完整数据导出（CSV、API、定时导出）
- 开发成本：$150K（3 名工程师 × 2 个月）
- 流失背景：30% 的流失客户表示，数据导出是原因之一
Agent 计算：
- 当前年度流失率：约 46%（按月复合计算，月流失率为 5%）
- 年度流失客户数：500 × 46% = 230 位客户
- 因导出问题而流失的客户数：230 × 30% = 69 位客户
- 流失的 MRR：69 × $4K = 每年损失 $276K MRR = $3.3M ARR
如果该功能将此情况减少 50%：
- 挽留的客户数：每年 35 位
- 挽留的 MRR：每年 $140K
- LTV 影响（假设客户生命周期为 24 个月）：$140K × 24 = $3.36M
Agent 计算 ROI：
- 投资：$150K
- 挽留的 LTV：$3.36M（保守估计，按减少 50% 计算）
- ROI：$3.36M / $150K = 22.4:1 🚀
Agent 建议：
“立即构建——留存方面的 ROI 极高
影响：
- 每年可避免约 35 位客户流失
- 每年挽留 $140K MRR
- LTV 影响：客户生命周期内共 $3.36M
- ROI：22:1（极高）
为什么这是显而易见的选择：
- 30% 的客户流失都提到了这一缺口（问题已得到验证）
- 即使只能避免 25% 的流失（而非 50%），ROI 仍为 11:1
- 留存改善会产生复合效应（也能减少未来的流失）
后续步骤：
- 采访流失客户，验证数据导出是否是主要原因
- 先构建核心导出功能（CSV、API）
- 上线后衡量流失率变化（目标：5% → 4.5%）
- 如果采用率较高，再添加定时导出”
示例 3：ROI 较低的功能（深色模式）
用户：“用户在请求深色模式。我们应该优先开发吗？”
Agent：[收集背景信息]
用户提供：
- 当前：$500K MRR，2,000 位客户，$250 ARPA，月流失率 3%，毛利率 75%
- 功能：产品全范围深色模式
- 开发成本：$80K（2 名设计师 + 2 名工程师 × 1 个月）
- 收入关联：间接关联——可能略微改善留存
Agent 询问：“有什么证据表明深色模式能降低流失率？”
用户：“50 位用户提出了功能请求。没有流失影响方面的数据。”
Agent 计算：
- 2,000 位客户中有 50 位提出功能请求 = 客户群的 2.5%
- 没有经过验证的流失影响
- 开发成本：$80K
- 乐观情景：每年避免 5 位客户流失（客户群的 2.5%）
- 挽留的 MRR：5 × $250 = 每月 $1,250 = 每年 $15K
- LTV 影响（假设客户生命周期为 24 个月）：$15K × 24 = $360K
ROI：$360K / $80K = 4.5:1（看起来还不错，但基于薄弱的假设）
Agent 建议：
“稍后再构建——ROI 依据不足
当前评估：
- 收入影响：每年 $15K（乐观估计）
- 开发成本：$80K
- ROI：4.5:1（假设深色模式能避免客户流失）
问题：
- 只有 50 位用户提出了这一请求（客户群的 2.5%）
- 没有证据表明深色模式能降低流失率
- 流失客户访谈中，没有人将其列为主要原因
替代方案：
- 调查流失客户——深色模式是否位列流失原因前 5 名？
- 测试需求——询问试用用户：“深色模式会影响您是否决定转为付费用户吗？”
- 缩小范围——构建基础深色模式（成本为 20%）作为实验
值得考虑的更好功能：
- 如果优先考虑留存：采访流失客户，找出导致流失的 3 大原因
- 如果优先考虑收入：关注扩展功能（追加销售、附加组件）
构建决策标准：
- 如果流失客户访谈显示深色模式是前 3 大原因之一 → 构建
- 如果转化率研究显示影响达到 10% 以上 → 构建
- 否则 → 降低优先级”
常见误区
误区 1：混淆收入与利润
表现：“这个功能将带来 $1M 的收入！”（忽略 $800K 的销货成本）
后果：$1M 收入在 20% 利润率下只值 $200K 利润，而非 $1M。只有计入成本后，才会发现这个功能并不那么出色。
**解决方法：**始终计算贡献利润率。使用 Revenue × Margin %，而不只是收入。
陷阱 2：忽视回本周期
症状：“ROI 是 5:1，开始开发吧！”（但回本需要 36 个月，而客户会在 24 个月时流失）
**后果：**客户在回本之前就离开了，你永远无法收回投资。
**解决方法：**检查回本周期。回本周期必须短于客户的平均生命周期。
陷阱 3：高估采用率
症状：“100% 的客户都会使用这个付费附加功能！”
**后果：**实际采用率为 10-20%。收入预测会高出 5-10 倍。
**解决方法：**采用保守的采用率估算（附加功能为 10-20%）。通过付费意愿调研进行验证。
陷阱 4：未经验证就开发
症状：“我们认为这能降低流失率”（没有访谈客户）
**后果：**你开发的功能并未解决真实的流失原因。流失率保持不变。
**解决方法：**先访谈已流失的客户。验证此功能能否解决导致流失的前三大原因。
陷阱 5：忽视机会成本
症状：“这个功能的 ROI 是 2:1，开始开发吧！”（其他功能的 ROI 是 10:1）
**后果：**更好的选择还在待办列表中，你却开发了一个平平无奇的功能。
**解决方法：**比较各项功能的 ROI。优先开发 ROI 最高的功能（除非战略价值更重要）。
陷阱 6：把战略价值当作借口
症状：“ROI 很糟糕，但它有战略意义！”（没有明确的战略）
后果：“战略意义”成了开发低价值功能的万能借口。
**解决方法：**明确“战略意义”的定义（竞争护城河、平台赋能、合规）。如果不符合这些条件，就不具备战略意义。
陷阱 7：忽视利润率稀释
症状：“这个功能能增加 50 万美元收入！”（但销货成本为 40 万美元）
**后果：**毛利率从 80% 降至 60%。该功能会破坏单位经济效益。
**解决方法：**计算贡献毛利率。如果毛利率低于 50%，就重新考虑，或提高收费。
陷阱 8：为虚荣指标喝彩
症状：“这个功能能提升参与度！”（但不会增加收入或留存率）
**后果：**你开发了让人感觉良好、却不会影响业务成果的功能。
**解决方法：**将功能与收入或留存率挂钩。参与度是领先指标，而非最终成果。
陷阱 9：忘记货币的时间价值
症状：“这个功能要 5 年才能回本。”
**后果：**5 年后的 1 美元，按 9% 的折现率计算，在今天约值 0.65 美元。ROI 被高估了。
**解决方法：**对于较长的回本周期（>24 个月），使用 NPV（净现值）对未来现金流折现。
陷阱 10：为声音最大的少数人开发功能
症状：“有 50 位客户提出了这个需求！”（客户总数为 10,000）
**后果：**你把优化重点放在客户群体中的 0.5%，却忽视了其他 99.5%。
**解决方法：**根据收入影响或客户细分群体为功能需求赋权。如果企业客户是你的战略重点，那么 10 个企业客户的权重应高于 100 个 SMB 客户。
参考资料
相关技能
saas-revenue-growth-metrics— 用于影响分析的收入、ARPU、流失率和 NRR 指标saas-economics-efficiency-metrics— ROI、回本周期和贡献毛利率计算finance-metrics-quickref— 公式和基准值速查acquisition-channel-advisor— 用于渠道决策的类似 ROI 框架finance-based-pricing-advisor— 变现功能的定价影响分析
外部框架
- RICE 优先级排序 — 综合考量覆盖范围、影响、信心和投入（本技能增加了财务视角）
- 价值与投入矩阵 — 本技能以财务方式量化“价值”
- Jobs-to-be-Done — 在评估财务影响前了解客户问题
- 机会解决方案树（Teresa Torres） — 在计算 ROI 前梳理机会
来源说明
- 改编自
research/finance/Finance_For_PMs.Putting_It_Together_Synthesis.md（决策框架 #1） - 测验情境来自
research/finance/Finance for Product Managers.md