Business Model Canvas
By the time you finish six weeks of piloting your AP automation product, you have something most early ventures do not: actual evidence. You know that three companies signed on, that two of them adopted the product within two weeks, and that CFOs used the phrase "audit confidence" unprompted. You have validated assumptions and invalidated others. Now the question becomes: does this add up to a sustainable business?
The Business Model Canvas — developed by Alexander Osterwalder and popularised in Business Model Generation — is the tool for answering that question systematically. It maps nine building blocks that describe how any business creates value, delivers that value, and captures revenue in return. Every successful business can be described through these nine blocks. So can every failing one — the difference is which blocks are validated and which are assumptions waiting to be tested.
In Lesson 7, you completed a Build-Measure-Learn cycle and produced validated learning. In this lesson, you convert that learning into a structured business model. You will map all nine blocks, rate the evidence quality behind each one, stress-test the three most dangerous assumptions, and explore whether an alternative business model configuration might be stronger.
The Nine Blocks: A Structured Map of the Business
The canvas is not a document you create once and file away. It is a living hypothesis map. Every block should be filled with your current best belief — but every belief must be rated for how confident you are in it.
The three evidence quality ratings are:
| Rating | Meaning | Risk Level |
|---|---|---|
| VALIDATED | Customers have paid, adopted, or told you this is true in behaviour | Low — keep defending |
| ANECDOTAL | A few customers or conversations suggest this — but sample size is tiny | Medium — test soon |
| ASSUMED | You believe this but have not tested it | High — test urgently |
An empty block is worse than an ASSUMED block. A gap hides risk; an assumption names it.
The Nine Blocks
1. Customer Segments — Who, specifically, are you building for? Not "SMEs" but "CFOs at manufacturing companies with $5M–$50M revenue who manage AP manually." The more specific the segment, the more precisely you can test it.
2. Value Propositions — What outcome do you deliver, and why can the customer not easily get it elsewhere? The quality standard: specific customer, specific outcome, specific differentiator, evidence it is valued.
3. Channels — How do customers discover you, evaluate your product, buy it, receive value, and stay engaged? Channels are where most early-stage businesses are weakest — three customers from personal outreach is anecdotal evidence of channel effectiveness, not validation.
4. Customer Relationships — How do you manage the relationship today, and how will it need to change as you scale? High-touch onboarding that works at five customers breaks at fifty.
5. Revenue Streams — How does money change hands? What is the pricing model and price point? Is willingness to pay validated by actual payment — or still an assumption?
6. Key Resources — What must you own or control to deliver your value proposition? For an AI-powered product: the AI model, the training dataset, the developer capability. The training dataset is a critical resource that gets more valuable with scale.
7. Key Activities — What must you do continuously to create value and grow? For an early SaaS: product development, AI model improvement, and founder-led sales. The risk is bandwidth — teams at this stage typically cannot do all three well simultaneously.
8. Key Partnerships — Who must you work with to deliver value you cannot build yourself? ERP integrations are a classic example: promising but hypothetical until a vendor signs.
9. Cost Structure — What does it cost to serve one customer per month? Fixed costs (salaries, infrastructure) plus variable costs (per-message API charges, per-invoice AI processing). This feeds directly into your unit economics in Lesson 9.
AP Automation Worked Example — Full Canvas
The AP automation canvas is built post-MVP. The evidence quality reflects what three pilots actually taught us, not what we assumed at the start.
/canvas
Build a Business Model Canvas for my AP automation SaaS venture.
Context: [Paste innov.local.md venture and customer sections]
MVP learnings: [Paste build-measure-learn analysis from L07]
For each canvas block, provide:
- Current hypothesis (what we believe now, post-MVP)
- Evidence quality (ASSUMED/ANECDOTAL/VALIDATED)
- Biggest risk in this block
- One question we still need to answer
Sample output — the AP automation canvas:
BUSINESS MODEL CANVAS — AP Automation SaaS
Version: 1.2 (post-MVP) | Date: [Date]
════════════════════════════════════════════════════════════
1. CUSTOMER SEGMENTS
Primary: CFOs at mid-market companies ($5M–$50M revenue)
Validated: 3 pilots signed; 2 at full price
Secondary: CEO/Founder-led SMEs ($1M–$5M) — emerging from pilot data
(Pilot 3 customer was smaller; different buying pattern)
Evidence: PARTIALLY VALIDATED
Risk: The SME segment may require a lower-cost tier — different product
Open Q: At what revenue size does the CFO have independent purchasing authority?
2. VALUE PROPOSITIONS
Primary: "AP audit confidence without AP process disruption"
→ Validated by CFO satisfaction and auditor-confidence quote
Secondary: "Invoice processing in your existing WhatsApp workflow"
→ Validated by adoption rates in Pilots 1 and 2
Evidence: VALIDATED (primary); VALIDATED (secondary)
Risk: VP #2 creates dependency on WhatsApp Business API pricing
Open Q: Is the VP strong enough to displace existing ERP-embedded AP modules?
3. CHANNELS
Current: Founder-led outreach (LinkedIn + warm intros); 2 weeks/deal
Evidence: ANECDOTAL (3 deals from ~40 outreach touchpoints; 7.5% conversion)
Risk: Founder-led sales does not scale; need first non-founder sale
Open Q: Can an inside sales rep achieve same conversion at lower cost?
4. CUSTOMER RELATIONSHIPS
Current: High-touch onboarding (founder personally onboards each pilot)
Weekly WhatsApp check-in with CFO for first 4 weeks
Evidence: VALIDATED (adopted in Pilots 1 and 2; failed in Pilot 3 — different cause)
Risk: High-touch is not scalable beyond 20 customers with current team
Open Q: What is the minimum viable onboarding that produces >70% adoption?
5. REVENUE STREAMS
Primary: SaaS subscription — $500/month (annual: $6,000)
Secondary: $350/month for SME tier (1 pilot)
Evidence: PARTIALLY VALIDATED (2 at $500; 1 at $350; sample too small)
Risk: SME tier creates pricing complexity and potentially lower LTV
Open Q: Can we sustain $500/month at scale? Or will market pressure
drive to $350/month for most customers?
6. KEY RESOURCES
Current: 2 developers, 1 founder-salesperson, Claude API (AI backbone),
WhatsApp Business API account, training dataset (500 invoices)
Critical: Invoice training dataset — needs to grow to >10,000
for 95%+ accuracy on handwritten invoices
Risk: AI accuracy on handwritten invoices (currently 87%) needs improvement
Open Q: How large must training dataset be for 95%+ accuracy?
7. KEY ACTIVITIES
Core: AI model training and improvement; product development; customer success
Growth: Sales outreach; pilot conversion; case study creation
Evidence: CLEAR
Risk: Bandwidth — 2 developers cannot train AI and build V1 simultaneously
Open Q: At what revenue level can we hire a dedicated ML engineer?
8. KEY PARTNERSHIPS
Potential: ERP vendors (SAP, NetSuite, Xero, QuickBooks, ERPNext ecosystem)
WhatsApp Business API providers
Finance professional associations (CPA societies, CFO networks) for distribution
Evidence: HYPOTHETICAL — no partnerships yet
Risk: ERP integration timeline unknown; could block enterprise deals
Open Q: Which ERP partner should we approach first?
9. COST STRUCTURE
Fixed: 2 developer salaries; founder salary (deferred); hosting (AWS)
Variable: WhatsApp API per message; Claude API per invoice processed
Unit cost: ~$8/customer/month (at current volume)
Margin: $492/customer/month contribution at $500 pricing
Evidence: ESTIMATED (based on 3 pilots; needs larger sample)
Risk: WhatsApp API cost could increase; AI API cost at scale TBD
Open Q: What does unit cost look like at 100 customers vs. 1,000?
CANVAS HEALTH SUMMARY:
Validated blocks: Value Propositions, Customer Relationships
Partially validated: Customer Segments, Revenue Streams, Cost Structure
Hypothetical (build risk): Channels, Key Partnerships
Critical gaps: Channels (scalability), Partnerships (ERP integration)
════════════════════════════════════════════════════════════
The health summary tells you where to invest attention next. The AP automation canvas has two validated blocks — strong foundations. But Channels and Key Partnerships are entirely hypothetical. If you are planning to scale through ERP partnerships, and no ERP partnership has been tested, that is the highest-priority assumption to test before raising money.
Stress-Testing the Canvas
A canvas without adversarial stress-testing is optimistic thinking dressed as strategy. You need to ask: what happens to this business model if one of our key assumptions is wrong?
The most useful stress-tests target your HYPOTHETICAL and PARTIALLY VALIDATED blocks — not the validated ones. If a scenario attacks something already validated, you have a mitigation plan. If it attacks an assumption you have never tested, that is the risk that matters.
/canvas
Stress-test my business model canvas with three adversarial scenarios:
1. WhatsApp announces it will discontinue the Business API across our target market.
2. A large ERP vendor (e.g. SAP, Oracle) launches a competing AP module at $200/month.
3. Our two developers both resign at Month 6.
For each scenario: impact assessment + mitigation + survival probability.
What a strong stress-test output includes:
For each scenario: which canvas blocks are affected, how severely, what the mitigation requires, and an honest survival probability assessment. The WhatsApp scenario is existential for Value Proposition #2 (WhatsApp-native approvals) but does not invalidate Value Proposition #1 (audit confidence) — the product could survive if it can migrate to an alternative approval channel before the API shuts down. The ERP competitor scenario attacks both the Channel and Value Proposition blocks simultaneously — that is the scenario worth planning for most carefully.
The specific scenarios above are the AP automation examples. For your own venture, design scenarios that attack your most hypothetical blocks — not the ones you feel comfortable about. If you feel uncomfortable designing the scenario, that discomfort is telling you something.
Alternative Business Model Exploration
Before committing to a single canvas, it is worth asking whether a structurally different business model might be stronger. The goal is not to change course — it is to understand what your primary model's trade-offs are by contrast with alternatives.
/canvas
Generate 3 alternative business model configurations for the same
AP automation product. For example:
- What if we charged per invoice processed instead of monthly SaaS?
- What if we gave the product free and charged for analytics + audit reports?
- What if we sold to finance professionals (accountants, auditors) instead of companies?
For each alternative: what does the canvas look like?
What is the biggest advantage vs. our primary model?
What is the fatal flaw?
Three structural patterns to explore for any B2B SaaS:
| Alternative | Biggest Advantage | Fatal Flaw |
|---|---|---|
| Usage-based pricing | Aligns cost with value; low barrier to entry | Revenue unpredictable; customers optimise usage rather than adopt fully |
| Freemium + analytics | Lower CAC; large user base for data moat | Free users rarely convert; analytics requires larger team to maintain |
| Sell to accountants | Accountants reach many companies; distribution multiplier | Different ICP; price anchoring is lower; product may need redesign |
After exploring alternatives, return to your primary model with explicit reasoning: "We are choosing SaaS subscription because the recurring revenue predictability matters more than the lower barrier of usage-based pricing at this stage — and our unit economics work at $500/month."
If you are innovating inside an existing organisation, the canvas looks different in several blocks. Customer Segments may be internal teams, not external buyers. Revenue Streams may be cost savings or efficiency gains measured in time or headcount, not subscription fees. Key Partnerships are other departments rather than external vendors. The framework still works — translate the business language to your organisational context. "What value do we create?" and "What does it cost to deliver that value?" are questions every internal innovation project must answer.
Exercise: BMC Build
Type: Business Model Design Time: 90 minutes Goal: Build a complete, validated Business Model Canvas for your venture from Exercise 3 (Lean Startup), stress-test the most fragile blocks, and explore alternative configurations
From prior exercises you have: a customer discovery synthesis (L03), a selected idea (L04), a validated assumption map (L05), an MVP design (L06), and pilot learnings (L07). This exercise integrates those outputs into a complete canvas.
Step 1 — First-draft canvas (20 minutes).
/canvas
Build a Business Model Canvas for:
Venture: [Your idea from Exercises 1–3]
Target customer: [From Exercise 2 — your discovery data]
Solution: [From Exercise 3 — your validated approach]
For each of the 9 blocks, provide:
- Your hypothesis (what you believe now)
- Evidence quality (ASSUMED / ANECDOTAL / VALIDATED)
- Biggest assumption in this block
- One question you still need to answer
After the first draft: check the health summary. Which blocks are hypothetical? Those are the blocks that carry the most risk.
Step 2 — Canvas stress-test (20 minutes).
Design three adversarial scenarios that target your most hypothetical blocks. If your Key Partnerships block is hypothetical, one scenario should test: what if the partnership never materialises? If your Channel block is anecdotal, test: what if your conversion rate is half of your assumption?
/canvas
Stress-test each block of my Business Model Canvas with
one adversarial question. Then answer each question with
the strongest possible counter-argument.
Step 3 — Alternative business model exploration (20 minutes).
/canvas
Generate 3 alternative business model configurations for
the same product/solution. For example:
- What if we charged per transaction instead of monthly SaaS?
- What if we gave the product free and charged for analytics?
- What if we sold to [different buyer] instead of [current target]?
For each alternative: what does the canvas look like?
What is the biggest advantage vs. our primary model?
What is the fatal flaw?
Step 4 — Revenue model design (30 minutes).
/canvas
Design the full revenue model for my chosen canvas:
- Primary revenue stream: [Pricing model + price point justification]
- Secondary revenue stream (if any)
- Unit economics: estimate CAC, LTV, payback period
- Breakeven calculation
- What I need to validate about the revenue model in the next 30 days
Deliverable: Complete Business Model Canvas with evidence quality ratings, canvas health summary, stress-test with three adversarial scenarios, three alternative models with trade-off analysis, and revenue model with unit economics. Save this deliverable — Lesson 9 builds directly on your Revenue Streams and Cost Structure blocks.
Your complete canvas is the input for Exercise 5 (Unit Economics, Lesson 9). Keep it in your Cowork session — Lesson 9 will take your Revenue Streams and Cost Structure blocks and model whether they actually work.
Try With AI
Use these prompts in Cowork or your preferred AI assistant.
Reproduce — Run the chapter's worked example:
/canvas
Build a Business Model Canvas for AP automation SaaS (post-pilot).
Context:
- Product: WhatsApp-native AP approval workflow with AI invoice matching
- Customer: CFOs, mid-market companies $5M–$50M revenue
- Traction: 3 paying pilots; 2 fully adopted; $500/month pricing tested
For each of the 9 blocks: hypothesis, evidence quality
(ASSUMED/ANECDOTAL/VALIDATED), biggest risk, one open question.
End with a canvas health summary.
What you are learning: The evidence quality rating is the most important part — a canvas block filled with an ASSUMED hypothesis is a hidden risk. The health summary converts nine isolated blocks into a prioritised risk register.
Adapt — Modify for a different context:
/canvas
Build a Business Model Canvas for a B2B SaaS product that helps
[choose a business problem you know well: e.g. HR onboarding,
inventory management, or customer support triage].
Target customer: [the specific person who would buy it]
Stage: post-discovery (you have spoken to customers but not yet built)
For each block: hypothesis, evidence quality, biggest risk, open question.
Note: the Channel and Revenue Streams blocks are likely ASSUMED at this stage.
What you are learning: At pre-product stage, most blocks will be ASSUMED. That is expected and honest. The canvas tells you which assumptions to test first — start with the blocks that are both most uncertain and most consequential if wrong.
Apply — Use your own venture data:
/canvas
Build a Business Model Canvas for my venture.
[Paste your innov.local.md or describe your venture context:
customer segments, value proposition, what you have validated so far]
After building the canvas: produce a health summary and identify
the three most important assumptions I should test in the next 30 days.
What you are learning: The three most important assumptions to test are the ones in your most hypothetical blocks that are also most consequential to the viability of the business. Building the canvas forces you to name them.
Flashcards Study Aid
Continue to Lesson 9: Unit Economics and Financial Modelling →