Feature Investment Advisor

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.

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)

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

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)

---

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.

Application

This interactive skill asks up to 4 adaptive questions, offering 3-5 enumerated options at decision points.

---

Step 0: Gather Context

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."

---

Step 1: Identify Revenue Connection

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

---

Step 2: Assess Cost Structure

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"

---

Step 3: Evaluate Constraints and Timing

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

---

Step 4: Deliver Recommendations

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:

---

Recommendation Pattern 1: Strong Financial Case

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"

---

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

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"

---

Recommendation Pattern 3: Don't Build (Poor 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"

---

Recommendation Pattern 4: Build Later / Need More Data

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"

---

Step 5: Allow Follow-Up Questions

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

---

Examples

See examples/ folder for sample conversation flows. Mini examples below:

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

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"

---

Example 2: Retention Feature (Data Export)

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"

---

Example 3: Poor ROI Feature (Dark Mode)

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"

---

Common Pitfalls

Pitfall 1: Confusing Revenue with Profit

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.

---

Pitfall 2: Ignoring Payback Period

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.

---

Pitfall 3: Overestimating Adoption

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.

---

Pitfall 4: Building Without Validation

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.

---

Pitfall 5: Ignoring Opportunity Cost

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).

---

Pitfall 6: Strategic Value as Excuse

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.

---

Pitfall 7: Margin Dilution Blindness

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.

---

Pitfall 8: Celebrating Vanity Metrics

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

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.

---

Pitfall 10: Building Features for Loud Minorities

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.

---

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

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

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

Example: Feature Investment Advisor Conversation Flow

This shows a full conversation using the feature-investment-advisor skill.

---

Scenario: Evaluating a Time Tracking Add-On

Step 0: Initial Request

User: "Should we build time tracking as a paid add-on to our project management tool?"

---

Step 0: Context Gathering

Agent: "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
• 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."

---

User: "Here's our context:

Feature: Time tracking add-on with start/stop timers, time reports, and invoice export. Target all segments.

Business context:

• MRR: $2M (1,000 customers)
• ARPA: $2,000/month
• ARPU: $200/month (average 10 users per account)
• Monthly churn: 3%
• Gross margin: 80%

Development:

• 2 engineers × 3 months = ~$100K dev cost
• No significant ongoing COGS (minimal compute cost)
• Might add 10-20 support tickets/month"

---

Step 1: Revenue Connection

Agent: "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."

---

User: "1 — Direct monetization. We'll charge $5/user/month as an add-on."

---

Agent: "Got it. You're planning to charge $5/user/month for time tracking.

Follow-up questions:

1. How many users do you have total?

• Current: 1,000 accounts × 10 users/account = 10,000 users

2. What adoption rate do you expect?

• Conservative (10-15%)
• Base case (20-25%)
• Optimistic (30-40%)
• Or provide your own estimate

3. Have you validated willingness-to-pay?

• Surveyed customers
• Prototype tested
• No validation yet"

---

User: "We have 10,000 users total.

I'll go with base case: 20% adoption (2,000 users).

We've surveyed 50 customers and 30% said they'd pay $5-10/user for time tracking, so 20% feels conservative."

---

Agent calculates:

Total Users: 10,000
Adoption Rate: 20%
Users Adopting: 2,000
Price: $5/user/month

Monthly Revenue: 2,000 × $5 = $10,000/month
Annual Revenue: $120,000/year
Gross Profit: $120,000 × 80% = $96,000/year

Agent: "Great! Based on 20% adoption at $5/user:

Revenue Impact:

• Monthly: $10,000 MRR
• Annual: $120,000 ARR
• Gross profit (80% margin): $96,000/year

Now let's look at costs."

---

Step 2: Cost Structure

Agent: "You mentioned:

• Dev cost: $100K (2 engineers × 3 months)
• COGS: Minimal
• Support: 10-20 tickets/month

Let me confirm the full cost picture:

One-time development: $100,000

Ongoing monthly costs:

• COGS (compute, storage): $___
• Support (est. 15 tickets/month × $50/ticket): $750/month = $9K/year
• Total ongoing: $9K/year

Does this look right?"

---

User: "Yes, that's right. COGS is negligible (maybe $100/month for compute), and support is probably $750/month."

---

Agent calculates:

Development Cost (one-time): $100,000

Ongoing Annual Costs:
- COGS: $100/month × 12 = $1,200/year
- Support: $750/month × 12 = $9,000/year
- Total: $10,200/year

Net Annual Profit:
$120,000 revenue - $10,200 ongoing costs = $109,800/year gross profit
After initial dev cost recovery: $109,800 - $100,000 = $9,800 in year 1

Agent: "Got it. Here's the cost structure:

Costs:

• One-time dev: $100,000
• Ongoing: $10,200/year (COGS + support)

Net Impact:

• Year 1: $109,800 revenue - $100,000 dev - $10,200 ongoing = -$200 (essentially breakeven)
• Year 2+: $109,800/year profit (no dev cost)

Payback Period: ~11 months"

---

Step 3: Constraints

Agent: "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."

---

User: "2 — We can only build one major feature this quarter. We're also considering a Gantt chart view (similar dev cost, but no monetization—retention play)."

---

Agent: "Got it. You're choosing between:

• Time tracking (direct monetization, $120K ARR)
• Gantt chart (retention/competitive feature, indirect impact)

Let me calculate the trade-off to help you decide."

---

Step 4: Recommendation

Agent: "Based on your inputs, here's my analysis and recommendation:

---

✅ Recommendation: Build Time Tracking Now

Financial Case: Strong

Revenue Impact:

• $10K MRR / $120K ARR
• 2,000 users × $5/user (20% adoption)
• Gross margin: 80%
• Net annual profit: $109,800 (after ongoing costs)

Costs:

• Development: $100,000 (one-time)
• Ongoing: $10,200/year (COGS + support)

ROI:

• Year 1: Essentially breakeven (-$200)
• Year 2: 2.2:1 ROI ($109,800 profit / $100K investment)
• Payback: 11 months

Contribution Margin:

• Revenue: $120K/year
• Variable costs: $10.2K/year
• Contribution margin: 91.5% (excellent)

---

Why This Makes Sense

1. Fast payback (11 months)

• You recover the investment in under a year
• Low risk—if adoption is even 15% (not 20%), still profitable

2. High-margin revenue

• 80% gross margin on add-on revenue
• Minimal ongoing costs (only $10K/year)
• Scales well (more users = more revenue, same cost)

3. Validated demand

• 30% of surveyed customers said they'd pay $5-10/user
• 20% adoption is conservative

4. Direct revenue > indirect retention (vs. Gantt chart)

• Gantt chart = retention play (indirect, hard to measure)
• Time tracking = direct revenue (measurable, predictable)
• If you can only build one: choose measurable revenue

---

Comparison: Time Tracking vs. Gantt Chart

Verdict: Time tracking has clearer ROI. Build it first.

BUT: If churn interviews show Gantt charts are a top 3 churn reason, reconsider.

---

Next Steps

1. Build MVP (Weeks 1-8)

• Core time tracking (start/stop timers)
• Time reports (basic)
• Delay invoice export to v2 if scope is tight

2. Beta Test (Weeks 9-10)

• Launch to 50-100 customers
• Validate $5/user pricing
• Measure adoption (target: 20%+)

3. Broad Launch (Week 11)

• If beta adoption is >15%, launch broadly
• If <15%, adjust pricing or positioning

4. Monitor Metrics (Ongoing)

• Track adoption rate weekly (target: 20%)
• Monitor support load (should stay <20 tickets/month)
• Measure MRR growth from add-on

5. Re-evaluate Gantt Chart (Q2)

• If time tracking hits 20% adoption: build Gantt next
• If adoption is low: investigate why before building more features

---

Decision Criteria to Proceed

Build if:

• Beta adoption >15%
• Support load manageable (<30 tickets/month)
• Pricing validated ($5/user is acceptable)

Pause/pivot if:

• Beta adoption <10% (pricing too high or low demand)
• Support costs >$2K/month (unsustainable)
• Churn increases (feature causes confusion)

---

Sensitivity Analysis (What If?)

If adoption is 15% (not 20%):

• Revenue: $90K/year
• Payback: 14 months (still acceptable)
• ROI: 1.6:1 in year 2 (still positive)

If adoption is 30% (optimistic):

• Revenue: $180K/year
• Payback: 7 months (excellent)
• ROI: 3.6:1 in year 2 (very strong)

If you can reduce dev cost to $75K:

• Payback: 8 months (great)
• ROI: 2.9:1 in year 2

Bottom line: Even conservative scenarios are profitable. Build it.

---

Want to explore further?

1. See detailed math breakdown 2. Compare to Gantt chart (if you have churn data) 3. Adjust assumptions (pricing, adoption, cost) 4. Export this recommendation (for stakeholder review)"

---

User: "This is super helpful. Can you show me the detailed math?"

---

Agent: "Sure! Here's the full financial breakdown:

Detailed Calculations

Revenue:

Total Users: 10,000
Adoption Rate: 20%
Users Adopting: 10,000 × 20% = 2,000 users

Price per User: $5/month
Monthly Revenue: 2,000 × $5 = $10,000 MRR
Annual Revenue: $10,000 × 12 = $120,000 ARR

Costs:

Development (one-time):
  2 engineers × 3 months × $16,667/eng-month = $100,000

Ongoing Monthly Costs:
  COGS (compute): $100/month
  Support: 15 tickets/month × $50/ticket = $750/month
  Total: $850/month

Ongoing Annual Costs:
  $850 × 12 = $10,200/year

Profit:

Gross Margin: 80%
Gross Profit (Annual): $120,000 × 80% = $96,000/year

After Ongoing Costs:
  $120,000 revenue - $10,200 costs = $109,800 net profit/year

Year 1 (with dev cost):
  $109,800 - $100,000 dev = $9,800 net profit

Year 2+ (no dev cost):
  $109,800 net profit/year

ROI:

Year 1 ROI:
  $9,800 profit / $100,000 investment = 0.098:1 (basically breakeven)

Year 2 ROI:
  $109,800 profit / $100,000 investment = 1.098:1

Cumulative 2-Year Profit:
  Year 1: $9,800
  Year 2: $109,800
  Total: $119,600 profit on $100K investment = 2.2:1 ROI

Payback Period:

Monthly net profit = $109,800 / 12 = $9,150/month

Payback = $100,000 / $9,150 = 10.9 months (11 months)

Contribution Margin:

Revenue: $120,000/year
Variable Costs: $10,200/year (COGS + support)
Contribution Profit: $109,800/year
Contribution Margin: $109,800 / $120,000 = 91.5%

Does this breakdown help?"

---

User: "Yes! One more question: what if we charge $10/user instead of $5/user?"

---

Agent: "Great question! Let's recalculate at $10/user:

Scenario: $10/user (double the price)

Assumptions:

• Higher price likely reduces adoption
• Conservative: 15% adoption (down from 20%)
• Optimistic: 20% adoption (same as $5/user base case)

Conservative (15% adoption at $10/user):

Users: 10,000 × 15% = 1,500 users
Revenue: 1,500 × $10 = $15,000 MRR = $180,000 ARR
Net Profit: $180,000 - $10,200 = $169,800/year
Year 1 Profit: $169,800 - $100,000 = $69,800
Payback: 7 months
ROI (Year 2): 2.7:1

Optimistic (20% adoption at $10/user):

Users: 10,000 × 20% = 2,000 users
Revenue: 2,000 × $10 = $20,000 MRR = $240,000 ARR
Net Profit: $240,000 - $10,200 = $229,800/year
Year 1 Profit: $229,800 - $100,000 = $129,800
Payback: 5 months
ROI (Year 2): 3.3:1

Recommendation on Pricing

$10/user is better IF:

• Adoption stays >15% (survey data shows 30% would pay $5-10, so likely yes)
• Higher ARPU, same/similar adoption = better unit economics
• Faster payback (5-7 months vs. 11 months)

Test Approach: 1. Launch beta at $10/user with 50 customers 2. If adoption >15%, keep $10/user 3. If adoption <10%, drop to $7/user or $5/user

My recommendation: Start at $10/user. Easier to lower price than raise it later."

---

User: "Perfect. I'm convinced. Let's build time tracking at $10/user."

---

Agent: "Excellent decision! Here's a summary you can share with stakeholders:

---

Feature Investment Decision: Time Tracking Add-On

Decision: ✅ Build now (Q1 priority)

Pricing: $10/user/month (test in beta, adjust if needed)

Target: 15-20% adoption (1,500-2,000 users)

Financial Projections:

• Year 1 Revenue: $180-240K ARR
• Year 1 Net Profit: $70-130K (after $100K dev cost)
• Payback: 5-7 months
• Year 2 ROI: 2.7-3.3:1

Next Steps: 1. Kickoff: Week 1 (2 engineers, 3 months) 2. Beta launch: Week 10 (50-100 customers, validate $10/user pricing) 3. Broad launch: Week 12 (if beta adoption >15%) 4. Monitor: Track adoption weekly, support load, MRR growth

Success Criteria:

• Adoption >15% within 3 months of launch
• Support <30 tickets/month
• $15K+ MRR within 6 months

Good luck with the build! 🚀

---

Want me to create a feature brief or PRD template for this?"

---

User: "No, that's all I needed. Thanks!"

Agent: "You're welcome! Good luck building time tracking. Feel free to come back if you need to evaluate other features."