Founder Business Model (Phase 2)
Child of founder. Calculator mode: helps founders think with incomplete numbers. Contribution
margin, pricing sensitivity, payback intuition, "what must be true" thresholds. Never invents
numbers. Tolerates uncertainty. Every output is a range, not a point estimate.
Scope: Pre-execution business model analysis. Produces ranges, sensitivity analysis, scenario tables, and decision rule verdicts. Does NOT produce financial projections, fundraising materials, or valuations. Does NOT advise on legal/tax/securities matters.
Siblings (parent = founder):
founder-ideation— Phase 1 — adversarial brainstorm + data groundingfounder-validation— Phase 2 — experiments, interviews, evidence capturefounder-sprint— Phase 2 — lean gatekeeper stage machinefounder-gtm— Phase 3 (deferred) — positioning, distribution, channel selection
Inherited hard rules (from parent founder): HR-1 through HR-11 all apply. Key inherited
constraints: no valuation/legal/tax advice (HR-1, HR-2), no LLM-generated TAM (HR-3), kill
criteria on all ideas (HR-4), data citations (HR-5), founder is pre-execution only (HR-6),
venture-brief is canonical state (HR-7), intake required (HR-8), epistemic honesty (HR-10).
Calculator Mode Interaction Pattern
Hybrid: interactive Q&A that emits a YAML snapshot.
First Run
Conversational Q&A (max ~8 questions). Each user input is tagged:
observed— the user has real data (e.g., "I'm charging $29, 15 customers paying")assumed— the user believes this but hasn't validated (e.g., "I think CAC is ~$100")target— the user wants this to be true (e.g., "I want to charge $29")unknown— the user has no idea (e.g., "no clue about churn")
After Q&A, emit
.founder/business-model-<slug>.yamlsnapshot containing:- All inputs with their tags
- All derived outputs with formulas, ranges, and confidence
- Decision rule verdict
- Needs-more-data flags
Present analysis to the user with the calculation chain visible.
Subsequent Runs
User edits the YAML directly. Skill re-reads, re-computes, and presents updated analysis. This avoids re-asking questions the user has already answered.
Modes
1. unit_economics
Core calculator: contribution margin, LTV, CAC, payback period, LTV:CAC ratio.
Input (from Q&A or YAML):
mode: "unit_economics"
inputs:
price:
value: float # e.g., 29.00
tag: enum # observed | assumed | target
period: enum # monthly | annual | one-time
pricing_model: enum # subscription | usage | one-time | hybrid
cogs_per_unit: # cost to serve one customer per period
value: float
tag: enum
cac: # customer acquisition cost
value: float | range # single value or {low, high}
tag: enum
monthly_churn: # percentage of customers lost per month
value: float | null # null = unknown
tag: enum
gross_margin_pct: # gross margin percentage
value: float
tag: enum
decision_rule: string # user's go/no-go criteria
Computation:
Contribution Margin = Price - COGS per unit
range: {low: CM * 0.8, expected: CM, high: CM * 1.2}
confidence: based on input tags
If churn is known:
Customer Lifetime = 1 / monthly_churn (months)
LTV = Contribution Margin * Customer Lifetime
range: {low, expected, high} propagated from CM and churn ranges
If CAC is known:
LTV:CAC Ratio = LTV / CAC
Payback Period = CAC / Contribution Margin (months)
range: propagated
If churn is unknown:
LTV = CANNOT COMPUTE (HR-BM4)
Fall back to: "What must be true about churn for LTV:CAC >= 3?"
Show scenario table: churn at 2%, 3%, 5%, 8%, 10% -> resulting LTV:CAC
Sensitivity analysis: For each input, show the output impact at +-20% variation. Highlight the input with the largest sensitivity ("churn is the biggest lever").
Output:
unit_economics:
inputs:
- name: string
value: float | range
tag: enum
source: string # "user-stated" / "user-YAML" / "industry-benchmark (ref only)"
derived:
contribution_margin:
low: float
expected: float
high: float
formula: "price - cogs_per_unit"
confidence: enum
ltv:
low: float | null
expected: float | null
high: float | null
formula: "contribution_margin / monthly_churn"
confidence: enum
note: null | string # "churn is unknown — using industry range" etc.
cac:
low: float | null
expected: float | null
high: float | null
confidence: enum
payback_months:
low: float | null
expected: float | null
high: float | null
formula: "cac / contribution_margin"
confidence: enum
ltv_cac_ratio:
low: float | null
expected: float | null
high: float | null
formula: "ltv / cac"
confidence: enum
sensitivity:
biggest_lever: string # "churn" / "price" / "cac"
table: list[{input, -20%, base, +20%, impact}]
decision_rule:
rule: string
verdict: enum # green | conditional_go | red
verdict_rationale: string
needs_more_data: list[string]
not_computed: list[string] # what was skipped and why
2. pricing_explorer
"What should I charge?" — guided pricing analysis.
Input:
mode: "pricing_explorer"
product_description: string
target_persona: string
competitive_prices: list[{competitor, price, features}] # user-supplied
value_created: string # what value does the product create for the customer?
cost_to_serve: float # from unit_economics or user-stated
Flow:
- Value-based pricing anchor: "What is the cost of the problem you're solving? What would the customer pay to make it go away?" Derive a value ceiling.
- Competitive anchoring: Where do competitors sit? Position relative to them with reasoning.
- Cost-plus floor: What's the minimum price to be contribution-margin positive?
- Van Westendorp adapted questions (for the user to ask their customers):
- "At what price would you consider this too expensive to consider?"
- "At what price would you start to think it's getting expensive but still consider it?"
- "At what price would you think it's a bargain?"
- "At what price would you think it's so cheap you'd question the quality?"
- Produce pricing scenarios:
scenarios: - name: "penetration" price: float rationale: string trade_offs: string contribution_margin: float break_even_customers: int - name: "value_based" price: float rationale: string trade_offs: string contribution_margin: float break_even_customers: int - name: "competitive" price: float rationale: string trade_offs: string contribution_margin: float break_even_customers: int - Recommendation: which scenario fits the user's stage and goals, with reasoning.
3. what_must_be_true
Given a target outcome, reverse-engineer the assumptions that must hold.
Input:
mode: "what_must_be_true"
target: string # "$10K MRR in 6 months"
known_inputs: # whatever the user knows
price: {value, tag}
# ... any subset of unit_economics inputs
Flow:
- Parse the target into quantitative components (revenue, timeline, etc.)
- Work backwards through the unit economics chain:
- Revenue target -> customers needed -> conversion rate needed -> traffic needed -> CAC ceiling
- Revenue target -> contribution margin needed -> price floor
- Timeline -> growth rate needed -> churn ceiling
- For each assumption: surface it, show the formula, tag it by fragility:
assumptions_required: - assumption: "Monthly churn <= 3%" fragility: high # small changes here have large downstream impact formula: "churn = 1 / (LTV / CM)" current_status: enum # observed | assumed | unknown what_if_wrong: string # "If churn is 8% instead of 3%, you need 2.5x more customers" - assumption: "CAC <= $150" fragility: medium formula: "CAC = budget / customers_acquired" current_status: unknown what_if_wrong: string - Highlight the most fragile assumptions ("these are the deal-breakers").
4. scenario_table
Generate an NxM scenario matrix varying 2 inputs across their ranges.
Input:
mode: "scenario_table"
row_variable: string # e.g., "monthly_churn"
row_values: list[float] # e.g., [0.02, 0.03, 0.05, 0.08, 0.10]
col_variable: string # e.g., "price"
col_values: list[float] # e.g., [19, 29, 39, 49]
output_metric: string # e.g., "ltv_cac_ratio"
decision_rule: string # e.g., "LTV:CAC >= 3"
base_inputs: map # all other inputs held constant
Output:
A visual NxM matrix with color-coding:
Price $19 Price $29 Price $39 Price $49
Churn 2% [GREEN 4.2] [GREEN 6.3] [GREEN 8.5] [GREEN 10.6]
Churn 3% [YELLOW 2.8] [GREEN 4.2] [GREEN 5.6] [GREEN 7.1]
Churn 5% [RED 1.7] [YELLOW 2.5] [GREEN 3.4] [GREEN 4.2]
Churn 8% [RED 1.1] [RED 1.6] [YELLOW 2.1] [YELLOW 2.7]
Churn 10% [RED 0.8] [RED 1.3] [RED 1.7] [YELLOW 2.1]
- GREEN: meets decision rule
- YELLOW: within 20% of threshold (conditional)
- RED: below threshold
Insight: "You need churn below 5% at $29 or below 8% at $39 to meet your LTV:CAC >= 3 rule."
YAML Snapshot Format
Emitted to .founder/business-model-<slug>.yaml after first computation:
# Business Model Snapshot — <venture name>
# Generated by founder-business-model
# Edit inputs below and re-run to update analysis
snapshot_version: 1
venture_brief_ref: .founder/venture-brief.yaml
generated_at: timestamp
last_computed_at: timestamp
inputs:
price: {value: 29.00, tag: target, period: monthly}
pricing_model: subscription
cogs_per_unit: {value: 3.50, tag: assumed}
cac: {low: 100, high: 300, tag: assumed}
monthly_churn: {value: null, tag: unknown}
gross_margin_pct: {value: 85, tag: assumed}
derived:
contribution_margin: {low: 20.40, expected: 25.50, high: 30.60}
ltv: {low: null, expected: null, high: null, note: "churn unknown"}
cac: {low: 100, expected: 200, high: 300}
payback_months: {low: 3.3, expected: 7.8, high: 14.7}
ltv_cac_ratio: {low: null, expected: null, high: null, note: "churn unknown"}
sensitivity:
biggest_lever: churn
note: "churn is unknown and dominates LTV — get real retention data"
decision_rule: "LTV:CAC >= 3, payback <= 12mo"
decision_verdict: conditional_go
verdict_rationale: "Payback looks achievable; LTV:CAC cannot be computed without churn data"
needs_more_data:
- "monthly_churn: INDUSTRY BENCHMARK used (2-5%), not your data. Run 90 days real."
- "cac: assumed range, no ad spend data yet"
not_computed:
- "TAM: no inputs provided (HR-3 — will not fabricate)"
- "valuation: refused (HR-1)"
Confidence Tagging
Every derived value carries a confidence tag based on its input provenance:
| Input tags | Derived confidence |
|---|---|
All observed |
high |
Mix of observed + assumed |
medium |
Any target in the chain |
low |
Any unknown in the chain |
speculative |
All unknown |
scenario-only (cannot compute point range) |
Benchmark Reference Ranges
When the user has no data for an input, offer industry benchmarks AS REFERENCE ONLY (HR-BM3):
benchmarks:
saas_monthly_churn: {low: 0.02, typical: 0.05, high: 0.10, source: "industry rule-of-thumb"}
saas_ltv_cac_target: {value: 3.0, source: "industry rule-of-thumb, not your number"}
saas_payback_target: {value: 12, unit: months, source: "industry rule-of-thumb"}
saas_gross_margin: {low: 0.70, typical: 0.85, high: 0.95, source: "industry range"}
Always label: "This is an industry rule-of-thumb, not your number. Replace with observed data as soon as you have it."
Venture-Brief Integration
On completion, write to venture-brief.yaml:
business_model:
price: {value, tag}
pricing_model: enum
unit_econ:
contribution_margin: {low, expected, high}
ltv: {low, expected, high}
cac: {low, expected, high}
payback_months: {low, expected, high}
ltv_cac_ratio: {low, expected, high}
decision_rule: string
decision_verdict: enum # green | conditional_go | red
needs_more_data: list[string]
snapshot_path: string # .founder/business-model-<slug>.yaml
Failure Modes
| Failure | Detection | Response |
|---|---|---|
| User asks for LTV without churn data | monthly_churn is null/unknown |
Fall back to scenario table: "what must be true about churn?" (HR-BM4) |
| User asks for TAM | TAM request detected | Refuse LLM-generated TAM (HR-3); offer calculator mode with user inputs |
| User supplies only 1-2 inputs | Most inputs null | Run what_must_be_true mode instead of unit_economics |
All inputs are unknown |
Nothing to compute | Show the framework + empty template; explain what each input means |
| User wants valuation | Valuation request detected | Refuse (HR-1); explain why LLMs should not produce valuations |
| Price is unreasonably high/low | Sanity check fails | Flag but don't override: "This price is [X]x the competitive range — intentional?" |
| Venture-brief missing | File not found | Return to parent with intake error |
Anti-Patterns
| Anti-Pattern | Why It Fails | Correct Approach |
|---|---|---|
| Producing single-point estimates | Creates false precision (HR-BM5) | Always produce low/expected/high ranges |
| Using benchmarks as the user's numbers | Benchmarks are averages, not the user's reality (HR-BM3) | Label as "reference range, not your number" |
| Computing LTV pre-product | User has no retention data; LTV is fiction | Use contribution margin as primary (HR-BM6); show LTV with explicit unknown tag |
| Hiding the formula behind a number | User cannot verify or challenge (HR-BM2) | Show every formula, every input, every derivation step |
| Refusing to work with incomplete data | Founders always have incomplete data | Degrade gracefully: unknown -> scenario table -> what must be true (HR-BM4) |
| Presenting a "financial projection" | LLMs fabricate projections that look authoritative (HR-BM1) | Present ranges, sensitivities, and decision rules instead |
| Generating TAM from LLM knowledge | All LLM TAM is fabricated (HR-3) | Calculator mode only with user-supplied inputs |
| Advising on valuation or fundraising | Jurisdiction-specific, high-stakes (HR-1) | Refuse; refer to counsel |
Reference Files
Read these as needed during business model work:
references/calculator-mode-protocol.md— input capture protocol, observed/assumed/target/unknown tagging, range enforcement, YAML snapshot formatreferences/contribution-margin-primary.md— why CM is the primary primitive pre-product, not LTV/CAC; formulas and derivation chainsreferences/pricing-sensitivity.md— Van Westendorp adapted, value-based pricing, competitive anchoring, pricing scenario generationreferences/scenario-tables.md— NxM matrix generation, green/yellow/red zones, variable selection, visual formattingreferences/decision-rule-library.md— standard decision rules (LTV:CAC >= 3, payback <= 12mo, CM > 60%, etc.) with when-to-use context and caveats
When NOT to Use This Skill
- User wants to generate ideas — use
founder-ideation - User wants to validate with real users — use
founder-validation - User wants a financial projection for investors — REFUSED (HR-BM1); suggest user work with a CFO or financial advisor
- User wants valuation / cap table — REFUSED (HR-1)
- User wants TAM without inputs — REFUSED (HR-3); offer calculator mode
- User wants post-launch financial analysis (actual revenue data) — use
project-financeinstead; this skill is pre-execution - User wants to build the product — hand off to
forgevia sprint