ENT 301 · Unit 3 · Lesson 2 of 5
Minimum Viable Products
Business Models and MVPs
Lesson
The MVP is a learning instrument, not a launch party
Teams ship "version one" and call it an MVP (minimum viable product, the smallest offer that produces decision-grade learning about the riskiest beliefs) while changing ten variables at once. RelayOps cannot afford that mistake with $400,000 runway and $45,000 monthly burn. Jordan Okonkwo could spend six months building scheduling parity with ServiceTitan and still learn nothing about whether dispatchers will touch software during a Monday heat-wave emergency.
An MVP is defined by falsifiable output: did behavior change under live operational stress? RelayOps chose an emergency dispatch MVP: a web console for urgent jobs, SMS links to technicians, and manual override visibility. Invoicing, inventory, native mobile apps, and AI routing sit outside scope. Maya Chen runs a concierge MVP variant when Jordan routes jobs manually behind the intake form for the first two weeks at Desert Cool HVAC.
RelayOps is a B2B (business-to-business, selling to companies) SaaS (software as a service, subscription software delivered over the internet) venture improving dispatch and scheduling for mid-market field-service companies and the anchor venture for ENT 301. Founders Maya Chen (CEO, former dispatch manager at regional HVAC operator Summit Climate) and Jordan Okonkwo (CTO, former platform engineer) left Summit Climate in 2025 after living dispatch-center chaos firsthand. Their initial beachhead is 80-to-200 technician residential-heavy HVAC and plumbing firms, later expanding to commercial HVAC in Phoenix and Dallas with 50 to 150 field technicians. Discovery work confirmed 10 to 15 percent overtime on peak weeks and missed first-visit appointment windows tied to same-day capacity loss when dispatchers rebalance schedules across phone calls, whiteboards, and legacy CRM tabs without a live view of technician skill, location, and parts. Competitors include ServiceTitan (heavy and expensive for mid-market), spreadsheets and whiteboards (status quo).
Throughout this course, RelayOps evolves from opportunity hypothesis to scaled venture. Elective depth lives in ENT 402 (Product-Market Fit and Startup Experimentation) when you want a full unit on that phase. ENT 301 teaches the integrated journey so you can advise founders, invest, or launch with disciplined evidence. ENT 402 dedicates full units to MVP strategy, assumption mapping, and experiment loops. ENT 301 requires you to choose MVP scope that matches the business model wedge and publishes kill criteria before code ships.
This lesson teaches MVP variants, scope boundaries, and production-readiness definitions for operations B2B SaaS where "beta" language can destroy trust when a homeowner waits without cooling.
MVP variants for dispatch operations
Founders pick MVP variants based on which assumption must break first. A concierge MVP delivers outcomes manually while customers see a simple surface. RelayOps dispatchers submit emergency jobs through a form; Maya assigns technicians in a spreadsheet until usage habits form. A Wizard of Oz MVP shows suggested routes in the UI while humans apply rules offline. A single-feature MVP does one job exceptionally: emergency queue only, not full-day optimization. A smoke-test MVP sells paid pilot deposits before fulfillment exists.
Each variant trades fidelity for speed. Concierge maximizes learning about desirability; smoke tests weakly validate budget authority. RelayOps uses concierge for week 1-2 at a pilot, then transitions to semi-automated suggestions once dispatchers prove live entry compliance.
Mislabeling variants causes scope creep. If sales calls a six-month build an MVP while investors call a landing page an MVP, planning talks past itself and runway burns.
RelayOps MVP variant map:
| Variant | Customer sees | Team does manually | Falsifies |
|---|---|---|---|
| Concierge | Emergency intake form | Maya assigns techs | Dispatcher adoption under call load |
| Wizard of Oz | Suggested tech in UI | Jordan applies rules | Do suggestions change dispatch time? |
| Single-feature | Emergency queue only | No invoicing or mobile | Is speed the wedge vs optimization? |
| Smoke test | Paid pilot deposit page | No product yet | Will manager commit budget pre-build? |
Emergency dispatch MVP scope boundary
RelayOps's scope boundary (written list of what the MVP will not do during the pilot) protects learning integrity. Included: emergency job intake, technician SMS acknowledgment, timestamp audit log, dispatcher override notes. Excluded: QuickBooks sync, ServiceTitan API, native iOS app, marketing campaigns module, predictive maintenance alerts.
Boundaries belong in the pilot SOW (statement of work, contract listing deliverables, timeline, and success metrics). When a Phoenix owner requests invoicing mid-pilot, Maya cites Exhibit B exclusions rather than negotiating a custom build that invalidates the RAT.
Production readiness is contextual. For emergency queue scope, production means zero silent job drops, 99.5% uptime during business hours, and visible override history. It does not mean feature parity with incumbents.
Assumption map tie-in and RAT selection
The MVP must test the top cell on the assumption map. RelayOps scores "dispatchers adopt console during live emergencies" at impact 5, uncertainty 5, risk 25. The emergency dispatch MVP exists to falsify that belief, not to impress trade show attendees.
The RAT (riskiest assumption test) for month one: paid 90-day pilot at Desert Cool with success metric of 70% emergency jobs entered live and median dispatch time at or below 5 minutes on 20 or more jobs. Kill criteria: fewer than 60% of emergency jobs in system after week 4 triggers pause and dispatcher interviews, not a feature sprint.
Feasibility and viability assumptions wait in queue. Native mobile requirement scores lower risk until desirability passes. ENT 402 expands ICE prioritization and pre-mortems; ENT 301 expects kill criteria written before Jordan merges pull requests.
Pilot versus beta language in ops B2B
A pilot is a bounded commercial test with start date, success metrics, exit terms, and usually discounted but non-zero price. RelayOps pilots charge $99 per technician per month for 90 days. A beta signals tolerance for quality gaps. Dispatch managers facing homeowner emergencies do not want beta; they want reliable narrow scope.
Free trials teach the wrong desirability signal. Unpaid users abandon workflows without procurement commitment. Maya's paid pilot generates WTP evidence and forces dispatcher champions to enforce usage.
Glossary discipline matters. One synonym mismatch (trial versus pilot) can undo weeks of boundary setting with a champion who hears "free."
Concierge exit criteria and automation gates
Concierge mode is temporary scaffolding, not the business model. RelayOps sets exit criteria: automate assignment when 70% of emergency jobs run through the console for two consecutive weeks and median dispatch time is at or below 7 minutes with manual routing.
Automation gates prevent premature algorithm investment. If dispatchers batch-enter jobs after calls, automation will optimize fiction. Jordan adds timestamp audits comparing call logs to job creation before enabling auto-suggest.
Maya reports concierge hours weekly. If manual routing exceeds 20 hours per week across pilots, hiring dispatch contractors is cheaper than pretending software exists.
Worked example: RelayOps emergency dispatch MVP pilot charter
Desert Cool HVAC (92 technicians, Phoenix) agrees to a paid pilot. Jordan's backlog includes mobile web and ServiceTitan export. Maya drafts the MVP charter tied to RAT metrics.
Part A: Scope and exclusions
In scope: Emergency queue web console, SMS tech links, audit log, dispatcher training (6 hours). Out of scope: Invoicing, native app, CRM API, schedule optimization for non-emergency jobs.
RAT under test: Desirability of live emergency entry. Concierge weeks 1-2: Maya manual assignment behind form.
Part B: Success, kill, and economics
| Metric | Target | Kill threshold |
|---|---|---|
| Emergency jobs in system | ≥ 70% live entry | < 60% by week 4 |
| Median dispatch time | ≤ 5 min on ≥ 20 jobs | > 7 min at week 8 |
| Daily active dispatchers | ≥ 70% | < 50% for 2 weeks |
| Pilot price | $99 × 92 techs = $9,108/mo | N/A |
Check: 92 × $99 × 3 months = $27,324 pilot revenue ✓.
Part C: Build decision
Defer mobile web to post-RAT unless SMS acknowledgment rate falls below 85%. Defer ServiceTitan API until renewal conversation. Jordan ships console plus SMS in 5 weeks; everything else sits on assumption map rank 8 or lower.
Managerial read: owner question "Are we guinea pigs?" gets answered with published kill switches and paid status, not beta apologies.
Part D: Managerial read
Investors asking for demos should see emergency loop latency and usage percentage, not a roadmap of deferred modules. MVP success is decision-grade evidence, not feature completeness.
Worked example: CoolFlow Dispatch: wide MVP failure
CoolFlow Dispatch (fictional) shipped invoicing, mobile, and routing in one "MVP" release. Dallas pilot dispatchers used only the whiteboard because training took three weeks. CoolFlow could not tell whether adoption failed due to UI, scope overload, or trust. RelayOps's single-feature emergency MVP isolates the riskiest belief with a charter Desert Cool can sign.
Managerial read: if an MVP tests more than two assumption families at once, failure modes become uninterpretable.
Common mistakes beginners make
| Mistake | Reality |
|---|---|
| Calling the first embarrassing release an MVP without a RAT | Name the riskiest assumption and metric before writing code |
| Using free beta for operations software | Paid pilots produce desirability and WTP signal under procurement pressure |
| Labeling live pilots as beta to excuse outages | Narrow scope with high reliability beats wide beta in dispatch centers |
| Letting concierge manual work become the permanent delivery model | Set automation exit criteria and track manual hours weekly |
| Skipping scope boundary in the SOW | Exhibit exclusions prevent pilots from becoming custom services projects |
Practice problem
RelayOps can ship in 5 weeks: emergency console only (Option X) or console plus non-emergency schedule board (Option Y, 9 weeks). Assumption map ranks emergency adoption at risk 25; schedule optimization value at risk 12. Burn is $45,000 per month; each extra month costs one RAT cycle.
Tasks: (1) Which option matches RAT discipline? (2) Compute extra burn cost of Option Y versus X. (3) Draft kill criteria for the chosen option in two bullet metrics.
Solution
Choose Option X. It falsifies the highest-risk assumption first; Option Y adds 4 weeks and confounds desirability with schedule workflow change.
Extra burn: 4 × $45,000 = $180,000 opportunity cost plus delayed learning. At pre-seed runway, that is material.
Kill criteria for Option X: (1) fewer than 60% emergency jobs entered live by pilot week 4; (2) median dispatch time above 7 minutes on 15 or more tracked jobs by week 8. Check: 4 × 45,000 = $180,000 ✓.
Key takeaways
- MVP variants describe how learning is produced, not how polished the UI looks.
- RelayOps's emergency dispatch MVP tests dispatcher adoption under live stress first.
- Scope boundaries and pilot language protect trust in operations B2B.
- Kill criteria and concierge exit gates prevent sunk-cost drift.
- ENT 402 provides deeper tooling on assumption maps and experiment backlogs.
After this lesson
- Write a one-page MVP charter for RelayOps with in-scope, out-of-scope, RAT, and kill lines.
- Identify which MVP variant fits a smoke test for budget authority at a 150-technician plumbing firm.
- Continue to Experiment Design: turning the charter into falsifiable tests.
Applying Minimum Viable Products at RelayOps
When RelayOps applies minimum viable products, Maya Chen and Jordan Okonkwo anchor decisions in field evidence, not slide optimism. Their beachhead (80-to-200 technician residential-heavy HVAC and plumbing firms, later expanding to commercial HVAC in Phoenix and Dallas with 50 to 150 field technicians) experiences 10 to 15 percent overtime on peak weeks and missed first-visit appointment windows. Discovery interviews suggested $89 to $149 per technician per month in discovery interviews. Competitors include ServiceTitan (heavy and expensive for mid-market), spreadsheets and whiteboards (status quo). Every framework in this lesson should translate into a falsifiable claim about that segment, not generic startup advice.
Consider how business models, MVPs, and experimentation changes capital allocation. RelayOps started with roughly $400k runway and ~$45k monthly burn before seed. A one-month delay on the wrong opportunity costs more than a month of disciplined interviews. That is why minimum viable products is a CEO-level skill, not a brainstorming exercise.
Document owners alongside metrics. Maya owns discovery synthesis; Jordan owns build scope tied to assumption ranks; both sign kill criteria before pilots. When definitions live in a shared glossary (pilot versus beta, activation versus login), the team avoids comparing incompatible cohort charts after Dallas expansion.
Extended RelayOps scenario: cross-functional read
Imagine RelayOps's quarterly review for minimum viable products. An angel investor asks whether dispatch pain justifies another build sprint. A pilot COO asks whether overtime reduction pays for software. A dispatcher lead asks whether the console survives Monday heat-wave call volume. A weak business models, MVPs, and experimentation answer pleases one stakeholder. A strong answer links evidence: interview prevalence, timed shadow data, pilot median dispatch time, and renewal intent.
Work a conservative arithmetic example. Suppose RelayOps targets 100-technician firms at $28 per technician per month ($2,800 MRR per logo). Closing 18 beachhead logos yields $50,400 MRR ($605k ARR). If CAC (customer acquisition cost, sales and marketing to win one paying customer) is $18,000 per logo, payback in months equals CAC divided by monthly gross profit. At 80% gross margin on MRR, monthly profit ~$2,240; payback ~8 months. Check: 18,000 / 2,240 ≈ 8.0 ✓. Founders who skip this math raise before they know whether GTM is repeatable.
Stakeholder conflict is normal. Jordan may push feature breadth; Maya must protect RAT (riskiest assumption test, cheapest experiment that falsifies the highest-impact uncertain belief) scope. Minimum Viable Products gives language to negotiate with pre-registered metrics rather than charisma. If evidence is descriptive only, label it and fund the next test instead of scaling spend.
For deeper study on this unit's specialty, see ENT 402 (Product-Market Fit and Startup Experimentation). ENT 301 integrates the full arc; electives provide textbook-depth units you can take after this core course.
Technical mechanics and checks (RelayOps patterns)
For minimum viable products, show work the way finance shows reconciliations. Opportunity scorecards print weighted criteria and explicit kill rules. Interview synthesis tables show code frequency with qualified denominators only. MVP scorecards list assumption rank, build weeks, runway share, and kill criteria. Cap tables after SAFE conversion show pre-money, post-money, and founder ownership with check lines.
Use plain-language hypotheses before instruments. Example: "If fewer than six of ten operations leaders rank same-day rebalance in top-three pains, RelayOps deprioritizes hypothesis H1." That hypothesis is falsifiable without code. Weak hypotheses hide inside feature roadmaps.
Spreadsheet grain matters. Customer-level tables suit funnel conversion; logo-month tables suit retention; assumption-level tables suit experiment backlogs. RelayOps forbids ambiguous metrics like "engagement" without operational definitions tied to dispatch jobs routed per active day.
Common executive questions (and disciplined answers)
Executives ask short questions that require long disciplined answers. "How sure are we?" maps to evidence labels (exploratory, descriptive, causal), not bravado. "What is the dollar impact?" maps to overtime saved, slots recovered, or MRR with stated assumptions. "Can we ship faster?" maps to risk of untested adoption during live emergencies. "Why not copy ServiceTitan?" maps to wedge focus and beachhead economics, not feature envy.
RelayOps's credible answer format for minimum viable products is three bullets: recommendation, evidence strength, and next test if limitations matter. A fourth bullet states what would falsify the recommendation within 60 days. That discipline prevents founders from becoming either bottlenecks or rubber stamps for investor narratives.
Judgment under uncertainty (RelayOps decision log)
Founders who master minimum viable products keep a decision log: date, decision, evidence at time, dissent captured, review date. When RelayOps chose emergency-queue MVP over full suite parity, the log recorded HeatRoute's LOI-to-active failure mode as contrast case. When Phoenix beat Dallas on retention, the log triggered segment screener review rather than blaming sales tone.
Your workbook should mirror that log format for one venture you follow. If you cannot write dissent and kill criteria, you have a story, not a decision. Minimum Viable Products is how teams convert stories into capital-efficient learning.
Applying Minimum Viable Products at RelayOps
When RelayOps applies minimum viable products, Maya Chen and Jordan Okonkwo anchor decisions in field evidence, not slide optimism. Their beachhead (80-to-200 technician residential-heavy HVAC and plumbing firms, later expanding to commercial HVAC in Phoenix and Dallas with 50 to 150 field technicians) experiences 10 to 15 percent overtime on peak weeks and missed first-visit appointment windows. Discovery interviews suggested $89 to $149 per technician per month in discovery interviews. Competitors include ServiceTitan (heavy and expensive for mid-market), spreadsheets and whiteboards (status quo). Every framework in this lesson should translate into a falsifiable claim about that segment, not generic startup advice.
Consider how business models, MVPs, and experimentation changes capital allocation. RelayOps started with roughly $400k runway and ~$45k monthly burn before seed. A one-month delay on the wrong opportunity costs more than a month of disciplined interviews. That is why minimum viable products is a CEO-level skill, not a brainstorming exercise.
Document owners alongside metrics. Maya owns discovery synthesis; Jordan owns build scope tied to assumption ranks; both sign kill criteria before pilots. When definitions live in a shared glossary (pilot versus beta, activation versus login), the team avoids comparing incompatible cohort charts after Dallas expansion.
Extended RelayOps scenario: cross-functional read
Imagine RelayOps's quarterly review for minimum viable products. An angel investor asks whether dispatch pain justifies another build sprint. A pilot COO asks whether overtime reduction pays for software. A dispatcher lead asks whether the console survives Monday heat-wave call volume. A weak business models, MVPs, and experimentation answer pleases one stakeholder. A strong answer links evidence: interview prevalence, timed shadow data, pilot median dispatch time, and renewal intent.
Work a conservative arithmetic example. Suppose RelayOps targets 100-technician firms at $28 per technician per month ($2,800 MRR per logo). Closing 18 beachhead logos yields $50,400 MRR ($605k ARR). If CAC (customer acquisition cost, sales and marketing to win one paying customer) is $18,000 per logo, payback in months equals CAC divided by monthly gross profit. At 80% gross margin on MRR, monthly profit ~$2,240; payback ~8 months. Check: 18,000 / 2,240 ≈ 8.0 ✓. Founders who skip this math raise before they know whether GTM is repeatable.
Stakeholder conflict is normal. Jordan may push feature breadth; Maya must protect RAT (riskiest assumption test, cheapest experiment that falsifies the highest-impact uncertain belief) scope. Minimum Viable Products gives language to negotiate with pre-registered metrics rather than charisma. If evidence is descriptive only, label it and fund the next test instead of scaling spend.
For deeper study on this unit's specialty, see ENT 402 (Product-Market Fit and Startup Experimentation). ENT 301 integrates the full arc; electives provide textbook-depth units you can take after this core course.
Technical mechanics and checks (RelayOps patterns)
For minimum viable products, show work the way finance shows reconciliations. Opportunity scorecards print weighted criteria and explicit kill rules. Interview synthesis tables show code frequency with qualified denominators only. MVP scorecards list assumption rank, build weeks, runway share, and kill criteria. Cap tables after SAFE conversion show pre-money, post-money, and founder ownership with check lines.
Use plain-language hypotheses before instruments. Example: "If fewer than six of ten operations leaders rank same-day rebalance in top-three pains, RelayOps deprioritizes hypothesis H1." That hypothesis is falsifiable without code. Weak hypotheses hide inside feature roadmaps.
Spreadsheet grain matters. Customer-level tables suit funnel conversion; logo-month tables suit retention; assumption-level tables suit experiment backlogs. RelayOps forbids ambiguous metrics like "engagement" without operational definitions tied to dispatch jobs routed per active day.
Common executive questions (and disciplined answers)
Executives ask short questions that require long disciplined answers. "How sure are we?" maps to evidence labels (exploratory, descriptive, causal), not bravado. "What is the dollar impact?" maps to overtime saved, slots recovered, or MRR with stated assumptions. "Can we ship faster?" maps to risk of untested adoption during live emergencies. "Why not copy ServiceTitan?" maps to wedge focus and beachhead economics, not feature envy.
RelayOps's credible answer format for minimum viable products is three bullets: recommendation, evidence strength, and next test if limitations matter. A fourth bullet states what would falsify the recommendation within 60 days. That discipline prevents founders from becoming either bottlenecks or rubber stamps for investor narratives.
Judgment under uncertainty (RelayOps decision log)
Founders who master minimum viable products keep a decision log: date, decision, evidence at time, dissent captured, review date. When RelayOps chose emergency-queue MVP over full suite parity, the log recorded HeatRoute's LOI-to-active failure mode as contrast case. When Phoenix beat Dallas on retention, the log triggered segment screener review rather than blaming sales tone.
Your workbook should mirror that log format for one venture you follow. If you cannot write dissent and kill criteria, you have a story, not a decision. Minimum Viable Products is how teams convert stories into capital-efficient learning.
Applying Minimum Viable Products at RelayOps
When RelayOps applies minimum viable products, Maya Chen and Jordan Okonkwo anchor decisions in field evidence, not slide optimism. Their beachhead (80-to-200 technician residential-heavy HVAC and plumbing firms, later expanding to commercial HVAC in Phoenix and Dallas with 50 to 150 field technicians) experiences 10 to 15 percent overtime on peak weeks and missed first-visit appointment windows. Discovery interviews suggested $89 to $149 per technician per month in discovery interviews. Competitors include ServiceTitan (heavy and expensive for mid-market), spreadsheets and whiteboards (status quo). Every framework in this lesson should translate into a falsifiable claim about that segment, not generic startup advice.
Consider how business models, MVPs, and experimentation changes capital allocation. RelayOps started with roughly $400k runway and ~$45k monthly burn before seed. A one-month delay on the wrong opportunity costs more than a month of disciplined interviews. That is why minimum viable products is a CEO-level skill, not a brainstorming exercise.
Document owners alongside metrics. Maya owns discovery synthesis; Jordan owns build scope tied to assumption ranks; both sign kill criteria before pilots. When definitions live in a shared glossary (pilot versus beta, activation versus login), the team avoids comparing incompatible cohort charts after Dallas expansion.
Lesson exercise
32 minEmergency MVP Charter and Kill Lines
Deliverable
One-page MVP charter, variant classification, and kill criteria in your ENT 301 experiment log.
Rubric
- • Option X matches highest risk assumption first
- • Scope exclusions name invoicing and ServiceTitan API
- • Paid pilot language, not free beta
- • Concierge exit criteria stated with automation gate