Frameworks for Analyzing MVP Strategy and Assumption Mapping

Frameworks turn arguments into ranked tests

Founders do not lack ideas. They lack ordering. Every team can brainstorm fifty assumptions after customer discovery. Without frameworks, the loudest voice or the most recent customer complaint sets the roadmap. Frameworks do not eliminate judgment. They force explicit trade-offs so capital and calendar time flow to the beliefs that would kill the venture if wrong.

This lesson covers four tools RelayOps uses after ENT 401: the assumption map, the build-measure-learn loop, ICE prioritization, and pre-mortem analysis. Each tool answers a different question. The assumption map asks what we believe. Build-measure-learn asks how fast we can falsify. ICE asks what to run this sprint. Pre-mortem asks how the test could lie to us.

RelayOps is the anchor venture for ENT 402. It sells B2B (business-to-business, software sold to companies rather than consumers) field-service dispatch and scheduling software to mid-market commercial HVAC (heating, ventilation, and air conditioning) companies with 50 to 150 field technicians. Founders Maya Chen (CEO, former dispatch manager) and Jordan Okonkwo (CTO) completed 28 discovery interviews in ENT 401. Those interviews confirmed that dispatch managers lose roughly 14% of revenue to missed appointments, double-bookings, and slow emergency routing. The beachhead segment is commercial HVAC operators in Phoenix and Dallas. Stated willingness to pay in interviews ranged from $89 to $149 per technician per month for software that reliably solves dispatch chaos.

Maya and Jordan already chose a single-queue emergency MVP in Lesson 1. Frameworks help them defend that choice to investors, sequence experiments across three Phoenix pilots, and notice when a "successful" pilot actually failed a hidden assumption.

Operational vocabulary at RelayOps is measured against Phoenix pilot scorecards, not dictionary completeness. Maya ties each term from this lesson to a field on the weekly dashboard Desert Cool, SunLine, and Valley Air review together. When a dispatch manager says "production ready," the glossary entry lists uptime, silent job drops, and override visibility, not feature parity with ServiceTitan. Jordan links engineering milestones to those same words so pull requests either advance the published RAT or appear on a deferral list with assumption ranks.

Founders should rehearse definitions aloud before customer calls the way finance teams rehearse earnings scripts. If Maya cannot define "live entry" in one sentence with a numeric threshold, dispatchers will not comply consistently. ENT 401 established that mid-market HVAC firms lose roughly 14% of revenue to dispatch chaos; ENT 402 vocabulary explains how MVP tests prove whether RelayOps recovers a measurable slice of that loss without claiming full product-market fit prematurely.

The assumption map (impact vs uncertainty)

An assumption map plots beliefs on two axes: impact if wrong (1 low to 5 catastrophic) and uncertainty (1 evidence-rich to 5 pure guess). Multiply to rank. RelayOps plots ten assumptions from ENT 401. "Dispatch managers control pilot purchases under $10k/month" scores impact 5, uncertainty 4, risk 20. "Technicians prefer native iOS over mobile web" scores impact 3, uncertainty 3, risk 9.

The map is a living document. Each experiment should move one assumption down the uncertainty axis or kill the venture. After Desert Cool pilot week 2, if 78% of emergency jobs run through RelayOps, desirability uncertainty drops from 5 toward 3. If only 30% run through, the map triggers kill criteria rather than a feature sprint.

Teams misuse maps by clustering every dot in the upper-right corner. Not every unknown is high impact. Founders must discipline impact scores: if the assumption is wrong, do we stop the company or defer a nice-to-have? Mobile app parity is uncomfortable if wrong; it is not automatically impact 5 unless mobile is the RAT.

Visual maps also expose dependency chains. Viability assumptions about pricing matter only if desirability passes. RelayOps should not negotiate enterprise pricing frameworks before dispatchers use the console daily.

Board members and pilot customers interpret the same English words through different incentives. Owners hear ROI (return on investment, profit or cost savings compared with spend). Dispatchers hear Tuesday-morning friction. Engineers hear technical debt. RelayOps publishes a single learning agenda so "success" always references emergency dispatch time, usage percentage, and renewal intent together rather than whichever metric flatters one stakeholder today.

Document vocabulary changes in the assumption map version history the same way you version pricing. When RelayOps redefines activation from "first login" to "first completed emergency loop," every cohort chart gets a footnote. Without version discipline, teams compare incompatible retention curves and draw wrong scale decisions heading into Dallas expansion or Unit 3 product-market fit measurement.

Sample RelayOps assumption map excerpt after ENT 401:

Build-measure-learn loop

The build-measure-learn loop (iterate by shipping the smallest test, measuring predefined outcomes, and updating beliefs) is the operational rhythm behind lean startup. Build the smallest artifact that exposes the riskiest assumption to reality. Measure with metrics tied to behavior, not opinions. Learn by updating the assumption map and choosing the next RAT.

RelayOps's loop for month 1: Build emergency queue console and SMS links (5 weeks). Measure median dispatch time, percent of emergency jobs entered live, daily active dispatchers. Learn after 20 jobs per site whether to persevere, iterate onboarding, or pivot wedge feature. The loop fails when teams build for 12 weeks and measure vanity signup counts.

Cycle time is a first-class metric. A loop that takes 90 days to produce one learning is often inferior to a rougher loop that takes 14 days, even if the rough loop feels less impressive in demos. Maya should report loop duration to the board alongside product screenshots.

Each loop iteration needs a written hypothesis: "We believe dispatchers at 50-to-150 tech HVAC firms will route ≥70% of emergency jobs through RelayOps within 30 days because ENT 401 showed 12-minute average delays cost revenue." Falsifiers must be explicit before build starts.

Board members and pilot customers interpret the same English words through different incentives. Owners hear ROI (return on investment, profit or cost savings compared with spend). Dispatchers hear Tuesday-morning friction. Engineers hear technical debt. RelayOps publishes a single learning agenda so "success" always references emergency dispatch time, usage percentage, and renewal intent together rather than whichever metric flatters one stakeholder today.

Document vocabulary changes in the assumption map version history the same way you version pricing. When RelayOps redefines activation from "first login" to "first completed emergency loop," every cohort chart gets a footnote. Without version discipline, teams compare incompatible retention curves and draw wrong scale decisions heading into Dallas expansion or Unit 3 product-market fit measurement.

ICE scoring for experiment backlog

When multiple experiments compete for two engineers, ICE (impact, confidence, ease, a prioritization score where each factor is rated 1 to 10 and multiplied) ranks the backlog. Impact: how much the experiment moves the riskiest assumption if it succeeds. Confidence: how likely the team is to read a clear signal. Ease: inverse of time and cash cost.

RelayOps compares two backlog items. Experiment A: dispatcher shadowing (watch 5 live emergency calls, no code). Experiment B: AI-suggested routing v1. A might score impact 7, confidence 8, ease 9 → ICE 504. B might score impact 6, confidence 4, ease 3 → ICE 72. Shadowing runs first despite less demo appeal.

ICE prevents " exciting build" bias. Engineers gravitate toward technically interesting work. ICE forces the boring ethnography that de-risks adoption. Confidence scores should drop when sample size is tiny or metrics are proxy-based.

Re-score ICE after each loop. An experiment that succeeded on ease but failed on impact should not repeat. If shadowing shows dispatchers never touch keyboards during calls, building routing UI is premature; test voice intake or copy-from-whiteboard flows instead.

Board members and pilot customers interpret the same English words through different incentives. Owners hear ROI (return on investment, profit or cost savings compared with spend). Dispatchers hear Tuesday-morning friction. Engineers hear technical debt. RelayOps publishes a single learning agenda so "success" always references emergency dispatch time, usage percentage, and renewal intent together rather than whichever metric flatters one stakeholder today.

Document vocabulary changes in the assumption map version history the same way you version pricing. When RelayOps redefines activation from "first login" to "first completed emergency loop," every cohort chart gets a footnote. Without version discipline, teams compare incompatible retention curves and draw wrong scale decisions heading into Dallas expansion or Unit 3 product-market fit measurement.

Pre-mortem and decision gates

A pre-mortem asks the team to imagine the experiment failed catastrophically and list reasons. Those reasons become monitoring checks during the pilot. RelayOps pre-mortem for Desert Cool: "Dispatchers secretly kept whiteboard because owner did not mandate change." Mitigation: owner sign-off memo and weekly usage review with named dispatcher champions.

Decision gates are calendar checkpoints with forced choices: persevere, pivot, or stop. Gate 1 at week 4 of pilot: if <60% emergency jobs in system, stop new feature work and run dispatcher interviews. Gate 2 at week 8: if median time >7 minutes, pivot wedge from speed to audit trail value. Gates prevent zombie pilots that consume support hours without learning.

Pre-mortems also catch metric gaming. Dispatchers might batch-enter jobs after emergencies to inflate usage. Mitigation: timestamp comparison between job creation and customer call logs during spot audits.

Document gate outcomes in the assumption map. Investors should see uncertainty scores change because of evidence, not because founders feel optimistic after one friendly email.

Board members and pilot customers interpret the same English words through different incentives. Owners hear ROI (return on investment, profit or cost savings compared with spend). Dispatchers hear Tuesday-morning friction. Engineers hear technical debt. RelayOps publishes a single learning agenda so "success" always references emergency dispatch time, usage percentage, and renewal intent together rather than whichever metric flatters one stakeholder today.

Document vocabulary changes in the assumption map version history the same way you version pricing. When RelayOps redefines activation from "first login" to "first completed emergency loop," every cohort chart gets a footnote. Without version discipline, teams compare incompatible retention curves and draw wrong scale decisions heading into Dallas expansion or Unit 3 product-market fit measurement.

Jordan proposes four pre-build experiments. Team has 2 weeks before coding starts. Rate ICE 1 to 10 each dimension.

Rehearse reconciliation checks at the bottom of every worked example the way accountants foot a ledger. RelayOps examples use technician counts, price per seat, weekly emergency volume, and runway months that must multiply consistently. If 92 technicians at $99 per month times three months does not equal the pilot revenue line in the table, the lesson fails its MBA standard even when the narrative sounds plausible.

Customer discovery from ENT 401 is the anchor evidence layer beneath every term in this lesson. Problem validation justifies why RelayOps exists; MVP vocabulary explains how founders test behavior change without pretending interviews predict Monday-morning whiteboard habits. Keep both layers visible when writing gate memos so investors see a chain from 28 interviews to three paid pilots to renewal arithmetic, not a jump from slides to product-market fit slogans.

Part A: ICE scores

Operational vocabulary at RelayOps is measured against Phoenix pilot scorecards, not dictionary completeness. Maya ties each term from this lesson to a field on the weekly dashboard Desert Cool, SunLine, and Valley Air review together. When a dispatch manager says "production ready," the glossary entry lists uptime, silent job drops, and override visibility, not feature parity with ServiceTitan. Jordan links engineering milestones to those same words so pull requests either advance the published RAT or appear on a deferral list with assumption ranks.

Founders should rehearse definitions aloud before customer calls the way finance teams rehearse earnings scripts. If Maya cannot define "live entry" in one sentence with a numeric threshold, dispatchers will not comply consistently. ENT 401 established that mid-market HVAC firms lose roughly 14% of revenue to dispatch chaos; ENT 402 vocabulary explains how MVP tests prove whether RelayOps recovers a measurable slice of that loss without claiming full product-market fit prematurely.

Part B: Sequencing decision

Run E1 then E2 in parallel if Maya handles concierge while Jordan observes. Defer E4 entirely until adoption assumptions drop uncertainty. E3 optional if sales pipeline is empty; ENT 401 already validated problem intensity, so E3 is lower priority than behavior observation.

Two weeks × $11,250 weekly burn ( $45,000 monthly burn ÷ 4) ≈ $22,500 opportunity cost. E1+E2 cost ~$3,000 travel and founder time. ICE favors $22,500 learning before $90,000 build commitment.

Operational vocabulary at RelayOps is measured against Phoenix pilot scorecards, not dictionary completeness. Maya ties each term from this lesson to a field on the weekly dashboard Desert Cool, SunLine, and Valley Air review together. When a dispatch manager says "production ready," the glossary entry lists uptime, silent job drops, and override visibility, not feature parity with ServiceTitan. Jordan links engineering milestones to those same words so pull requests either advance the published RAT or appear on a deferral list with assumption ranks.

Founders should rehearse definitions aloud before customer calls the way finance teams rehearse earnings scripts. If Maya cannot define "live entry" in one sentence with a numeric threshold, dispatchers will not comply consistently. ENT 401 established that mid-market HVAC firms lose roughly 14% of revenue to dispatch chaos; ENT 402 vocabulary explains how MVP tests prove whether RelayOps recovers a measurable slice of that loss without claiming full product-market fit prematurely.

Part C: Reconciliation

Monthly burn $45,000 → weekly ~$11,250 ✓. ENT 401 MVP build estimate was ~$90,000 for two months in Lesson 1 ✓. E1 highest ICE 576 ✓. If E1 shows dispatchers never use keyboards during calls, RAT shifts to voice or photo intake before any routing code.

Operational vocabulary at RelayOps is measured against Phoenix pilot scorecards, not dictionary completeness. Maya ties each term from this lesson to a field on the weekly dashboard Desert Cool, SunLine, and Valley Air review together. When a dispatch manager says "production ready," the glossary entry lists uptime, silent job drops, and override visibility, not feature parity with ServiceTitan. Jordan links engineering milestones to those same words so pull requests either advance the published RAT or appear on a deferral list with assumption ranks.

Founders should rehearse definitions aloud before customer calls the way finance teams rehearse earnings scripts. If Maya cannot define "live entry" in one sentence with a numeric threshold, dispatchers will not comply consistently. ENT 401 established that mid-market HVAC firms lose roughly 14% of revenue to dispatch chaos; ENT 402 vocabulary explains how MVP tests prove whether RelayOps recovers a measurable slice of that loss without claiming full product-market fit prematurely.

Part D: Managerial read

Investor push: "Skip shadowing; build fast." Response: "Shadowing costs <$5k and can falsify adoption before $90k build. ICE ranks it 16× higher than AI prototype on this backlog."

Board members and pilot customers interpret the same English words through different incentives. Owners hear ROI (return on investment, profit or cost savings compared with spend). Dispatchers hear Tuesday-morning friction. Engineers hear technical debt. RelayOps publishes a single learning agenda so "success" always references emergency dispatch time, usage percentage, and renewal intent together rather than whichever metric flatters one stakeholder today.

Document vocabulary changes in the assumption map version history the same way you version pricing. When RelayOps redefines activation from "first login" to "first completed emergency loop," every cohort chart gets a footnote. Without version discipline, teams compare incompatible retention curves and draw wrong scale decisions heading into Dallas expansion or Unit 3 product-market fit measurement.

FieldSync Pro (fictional) ran a 6-month pilot with one friendly customer. Usage looked healthy because the customer's ops director was a college friend who mandated imports nightly. FieldSync never held a week-4 gate. At rollout to customer two, usage collapsed to 15%. The assumption map still showed desirability uncertainty at 5 because the team never updated scores. RelayOps's gates and pre-mortems force honest map updates when friend-driven usage masks market reality.

Rehearse reconciliation checks at the bottom of every worked example the way accountants foot a ledger. RelayOps examples use technician counts, price per seat, weekly emergency volume, and runway months that must multiply consistently. If 92 technicians at $99 per month times three months does not equal the pilot revenue line in the table, the lesson fails its MBA standard even when the narrative sounds plausible.

Customer discovery from ENT 401 is the anchor evidence layer beneath every term in this lesson. Problem validation justifies why RelayOps exists; MVP vocabulary explains how founders test behavior change without pretending interviews predict Monday-morning whiteboard habits. Keep both layers visible when writing gate memos so investors see a chain from 28 interviews to three paid pilots to renewal arithmetic, not a jump from slides to product-market fit slogans.

RelayOps assumption "owner sign-off required for any software purchase" scores impact 5, uncertainty 5 (risk 25). Maya proposes two tests: (O1) ask 10 ENT 401 interview contacts who controls budget; (O2) offer 3 paid pilots requiring owner signature within 14 days.

Score ICE for O1 (impact 6, confidence 5, ease 9) and O2 (impact 9, confidence 8, ease 5). Which runs first? If O2 yields 2 of 3 signed owner letters in 14 days, how should uncertainty on the assumption map change?

Rehearse reconciliation checks at the bottom of every worked example the way accountants foot a ledger. RelayOps examples use technician counts, price per seat, weekly emergency volume, and runway months that must multiply consistently. If 92 technicians at $99 per month times three months does not equal the pilot revenue line in the table, the lesson fails its MBA standard even when the narrative sounds plausible.

Customer discovery from ENT 401 is the anchor evidence layer beneath every term in this lesson. Problem validation justifies why RelayOps exists; MVP vocabulary explains how founders test behavior change without pretending interviews predict Monday-morning whiteboard habits. Keep both layers visible when writing gate memos so investors see a chain from 28 interviews to three paid pilots to renewal arithmetic, not a jump from slides to product-market fit slogans.

Solution

O1 ICE: 6 × 5 × 9 = 270. O2 ICE: 9 × 8 × 5 = 360. Run O2 first if sales bandwidth allows because higher ICE and tests revealed behavior (signature) not recall.

Two of three owner signatures in 14 days suggests managers alone cannot close; uncertainty drops from 5 toward 2, impact stays 5 (still catastrophic if ignored). Updated risk: 5 × 2 = 10. Next loop: bake owner workflow into pilot contract template.

Check: 2/3 = 67% owner involvement rate, meaningful for sales process design ✓

Operational vocabulary at RelayOps is measured against Phoenix pilot scorecards, not dictionary completeness. Maya ties each term from this lesson to a field on the weekly dashboard Desert Cool, SunLine, and Valley Air review together. When a dispatch manager says "production ready," the glossary entry lists uptime, silent job drops, and override visibility, not feature parity with ServiceTitan. Jordan links engineering milestones to those same words so pull requests either advance the published RAT or appear on a deferral list with assumption ranks.

Founders should rehearse definitions aloud before customer calls the way finance teams rehearse earnings scripts. If Maya cannot define "live entry" in one sentence with a numeric threshold, dispatchers will not comply consistently. ENT 401 established that mid-market HVAC firms lose roughly 14% of revenue to dispatch chaos; ENT 402 vocabulary explains how MVP tests prove whether RelayOps recovers a measurable slice of that loss without claiming full product-market fit prematurely.

Board members and pilot customers interpret the same English words through different incentives. Owners hear ROI (return on investment, profit or cost savings compared with spend). Dispatchers hear Tuesday-morning friction. Engineers hear technical debt. RelayOps publishes a single learning agenda so "success" always references emergency dispatch time, usage percentage, and renewal intent together rather than whichever metric flatters one stakeholder today.

Document vocabulary changes in the assumption map version history the same way you version pricing. When RelayOps redefines activation from "first login" to "first completed emergency loop," every cohort chart gets a footnote. Without version discipline, teams compare incompatible retention curves and draw wrong scale decisions heading into Dallas expansion or Unit 3 product-market fit measurement.

Key takeaways

• Assumption maps rank beliefs by impact times uncertainty, not by recency of customer complaints.
• Build-measure-learn loops succeed when cycle time is short and metrics are behavioral.
• ICE prioritizes experiment backlog using impact, confidence, and ease.
• Pre-mortems and decision gates prevent zombie pilots and metric self-deception.
• Frameworks are living tools; update scores when evidence arrives, not when fundraising starts.

1. Plot five RelayOps assumptions on impact vs uncertainty axes. Which sits furthest top-right?
2. Draft one pre-mortem paragraph for the Desert Cool pilot. What monitoring would you add?
3. Continue to Lesson 4: MVP Strategy and Assumption Mapping: Applied Business Decisions.