MVP Strategy and Assumption Mapping: Applied Business Decisions

Maps and frameworks only matter at decision time

Assumption maps on a wall do not save runway. Decisions do: which customer to pilot with, how much to charge, what to defer, when to stop. Applied MVP strategy is the discipline of converting ENT 401 discovery into signed pilot terms, engineering sprints, and board-ready kill or persevere calls.

RelayOps enters this lesson with ranked assumptions, shared vocabulary, and ICE-scored experiments. Now Maya must choose among three Phoenix HVAC prospects, allocate $90,000 of build budget, and set contract language that preserves learning if the product fails.

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.

This lesson walks through decision memos founders actually write: scope memos, pilot term sheets, runway checks, and pivot triggers. You should finish able to defend a MVP scope choice to an skeptical owner who already lost money on software that "never got used."

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.

Pilot selection as a filtering decision

Not every friendly interviewee makes a good pilot customer. Ideal pilots sit in the beachhead segment, feel acute pain, have operational discipline to measure baseline dispatch time, and accept bounded scope. RelayOps filters Phoenix prospects: 50 to 150 technicians, commercial HVAC (not residential only), dispatch manager with daily emergency volume, owner willing to sign a 90-day pilot with kill criteria.

Avoid "innovation theater" accounts: ops directors who love demos but will not enforce dispatcher behavior change. Avoid accounts so distressed they cannot spare 30 minutes weekly for data review. Avoid accounts planning ERP migration in 60 days that will blame RelayOps for any friction.

Scoring pilots on learning quality beats scoring on logo prestige. A 65-tech firm with honest dispatchers and 12-minute baseline teaches more than a 140-tech firm whose champion hides whiteboard usage.

RelayOps targets three pilots staggered by two weeks so engineering fixes from pilot one deploy before pilot three starts. Parallel pilots without stagger duplicate the same bugs and waste support capacity.

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.

Pilot selection scorecard for RelayOps:

Desert Cool ranks higher despite smaller size because baseline tracking and owner sign-off reduce experiment noise.

Scope memos and deferral decisions

A scope memo is a one-page internal document listing in-scope jobs, out-of-scope jobs, success metrics, and deferral rationale. RelayOps in-scope: emergency job intake, technician SMS confirmation, manual override, dispatch time logging. Out-of-scope: preventive maintenance scheduling, invoicing, QuickBooks sync, native mobile apps, AI routing.

Each deferral ties to an assumption rank. QuickBooks sync deferred because feasibility risk 12 is lower than desirability risk 25. AI routing deferred because it does not falsify adoption if dispatchers ignore the console entirely.

Scope memos prevent "just one more feature" during pilots. When Desert Cool asks for customer history panels, Maya cites the memo and offers post-pilot roadmap review if success metrics hit.

External scope memos become pilot exhibits. Customers sign what they are not buying as clearly as what they are buying. That reduces custom services creep.

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.

Runway allocation and stage gates

RelayOps holds $400,000 runway and burns roughly $45,000 per month with two engineers. Rule of thumb: spend no more than 25% of runway on a single RAT before reading results. $400,000 × 25% = $100,000 cap per RAT cycle. Planned MVP build plus pilot support targets $90,000 over two months, within cap.

Stage gate 0 (pre-build): ICE-ranked shadowing complete, three pilot LOIs (letters of intent, non-binding statements of interest) with owner contacts. Gate 1 (week 4 live): ≥60% emergency jobs in system or pause rollout. Gate 2 (week 8): median dispatch time ≤7 minutes or pivot messaging. Gate 3 (week 12): renewals at ≥$89 per tech or revisit wedge.

If gate 1 fails, reallocate remaining build budget to onboarding redesign rather than new features. Sunk-cost fallacy kills startups here: teams add AI because adoption failed instead of fixing workflow fit.

Board reporting ties dollars to gates: "We spent $78,000 of $100,000 RAT budget; gate 1 passed at 71% usage; requesting $45,000 month three burn unchanged."

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.

Persevere, pivot, or stop criteria

Persevere when primary RAT metrics hit predefined success thresholds and secondary assumptions do not contradict. RelayOps perseveres if median emergency dispatch time ≤5 minutes on 20+ jobs and daily active dispatchers ≥70% across two pilots.

Pivot when learning is clear but the original hypothesis wrong. Example: dispatchers adopt console but emergency volume is too low to prove speed; pivot wedge to compliance audit trail for commercial contracts. Pivot preserves team and some code; it changes which assumption stack is central.

Stop when kill criteria hit and pivots exhaust ranked assumptions within runway. Stop is rational capital preservation, not shame. Document learnings for acquihire or segment change.

Decisions need dates and signatories. Maya and Jordan co-sign gate outcomes within 48 hours of metric review to prevent drift.

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.

Week 12 results arrive. RelayOps spent $88,000 on build and pilot support (within $100,000 cap). Data from three Phoenix pilots:

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: Pilot metrics

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: Revenue and decision math

Pilot monthly revenue: (92+118+68) × $99 = 278 × 99 = $27,522/month. If RelayOps renews Desert Cool + Valley only: (92+68) × 99 = 160 × 99 = $15,840/month. SunLine missed usage gate (52% < 60% kill) and time gate (6.8 > 5 target).

Decision: Persevere on emergency speed wedge with two renewals. Pivot onboarding for SunLine-like accounts with lower emergency volume: offer audit trail module trial. Do not stop: 2 of 3 renewals, 2 of 3 usage ≥70%, median times 4.6 and 4.9 beat 12-minute ENT 401 baseline by >50%.

Remaining runway: $400,000 − $88,000 − ($45,000 × 3 months operations during pilots) = $400,000 − $88,000 − $135,000 = $177,000. Months left ≈ $177,000 ÷ $45,000 ≈ 3.9 months without new revenue. Renewals add $15,840/month extending runway.

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 check

278 techs × $99 = $27,522 ✓. 160 × $99 = $15,840 ✓. Baseline 12 min vs 4.6 min = 62% reduction ✓. SunLine 52% usage triggers pivot playbook, not company stop ✓. Spend $88,000 < $100,000 cap ✓.

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

Board question: "SunLine is your largest logo. Why not build schedule module to save them?" Answer: "SunLine failed desirability gate on emergency wedge. Building schedule module before adoption proof repeats HeatRoute's mistake. We pivot onboarding for low-emergency accounts after we document why usage stalled."

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.

DispatchIQ (fictional) ignored kill criteria to please a channel partner. After $320,000 spend, usage stayed at 22% across four pilots. Founders persevered because one pilot promised enterprise expansion. Runway hit $80,000 with no renewals. RelayOps's gate memo would have stopped at week 4 usage <40% after remediation, preserving ~$200,000 for pivot or orderly shutdown.

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 can add a fourth pilot (Dallas, 105 techs) for $8,000 extra travel and support, delaying gate review 3 weeks. Current burn $45,000/month. Expected usage 65%, median time 5.5 min.

Should Maya add the fourth pilot before gate 3? Compute extra burn during delay (3 weeks ≈ 0.75 month). Compare to learning value given gates already passed at 2 of 3 Phoenix pilots.

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

Extra burn during 3-week delay: 0.75 × $45,000 = $33,750 plus $8,000 travel = $41,750 incremental cost.

Gate 3 already has two successful renewals demonstrating pattern in beachhead. Fourth pilot adds marginal learning on Dallas geography but risks $41,750 and delays sales focus on converting renewals to annual contracts.

Recommend defer Dallas until Phoenix renewals convert to 12-month agreements. Revisit Dallas when runway >$200,000 after renewal cash inflow. Check: $41,750 ≈ 0.93 months runway, material at 3.9 months remaining ✓

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

• Pilot selection filters for learning quality, not logo prestige.
• Scope memos tie deferrals to assumption ranks and signed customer exhibits.
• Spend ≤25% of runway per RAT cycle with dated stage gates.
• Persevere, pivot, and stop criteria must be signed before pilots start.
• Applied MVP strategy converts maps into memos, contracts, and cash decisions.

1. Draft a one-page scope memo for RelayOps emergency queue MVP.
2. Which gate would worry you most on a real ops software pilot you have seen?
3. Continue to Unit 1 Lesson 1: Understanding Experiment Design and Learning Loops.