Back to Details

feature-investment-advisor

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Purpose

目的

Guide product managers through evaluating whether to build a feature based on financial impact analysis. Use this to make data-driven prioritization decisions by assessing revenue connection (direct or indirect), cost structure (dev + COGS + OpEx), ROI calculation, and strategic value—then deliver actionable build/don't build recommendations with supporting math.
This is not a generic prioritization framework—it's a financial lens for feature decisions that complements other prioritization methods (RICE, value vs. effort, user research). Use when financial impact is a key decision factor.
指导产品经理通过财务影响分析评估是否开发某一功能。通过评估收入关联（直接或间接）、成本结构（开发成本+COGS+OpEx）、ROI计算及战略价值，做出基于数据的优先级决策，最终给出可执行的“开发/不开发”建议并附上支撑数据。
这不是通用的优先级框架——它是针对功能决策的财务视角，可补充其他优先级方法（RICE、价值vs.投入、用户研究）。当财务影响是关键决策因素时使用本框架。

Key Concepts

核心概念

The Feature Investment Framework

功能投资框架

A systematic approach to evaluate features financially:
  1. Revenue Connection — How does this feature impact revenue?
    • Direct monetization (new tier, add-on, usage charges)
    • Indirect monetization (retention, conversion, expansion enablement)
  2. Cost Structure — What does it cost to build and run?
    • Development cost (one-time investment)
    • COGS impact (ongoing infrastructure, processing)
    • OpEx impact (ongoing support, maintenance)
  3. ROI Calculation — Is the return worth the investment?
    • Direct monetization: Revenue impact / Development cost
    • Retention features: LTV impact across customer base / Development cost
    • Factor in gross margin, not just revenue
  4. Strategic Value — Non-financial value that might override pure ROI
    • Competitive moat (prevents churn to competitor)
    • Platform enabler (unlocks future features)
    • Market positioning (needed for enterprise deals)
    • Risk reduction (compliance, security)
一种系统化的功能财务评估方法：
  1. 收入关联 — 该功能如何影响收入？
    • 直接变现（新定价层级、附加组件、使用收费）
    • 间接变现（留存、转化、促成扩容）
  2. 成本结构 — 开发和运行该功能的成本是多少？
    • 开发成本（一次性投入）
    • COGS影响（持续的基础设施、处理成本）
    • OpEx影响（持续的支持、维护成本）
  3. ROI计算 — 回报是否值得投入？
    • 直接变现：收入影响 / 开发成本
    • 留存类功能：客户群体的LTV影响 / 开发成本
    • 需考虑毛利率，而非仅收入
  4. 战略价值 — 可能超越纯ROI的非财务价值
    • 竞争壁垒（防止客户流失到竞品）
    • 平台赋能（解锁未来功能）
    • 市场定位（大型企业客户交易所需）
    • 风险降低（合规、安全）

Anti-Patterns (What This Is NOT)

反模式（本框架不适用的场景）

  • Not feature scoring alone: Combines financial analysis with strategic judgment
  • Not revenue-only thinking: Considers margins, costs, and ROI, not just top-line revenue
  • Not ignoring retention: Indirect revenue impact (churn reduction) is equally valid
  • Not building without validation: Assumes you've done discovery; this is the financial lens
  • 并非仅功能评分：结合财务分析与战略判断
  • 非唯收入论：考虑利润率、成本和ROI，而非仅营收总额
  • 不忽略留存：间接收入影响（减少流失）同样重要
  • 不盲目开发：假设已完成用户探索，本框架仅提供财务视角

When to Use This Framework

何时使用本框架

Use this when:
  • Prioritizing between features with quantifiable revenue/retention impact
  • Evaluating expensive features (>1 engineer-month of work)
  • Making build/buy/partner decisions
  • Defending feature prioritization to stakeholders or leadership
  • Choosing between direct monetization (add-on) vs. indirect (retention)
Don't use this when:
  • Feature is table stakes (must-have for competitive parity)
  • Impact is purely qualitative (brand, UX delight without measurable retention effect)
  • You haven't validated the problem (do discovery first)
  • Feature is < 1 week of work (just build it)
适用场景：
  • 在具有可量化收入/留存影响的功能间做优先级排序
  • 评估高成本功能（需投入超过1人月的开发工作量）
  • 做出“开发/采购/合作”决策
  • 向利益相关者或管理层论证功能优先级
  • 在直接变现（附加组件）与间接变现（留存）间做选择
不适用场景：
  • 功能是必备门槛（为保持竞争力必须拥有）
  • 影响纯定性（品牌、用户体验愉悦但无可衡量的留存效果）
  • 尚未验证问题（先做用户探索）
  • 功能开发周期<1周（直接开发即可）

Facilitation Source of Truth

引导执行的基准规范

Use 
workshop-facilitation
 as the default interaction protocol for this skill.
It defines:
  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include 
    Other (specify)
    when useful)
This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.
使用
workshop-facilitation
作为本技能的默认交互协议。
它定义了：
  • 会议预告+参与模式（引导式、上下文导入式、最佳猜测式）
  • 单轮提问制，使用平实语言提示
  • 进度标签（例如，上下文问题 Qx/8、评分问题 Qx/5）
  • 中断处理与暂停/恢复机制
  • 决策点的编号化建议
  • 常规问题的快速选择编号选项（必要时包含“其他（请说明）”）
本文件定义了领域特定的评估内容。若存在冲突，以本文件的领域逻辑为准。

Application

应用流程

This interactive skill asks up to 4 adaptive questions, offering 3-5 enumerated options at decision points.
本交互式技能会提出最多4个自适应问题，在决策点提供3-5个枚举选项。

Step 0: Gather Context

步骤0：收集上下文信息

Agent asks:
"Let's evaluate the financial impact of this feature investment. Please provide:
Feature description:
  • What's the feature? (1-2 sentences)
  • Target customer segment (SMB, mid-market, enterprise, all)
Current business context:
  • Current MRR/ARR (or customer count if pre-revenue)
  • Current ARPU/ARPA
  • Current monthly churn rate
  • Gross margin %
Constraints:
  • Development cost estimate (team size × time)
  • Any ongoing COGS or OpEx implications?
You can provide estimates if you don't have exact numbers."
Agent提问：
"我们来评估该功能投资的财务影响，请提供以下信息：
功能描述：
  • 该功能是什么？（1-2句话）
  • 目标客户群体（SMB、中大型企业、大型企业、全客户）
当前业务上下文：
  • 当前MRR/ARR（若未盈利则提供客户数量）
  • 当前ARPU/ARPA
  • 当前月度流失率
  • 毛利率%
约束条件：
  • 开发成本估算（团队规模×时间）
  • 是否有持续的COGS或OpEx影响？
你可以提供估算值，若没有准确数据。"

Step 1: Identify Revenue Connection

步骤1：确定收入关联类型

Agent asks:
"How does this feature impact revenue? Choose the option that best describes the revenue connection:
  1. Direct monetization (new revenue stream) — We'll charge for this (new pricing tier, paid add-on, usage-based fee)
  2. Retention improvement (reduce churn) — Addresses key churn reason; keeps customers from leaving
  3. Conversion improvement (trial-to-paid) — Helps convert free/trial users to paid customers
  4. Expansion enabler (upsell/cross-sell) — Creates upsell path or drives usage-based expansion
  5. No direct revenue impact — Table stakes, platform improvement, or strategic value only
Choose a number, or describe a custom revenue connection."
Based on selection, agent adapts:
If 1 (Direct monetization):
  • "What pricing are you considering?"
  • "What % of customers do you expect to adopt this?" (conservative, base, optimistic)
  • Calculate: 
    Potential Monthly Revenue = Customer Base × Adoption Rate × Price
If 2 (Retention improvement):
  • "What % of churn does this feature address?" (e.g., "30% of churned customers cited this gap")
  • "What churn reduction do you expect?" (e.g., "5% → 4% monthly churn")
  • Calculate: 
    LTV Impact = Increase in Customer Lifetime × Customer Base × ARPU × Margin
If 3 (Conversion improvement):
  • "Current trial-to-paid conversion rate?"
  • "Expected conversion lift?" (e.g., "20% → 25% conversion")
  • Calculate: 
    Additional MRR = Trial Users × Conversion Lift × ARPU
If 4 (Expansion enabler):
  • "What expansion opportunity does this create?" (upsell tier, usage growth, add-on)
  • "What % of customers will expand?"
  • Calculate: 
    Expansion MRR = Customer Base × Expansion Rate × ARPU Increase
If 5 (No direct revenue impact):
  • Skip to strategic value assessment
Agent提问：
"该功能如何影响收入？选择最符合的收入关联类型：
  1. 直接变现（新收入流） — 我们将对该功能收费（新定价层级、付费附加组件、基于使用量的费用）
  2. 提升留存（减少流失） — 解决核心流失原因；防止客户离开
  3. 提升转化（免费/试用转付费） — 帮助免费/试用用户转化为付费客户
  4. 促成扩容（向上销售/交叉销售） — 创造向上销售路径或推动基于使用量的扩容
  5. 无直接收入影响 — 必备门槛、平台改进或仅具备战略价值
选择对应编号，或描述自定义的收入关联类型。"
根据选择，Agent会调整后续提问：
若选择1（直接变现）：
  • "你们考虑采用何种定价方式？"
  • "预计有多少比例的客户会使用该功能？"（保守、基准、乐观三种场景）
  • 计算：
    潜在月度收入 = 客户基数 × 采用率 × 价格
若选择2（提升留存）：
  • "该功能能解决多少比例的流失问题？"（例如，"30%的流失客户提到这一缺口"）
  • "预计能降低多少流失率？"（例如，"月度流失率从5%降至4%"）
  • 计算：
    LTV影响 = 客户生命周期延长时长 × 客户基数 × ARPU × 毛利率
若选择3（提升转化）：
  • "当前试用转付费转化率是多少？"
  • "预计转化率提升幅度是多少？"（例如，"从20%提升至25%"）
  • 计算：
    新增MRR = 试用用户数 × 转化率提升幅度 × ARPU
若选择4（促成扩容）：
  • "该功能创造了何种扩容机会？"（向上销售层级、使用量增长、附加组件）
  • "预计有多少比例的客户会进行扩容？"
  • 计算：
    扩容MRR = 客户基数 × 扩容率 × ARPU增长额
若选择5（无直接收入影响）：
  • 直接跳至战略价值评估环节

Step 2: Assess Cost Structure

步骤2：评估成本结构

Agent asks:
"What's the cost structure for this feature?
Development cost (one-time):
  • Team size: ___ engineers
  • Time estimate: ___ weeks/months
  • Estimated dev cost: $___
Ongoing costs (if any):
  • COGS impact: $___ /month (hosting, infrastructure, processing)
  • OpEx impact: $___ /month (support, maintenance)
If no ongoing costs, enter $0."
Agent calculates:
  • One-time investment: Development cost
  • Ongoing monthly cost: COGS + OpEx
  • Contribution margin impact: 
    (Revenue - COGS) / Revenue
Agent flags:
  • If COGS is >20% of projected revenue: "⚠️ This feature significantly dilutes margins"
  • If ongoing costs are high relative to revenue: "⚠️ Consider if this is sustainable"
Agent提问：
"该功能的成本结构是什么？
开发成本（一次性）：
  • 团队规模：___ 名工程师
  • 时间估算：___ 周/月
  • 估算开发成本：$___
持续成本（若有）：
  • COGS影响：$___ /月（托管、基础设施、处理成本）
  • OpEx影响：$___ /月（支持、维护成本）
若无持续成本，填$0。"
Agent会计算：
  • 一次性投入：开发成本
  • 月度持续成本：COGS + OpEx
  • 边际贡献影响：
    (收入 - COGS) / 收入
Agent会标记警告：
  • 若COGS超过预计收入的20%："⚠️ 该功能会显著拉低利润率"
  • 若持续成本相对于收入过高："⚠️ 请考虑其可持续性"

Step 3: Evaluate Constraints and Timing

步骤3：评估约束条件与时间规划

Agent asks:
"What constraints or timing considerations apply?
  1. Time-sensitive competitive threat — Competitor launched this; we're losing deals
  2. Limited budget/team capacity — We can only build one major feature this quarter
  3. Dependencies on other work — Requires platform improvements or other features first
  4. No major constraints — We have capacity and flexibility
Choose a number, or describe your constraints."
Based on selection:
If 1 (Competitive threat):
  • Strategic value increases (churn prevention)
  • Urgency factor in recommendation
If 2 (Limited capacity):
  • Compare ROI against other features in backlog
  • Recommend stack ranking
If 3 (Dependencies):
  • Flag dependency risk
  • Suggest sequencing
If 4 (No constraints):
  • Proceed to recommendations
Agent提问：
"存在哪些约束条件或时间规划考量？
  1. 时效性竞争威胁 — 竞品已推出该功能；我们正在流失客户
  2. 预算/团队产能有限 — 本季度我们只能开发一个重大功能
  3. 依赖其他工作 — 需要先完成平台改进或其他功能
  4. 无重大约束 — 我们有足够产能与灵活性
选择对应编号，或描述你的约束条件。"
根据选择：
若选择1（竞争威胁）：
  • 战略价值提升（防止流失）
  • 建议中纳入紧迫性因素
若选择2（产能有限）：
  • 与待办清单中的其他功能对比ROI
  • 建议进行堆叠排序
若选择3（依赖其他工作）：
  • 标记依赖风险
  • 建议分阶段执行
若选择4（无约束）：
  • 进入建议环节

Step 4: Deliver Recommendations

步骤4：给出建议

Agent synthesizes:
  • Revenue impact (from Step 1)
  • Cost structure (from Step 2)
  • Constraints (from Step 3)
  • ROI calculation
  • Strategic value assessment
Agent offers 3-4 recommendations:
Agent会综合以下信息：
  • 收入影响（来自步骤1）
  • 成本结构（来自步骤2）
  • 约束条件（来自步骤3）
  • ROI计算结果
  • 战略价值评估
Agent会提供3-4条建议：

Recommendation Pattern 1: Strong Financial Case

建议模式1：财务案例强劲

When:
  • ROI >3:1 (direct monetization) or LTV impact >10:1 (retention/expansion)
  • Positive contribution margin
  • No major red flags
Recommendation:
"Build now — Strong financial case
Revenue Impact:
  • [Direct/Indirect revenue impact calculation]
  • Conservative estimate: $___/month
  • Optimistic estimate: $___/month
Cost:
  • Development: $___
  • Ongoing COGS/OpEx: $___/month
  • Net margin impact: ___%
ROI:
  • Year 1 ROI: ___:1
  • Payback period: ___ months
Why this makes sense: [Specific reasoning based on numbers]
Next steps:
  1. Validate pricing/adoption assumptions with customer research
  2. Build MVP to test core value prop
  3. Monitor [specific metric] to measure impact"
适用场景：
  • ROI >3:1（直接变现）或LTV影响 >10:1（留存/扩容）
  • 边际贡献为正
  • 无重大风险信号
建议内容：
"立即开发——财务案例强劲
收入影响：
  • [直接/间接收入影响计算结果]
  • 保守估算：$___/月
  • 乐观估算：$___/月
成本：
  • 开发成本：$___
  • 持续COGS/OpEx：$___/月
  • 净利润影响：___%
ROI：
  • 第1年ROI：___:1
  • 投资回收期：___ 个月
合理性说明： [基于数据的具体理由]
下一步行动：
  1. 通过客户研究验证定价/采用率假设
  2. 开发MVP测试核心价值主张
  3. 监控[特定指标]以衡量影响"

Recommendation Pattern 2: Weak Financial Case, Build Anyway (Strategic)

建议模式2：财务案例薄弱，但仍需开发（战略考量）

When:
  • ROI <2:1 or marginal financial impact
  • But high strategic value (competitive, platform, compliance)
Recommendation:
"Build for strategic reasons (financial case is marginal)
Financial Reality:
  • Revenue impact: $___/month (modest)
  • Development cost: $___
  • ROI: ___:1 (below 3:1 threshold)
Strategic Value:
  • [Competitive moat / Platform enabler / Market requirement]
  • Prevents churn to competitor X
  • Required for enterprise segment (30% of pipeline)
Recommendation: Build, but monitor closely:
  1. Track adoption vs. projections
  2. Measure churn impact (target: reduce churn by ___%)
  3. Re-evaluate after 6 months if adoption is low
Risk: Opportunity cost—other features may have better ROI"
适用场景：
  • ROI <2:1或财务影响微小
  • 但具有高战略价值（竞争、平台、合规）
建议内容：
"出于战略原因开发（财务案例薄弱）
财务现状：
  • 收入影响：$___/月（小幅）
  • 开发成本：$___
  • ROI：___:1（低于3:1阈值）
战略价值：
  • [竞争壁垒 / 平台赋能 / 市场要求]
  • 防止客户流失至竞品X
  • 大型企业客户必备（占销售线索的30%）
建议： 开发，但需密切监控：
  1. 跟踪采用率与预期的偏差
  2. 衡量流失影响（目标：将流失率降低___%）
  3. 若采用率低，6个月后重新评估
风险： 机会成本——其他功能可能具有更高ROI"

Recommendation Pattern 3: Don't Build (Poor ROI)

建议模式3：不开发（ROI不佳）

When:
  • ROI <1:1 (direct monetization) or negative LTV impact
  • Margin-diluting
  • No compelling strategic value
Recommendation:
"Don't build — Financial case doesn't support investment
Why:
  • Revenue impact: $___/month
  • Development cost: $___
  • ROI: ___:1 (below breakeven)
  • Margin impact: Dilutes gross margin from ___% to ___%
Alternative approaches:
  1. Reduce scope — Can we build a simpler version at 50% cost?
  2. Change monetization — Can we charge more or differently?
  3. Deprioritize — Focus on higher-ROI features like [alternative]
What would need to change:
  • If adoption rate increases from ___% to ___%, ROI becomes viable
  • If we can reduce dev cost to $___, payback becomes acceptable"
适用场景：
  • ROI <1:1（直接变现）或LTV影响为负
  • 拉低利润率
  • 无引人注目的战略价值
建议内容：
"不开发——财务案例不支持投资
原因：
  • 收入影响：$___/月
  • 开发成本：$___
  • ROI：___:1（低于盈亏平衡点）
  • 利润率影响：毛利率从___%降至___%
替代方案：
  1. 缩小范围——能否以50%的成本开发简化版本？
  2. 调整变现方式——能否提高定价或改变收费模式？
  3. 降低优先级——聚焦ROI更高的功能，例如[替代功能]
需满足以下条件才可考虑开发：
  • 若采用率从___%提升至___%，ROI将具备可行性
  • 若能将开发成本降至$___，投资回收期将可接受"

Recommendation Pattern 4: Build Later / Need More Data

建议模式4：延后开发 / 需更多数据

When:
  • Assumptions are highly uncertain
  • Revenue impact depends on unvalidated hypotheses
  • Medium strategic value
Recommendation:
"Build later — Validate assumptions first
Current uncertainty:
  • Adoption rate assumption: ___% (needs validation)
  • Churn impact: ___% reduction (hypothesis, not proven)
  • Pricing unknown
What to validate:
  1. Run feature demand survey with 50+ customers
  2. Prototype and test willingness-to-pay
  3. Interview churned customers to confirm this addresses churn reason
Decision criteria:
  • If % of customers say they'd pay $, build
  • If churn interviews confirm this is top 3 reason, build
  • Otherwise, deprioritize
Timeline:
  • Spend 2-4 weeks validating
  • Re-evaluate with real data"
适用场景：
  • 假设高度不确定
  • 收入影响依赖未验证的假设
  • 战略价值中等
建议内容：
"延后开发——先验证假设
当前不确定性：
  • 采用率假设：___%（需验证）
  • 流失影响：___%的降低幅度（仅为假设，未证实）
  • 定价未知
需验证的内容：
  1. 对50+客户开展功能需求调研
  2. 制作原型测试付费意愿
  3. 访谈流失客户，确认该功能能否解决其流失原因
开发决策标准：
  • 若___%的客户表示愿意支付$___，则开发
  • 若流失客户访谈显示这是前3大流失原因，则开发
  • 否则，降低优先级
时间规划：
  • 花费2-4周验证
  • 基于真实数据重新评估"

Step 5: Allow Follow-Up Questions

步骤5：接受后续提问

Agent offers:
"Do you want to:
  1. See the detailed math breakdown
  2. Compare this to another feature
  3. Adjust assumptions (pricing, adoption, cost)
  4. Export recommendation summary
Or, ask any follow-up questions."
Agent can:
  • Show detailed calculations
  • Sensitivity analysis (what if adoption is 2x? 0.5x?)
  • Compare multiple features side-by-side
  • Export summary for stakeholders
Agent会提供选项：
"你希望：
  1. 查看详细的计算过程
  2. 将该功能与其他功能对比
  3. 调整假设（定价、采用率、成本）
  4. 导出建议摘要
或提出任何后续问题。"
Agent可执行以下操作：
  • 展示详细计算
  • 敏感性分析（例如，若采用率翻倍？减半？）
  • 多功能并排对比
  • 导出摘要供利益相关者查看

Examples

示例

See 
examples/
folder for sample conversation flows. Mini examples below:
请查看
examples/
文件夹中的完整对话流程示例。以下是迷你示例：

Example 1: Direct Monetization (Time Tracking Add-On)

示例1：直接变现（时间跟踪附加组件）

User: "We're considering building time tracking as a paid add-on."
Agent: [Gathers context]
User provides:
  • Current: 1,000 customers, $500 ARPU, 80% gross margin
  • Feature: Time tracking add-on, $10/user/month
  • Dev cost: $100K (2 engineers × 3 months)
  • Adoption estimate: 20% of customers
Agent calculates:
  • Customers with 10 users/account avg = 1,000 accounts × 10 users = 10,000 users
  • Adoption: 20% of users = 2,000 users
  • Revenue: 2,000 × $10 = $20K/month = $240K/year
  • Margin: $240K × 80% = $192K gross profit/year
  • ROI: $192K / $100K = 1.92:1 in year 1
  • Payback: $100K / $20K = 5 months
Agent recommends:
"Build now — Positive ROI with fast payback
Revenue Impact: $240K/year (conservative 20% adoption) ROI: 1.92:1 in year 1, 3.8:1 in year 2 Payback: 5 months
Why this works:
  • Fast payback (5 months) means low risk
  • 80% gross margin on add-on revenue
  • 20% adoption is conservative (test willingness-to-pay)
Next steps:
  1. Survey customers: who would pay $10/user for time tracking?
  2. Build MVP with core time tracking only
  3. Beta with 50 customers before broad launch
  4. Track adoption rate vs. 20% target"
用户："我们考虑开发时间跟踪作为付费附加组件。"
Agent：[收集上下文信息]
用户提供：
  • 当前：1000个客户，ARPU为$500，毛利率80%
  • 功能：时间跟踪附加组件，$10/用户/月
  • 开发成本：$100K（2名工程师×3个月）
  • 采用率估算：20%的客户
Agent计算：
  • 平均每个客户有10名用户 = 1000个客户×10名用户 = 10000名用户
  • 采用用户：20%的用户 = 2000名用户
  • 收入：2000×$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%的采用率较为保守（可测试付费意愿）
下一步行动：
  1. 调研客户：谁愿意为时间跟踪支付$10/用户？
  2. 仅开发核心时间跟踪功能的MVP
  3. 先向50个客户进行beta测试，再全面推出
  4. 跟踪采用率是否达到20%的目标"

Example 2: Retention Feature (Data Export)

示例2：留存功能（数据导出）

User: "We're losing customers because they can't export their data easily. Should we build a comprehensive export feature?"
Agent: [Gathers context]
User provides:
  • Current: $2M MRR, 500 customers, $4K ARPA, 5% monthly churn
  • Feature: Full data export (CSV, API, scheduled exports)
  • Dev cost: $150K (3 engineers × 2 months)
  • Churn context: 30% of churned customers cited data export as a reason
Agent calculates:
  • Current annual churn: ~46% (5% monthly compounded)
  • Customers churned annually: 500 × 46% = 230 customers
  • Customers churned due to export issue: 230 × 30% = 69 customers
  • MRR lost: 69 × $4K = $276K MRR lost/year = $3.3M ARR
If feature reduces this by 50%:
  • Churn prevented: 35 customers/year
  • MRR saved: $140K/year
  • LTV impact (assuming 24-month lifetime): $140K × 24 = $3.36M
Agent calculates ROI:
  • Investment: $150K
  • LTV saved: $3.36M (conservative 50% reduction)
  • ROI: $3.36M / $150K = 22.4:1 🚀
Agent recommends:
"Build immediately — Exceptional ROI on retention
Impact:
  • Prevents ~35 customer churns/year
  • Saves $140K MRR annually
  • LTV impact: $3.36M over customer lifetime
  • ROI: 22:1 (exceptional)
Why this is a no-brainer:
  • 30% of churn cites this gap (validated problem)
  • Even if you only prevent 25% (not 50%), ROI is still 11:1
  • Retention improvements compound (reduces future churn too)
Next steps:
  1. Interview churned customers to validate export was primary reason
  2. Build core export (CSV, API) first
  3. Measure churn rate change after launch (target: 5% → 4.5%)
  4. Add scheduled exports if adoption is high"
用户："我们因为客户无法轻松导出数据而流失客户。我们是否应该开发全面的导出功能？"
Agent：[收集上下文信息]
用户提供：
  • 当前：$2M MRR，500个客户，ARPA为$4K，月度流失率5%
  • 功能：完整数据导出（CSV、API、定时导出）
  • 开发成本：$150K（3名工程师×2个月）
  • 流失上下文：30%的流失客户提到数据导出是原因之一
Agent计算：
  • 当前年度流失率：约46%（5%月度流失率复利计算）
  • 年度流失客户数：500×46% = 230个客户
  • 因导出问题流失的客户数：230×30% = 69个客户
  • 流失的MRR：69×$4K = $276K/年 = $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
  • 留存提升会产生复利效应（减少未来流失）
下一步行动：
  1. 访谈流失客户，验证导出是主要原因
  2. 先开发核心导出功能（CSV、API）
  3. 推出后跟踪流失率变化（目标：从5%降至4.5%）
  4. 若采用率高，再添加定时导出功能"

Example 3: Poor ROI Feature (Dark Mode)

示例3：ROI不佳的功能（深色模式）

User: "Users are requesting dark mode. Should we prioritize it?"
Agent: [Gathers context]
User provides:
  • Current: $500K MRR, 2,000 customers, $250 ARPA, 3% monthly churn, 75% gross margin
  • Feature: Full dark mode across product
  • Dev cost: $80K (2 designers + 2 engineers × 1 month)
  • Revenue connection: Indirect—may improve retention slightly
Agent asks: "What evidence do you have that dark mode will reduce churn?"
User: "Feature requests from 50 users. No data on churn impact."
Agent calculates:
  • 50 feature requests out of 2,000 customers = 2.5% of base
  • No validated churn impact
  • Dev cost: $80K
  • Optimistic scenario: Prevents 5 churns/year (2.5% of base)
  • MRR saved: 5 × $250 = $1,250/month = $15K/year
  • LTV impact (24-month lifetime): $15K × 24 = $360K
ROI: $360K / $80K = 4.5:1 (looks okay, but based on weak assumptions)
Agent recommends:
"Build later — Weak evidence for ROI
Current case:
  • Revenue impact: $15K/year (optimistic)
  • Development cost: $80K
  • ROI: 4.5:1 (assumes dark mode prevents churn)
Problem:
  • Only 50 users requested this (2.5% of base)
  • No evidence dark mode reduces churn
  • Churn interviews don't mention this as a top reason
Alternative approach:
  1. Survey churned customers — Is dark mode in top 5 churn reasons?
  2. Test demand — Ask trial users: "Would dark mode affect your decision to convert?"
  3. Reduce scope — Build basic dark mode (20% cost) as experiment
Better features to consider:
  • If retention is priority: Interview churned customers, find top 3 churn drivers
  • If revenue is priority: Focus on expansion features (upsell, add-ons)
Decision criteria to build:
  • If churn interviews show dark mode is top 3 reason → build
  • If conversion research shows 10%+ impact → build
  • Otherwise → deprioritize"
用户："用户要求添加深色模式。我们是否应该优先开发它？"
Agent：[收集上下文信息]
用户提供：
  • 当前：$500K MRR，2000个客户，ARPA为$250，月度流失率3%，毛利率75%
  • 功能：全产品深色模式
  • 开发成本：$80K（2名设计师+2名工程师×1个月）
  • 收入关联：间接——可能小幅提升留存
Agent提问："你有何证据表明深色模式会降低流失率？"
用户："50个用户提出了该需求。无流失影响数据。"
Agent计算：
  • 50个需求来自2000个客户 = 占客户基数的2.5%
  • 无已验证的流失影响
  • 开发成本：$80K
  • 乐观场景：每年避免5个客户流失（占基数的2.5%）
  • 挽回的MRR：5×$250 = $1250/月 = $15K/年
  • LTV影响（24个月生命周期）：$15K×24 = $360K
ROI: $360K / $80K = 4.5:1（看起来不错，但基于薄弱假设）
Agent建议：
"延后开发——ROI证据薄弱
当前情况：
  • 收入影响：$15K/年（乐观估算）
  • 开发成本：$80K
  • ROI：4.5:1（假设深色模式能防止流失）
问题：
  • 仅50个用户提出需求（占基数的2.5%）
  • 无证据表明深色模式会降低流失率
  • 流失客户访谈未将此列为主要原因
替代方案：
  1. 调研流失客户——深色模式是否为前5大流失原因？
  2. 测试需求——询问试用用户：“深色模式会影响你转为付费用户的决定吗？”
  3. 缩小范围——以20%的成本开发基础深色模式作为实验
更值得优先开发的功能：
  • 若以留存为优先级：访谈流失客户，找出前3大流失驱动因素
  • 若以收入为优先级：聚焦扩容功能（向上销售、附加组件）
开发决策标准：
  • 若流失客户访谈显示深色模式是前3大原因→开发
  • 若转化研究显示影响达10%以上→开发
  • 否则→降低优先级"

Common Pitfalls

常见误区

Pitfall 1: Confusing Revenue with Profit

误区1：混淆收入与利润

Symptom: "This feature will generate $1M in revenue!" (ignoring $800K COGS)
Consequence: $1M revenue at 20% margin is worth $200K profit, not $1M. Feature looks great until you factor in costs.
Fix: Always calculate contribution margin. Use 
Revenue × Margin %
, not just revenue.
表现："该功能将产生$1M收入！"（忽略$800K的COGS） 后果：$1M收入在20%利润率下仅对应$200K利润，而非$1M。未考虑成本时功能看似优秀。 **解决方法：**始终计算边际贡献。使用
收入×利润率%
，而非仅收入。

Pitfall 2: Ignoring Payback Period

误区2：忽略投资回收期

Symptom: "ROI is 5:1, let's build!" (but payback is 36 months and customers churn at 24 months)
Consequence: You never recover the investment because customers leave before payback.
Fix: Check payback period. Must be shorter than average customer lifetime.
表现："ROI为5:1，我们开发吧！"（但投资回收期为36个月，而客户生命周期仅24个月） **后果：**客户在投资回收前就已流失，永远无法收回投入。 **解决方法：**检查投资回收期。必须短于平均客户生命周期。

Pitfall 3: Overestimating Adoption

误区3：高估采用率

Symptom: "100% of customers will use this paid add-on!"
Consequence: Real adoption is 10-20%. Revenue projections are 5-10x too high.
Fix: Use conservative adoption estimates (10-20% for add-ons). Validate with willingness-to-pay research.
表现："100%的客户会使用这个付费附加组件！" **后果：**实际采用率为10-20%。收入预测被高估5-10倍。 **解决方法：**使用保守的采用率估算（附加组件为10-20%）。通过付费意愿研究验证。

Pitfall 4: Building Without Validation

误区4：未验证就开发

Symptom: "We think this will reduce churn" (no customer interviews)
Consequence: You build a feature that doesn't address real churn reasons. Churn stays flat.
Fix: Interview churned customers first. Validate that this feature addresses top 3 churn reasons.
表现："我们认为这会降低流失率"（未做客户访谈） **后果：**开发的功能无法解决真实的流失原因。流失率保持不变。 **解决方法：**先访谈流失客户。验证该功能能否解决前3大流失原因。

Pitfall 5: Ignoring Opportunity Cost

误区5：忽略机会成本

Symptom: "This feature has 2:1 ROI, let's build!" (other features have 10:1 ROI)
Consequence: You build a mediocre feature while better options sit in the backlog.
Fix: Compare ROI across features. Build highest-ROI features first (unless strategic value overrides).
表现："该功能ROI为2:1，我们开发吧！"（其他功能ROI为10:1） **后果：**开发了平庸的功能，而更优的功能被搁置。 **解决方法：**跨功能对比ROI。优先开发ROI最高的功能（除非战略价值超越ROI）。

Pitfall 6: Strategic Value as Excuse

误区6：以战略价值为借口

Symptom: "ROI is terrible but it's strategic!" (no clear strategy)
Consequence: "Strategic" becomes a catch-all for building low-value features.
Fix: Define what "strategic" means (competitive moat, platform enabler, compliance). If it doesn't fit, it's not strategic.
表现："ROI很差，但它具有战略意义！"（无明确战略定义） 后果："战略"成为开发低价值功能的万能借口。 **解决方法：**明确定义"战略"的含义（竞争壁垒、平台赋能、合规）。若不符合，则不具备战略价值。

Pitfall 7: Margin Dilution Blindness

误区7：对利润率稀释视而不见

Symptom: "This feature adds $500K revenue!" (but COGS is $400K)
Consequence: Your gross margin drops from 80% to 60%. Feature destroys unit economics.
Fix: Calculate contribution margin. If margin is <50%, reconsider or charge a premium.
表现："该功能将增加$500K收入！"（但COGS为$400K） **后果：**毛利率从80%降至60%。功能破坏了单位经济效益。 **解决方法：**计算边际贡献。若利润率<50%，重新考虑或提高定价。

Pitfall 8: Celebrating Vanity Metrics

误区8：沉迷虚荣指标

Symptom: "This feature will increase engagement!" (but not revenue or retention)
Consequence: You build features that feel good but don't impact business outcomes.
Fix: Tie features to revenue or retention. Engagement is a leading indicator, not an outcome.
表现："该功能将提升用户活跃度！"（但不影响收入或留存） **后果：**开发的功能看似良好，但不影响业务成果。 **解决方法：**将功能与收入或留存挂钩。活跃度是领先指标，而非业务成果。

Pitfall 9: Forgetting Time Value of Money

误区9：忽略货币的时间价值

Symptom: "This feature pays back in 5 years"
Consequence: $1 in 5 years is worth ~$0.65 today (at 9% discount rate). ROI is overstated.
Fix: For long payback periods (>24 months), use NPV (net present value) to discount future cash flows.
表现："该功能将在5年内收回成本" **后果：**按9%的折现率计算，5年后的$1仅相当于现在的$0.65左右。ROI被高估。 **解决方法：**对于长回收期（>24个月），使用NPV（净现值）折现未来现金流。

Pitfall 10: Building Features for Loud Minorities

误区10：为少数声音开发功能

Symptom: "50 customers requested this!" (out of 10,000)
Consequence: You optimize for 0.5% of your base while ignoring the other 99.5%.
Fix: Weight feature requests by revenue impact or customer segment. 10 enterprise customers > 100 SMB customers if enterprise is your strategy.
表现："50个客户提出了这个需求！"（总客户数为10000） **后果：**为0.5%的客户优化，而忽略了其他99.5%的客户。 **解决方法：**按收入影响或客户群体权重排序需求。若企业客户是战略重点，10个企业客户的需求>100个SMB客户的需求。

References

参考资料

Related Skills

相关技能

  • saas-revenue-growth-metrics
    — Revenue, ARPU, churn, NRR metrics used in impact calculations
  • saas-economics-efficiency-metrics
    — ROI, payback, contribution margin calculations
  • finance-metrics-quickref
    — Quick lookup for formulas and benchmarks
  • acquisition-channel-advisor
    — Similar ROI framework for channel decisions
  • finance-based-pricing-advisor
    — Pricing impact analysis for monetization features
  • saas-revenue-growth-metrics
    ——影响计算中使用的收入、ARPU、流失率、NRR指标
  • saas-economics-efficiency-metrics
    ——ROI、投资回收期、边际贡献计算
  • finance-metrics-quickref
    ——公式与基准的快速查询
  • acquisition-channel-advisor
    ——用于渠道决策的类似ROI框架
  • finance-based-pricing-advisor
    ——变现功能的定价影响分析

External Frameworks

外部框架

  • RICE Prioritization — Combines Reach, Impact, Confidence, Effort (this skill adds financial lens)
  • Value vs. Effort Matrix — This skill quantifies "value" financially
  • Jobs-to-be-Done — Understand customer problems before evaluating financial impact
  • Opportunity Solution Tree (Teresa Torres) — Map opportunities before calculating ROI
  • RICE优先级排序——结合覆盖范围、影响、信心、投入（本技能补充了财务视角）
  • 价值vs.投入矩阵——本技能从财务角度量化"价值"
  • Jobs-to-be-Done——在评估财务影响前理解客户问题
  • 机会解决方案树（Teresa Torres）——在计算ROI前梳理机会

Provenance

来源

  • Adapted from 
    research/finance/Finance_For_PMs.Putting_It_Together_Synthesis.md
    (Decision Framework #1)
  • Quiz scenarios from 
    research/finance/Finance for Product Managers.md
  • 改编自
    research/finance/Finance_For_PMs.Putting_It_Together_Synthesis.md
    （决策框架#1）
  • 测验场景来自
    research/finance/Finance for Product Managers.md