Key Concepts and Vocabulary in MVP Strategy and Assumption Mapping

Shared language prevents expensive misalignment

Teams argue for weeks about "the MVP" because the term hides different mental models. Engineering hears minimum code. Sales hears minimum embarrassment. Investors hear minimum story for the next raise. Customer success hears minimum support load. Without a shared vocabulary, each group optimizes locally and the company ships a product that tests nothing important.

Vocabulary is not pedantry in early-stage ventures. It is how founders convert ENT 401 discovery insights into testable bets. When Maya at RelayOps says "riskiest assumption test," Jordan should picture a two-week pilot with predefined kill criteria, not a routing algorithm refactor. When she says "concierge MVP," dispatch managers should expect human-assisted routing behind a simple intake form, not a broken self-serve signup.

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 builds the lexicon for Unit 0. You will use these terms in assumption maps, pilot contracts, and board updates. Master them now so later frameworks describe decisions rather than decorate slide decks.

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.

Minimum viable product (MVP) and its common variants

An MVP (minimum viable product, the smallest offer that produces decision-grade learning about the riskiest beliefs) is defined by learning output, not feature count. A five-screen web console can be an MVP if it tests whether dispatch managers adopt a new workflow during live emergencies. A forty-screen platform can fail as an MVP if it tests nothing falsifiable because too many variables changed at once.

Founders use variant labels to signal how learning is produced. A concierge MVP delivers the promised outcome manually while the customer-facing surface stays simple. RelayOps might route emergency jobs by hand in a spreadsheet while dispatchers submit requests through a web form. The learning target is workflow adoption, not algorithm quality. A Wizard of Oz MVP looks automated but hides human work behind the interface. Customers experience software; operators perform the task until automation is justified.

A single-feature MVP commits to one job-to-be-done and defers adjacent jobs. RelayOps's emergency queue MVP is single-feature: it ignores invoicing, inventory, and technician performance dashboards. A smoke-test MVP measures demand before building fulfillment. Landing pages, waitlists, and paid pilot deposits are smoke tests. They validate interest and budget authority weakly compared to live usage, but they cost days instead of months.

Each variant trades fidelity for speed. Teams pick the variant that falsifies the riskiest assumption at the lowest cost without destroying operational credibility. A dispatch manager who loses an emergency job during a heat wave because RelayOps "is just a test" will not return.

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.

Use this table to align stakeholders on what kind of MVP RelayOps is running:

Mislabeling causes scope creep. If the team calls a six-month build an "MVP" while investors call a landing page an "MVP," planning conversations talk past each other and runway burns.

Assumption types: desirability, feasibility, and viability

Startup plans rest on three assumption families popularized in lean startup methodology (a product development approach that favors rapid experiments over large upfront plans). Desirability assumptions ask whether customers want the solution enough to change behavior. RelayOps assumes dispatch managers will enter jobs into software while phones ring at 7 a.m. That is desirability.

Feasibility assumptions ask whether the team can deliver the promised experience reliably. Can RelayOps integrate with existing customer databases? Can SMS reach technicians in basement mechanical rooms? Can median emergency dispatch time fall from 12 minutes to under 5 minutes within 30 days of rollout? Feasibility is about physics, engineering, and operations, not taste.

Viability assumptions ask whether the business can sustain itself economically and legally. Will customers pay $89 to $149 per technician per month? Does gross margin support inside sales? Will mid-market HVAC firms renew after summer peak season? Viability connects product behavior to unit economics and cash runway.

Assumption maps that mix all three types without labels produce muddled priorities. A team might spend a quarter on feasibility (mobile app polish) while the killer desirability question (dispatcher adoption) stays untested. RelayOps ranks desirability first because ENT 401 already showed pain; the MVP must prove behavior change.

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.

Leap-of-faith assumptions and the riskiest assumption test (RAT)

Leap-of-faith assumptions are beliefs that must be true for the venture to work but lack strong evidence. RelayOps treats "dispatch managers control pilot budget without owner approval" as a leap-of-faith until three paid pilots sign. ENT 401 interviews suggested it; contracts will prove it.

The RAT (riskiest assumption test, the cheapest experiment that could falsify the highest-impact uncertain belief) forces ordering. Rank assumptions by impact (damage if wrong) and uncertainty (evidence gap). Multiply to prioritize. RelayOps scored "dispatchers will use the console during live emergencies" at impact 5 and uncertainty 5, risk score 25. That assumption gets the first experiment.

A RAT is not the first feature on the roadmap. It is the fastest credible test of the belief that would kill the company if false. If dispatchers refuse the console, a perfect routing engine is irrelevant. Maya should be able to explain the current RAT in one sentence to any board member.

Kill criteria belong inside the RAT definition before launch. Example: if fewer than 60% of emergency jobs run through RelayOps after four weeks at a pilot site, pause rollout and interview dispatchers before writing new code. Success criteria are symmetric: median dispatch time under 5 minutes on 20 or more live jobs with at least 70% daily active dispatchers.

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, beta, and production: boundary vocabulary

A pilot is a bounded commercial test with explicit start date, success metrics, exit terms, and often a discounted price that still validates willingness to pay. RelayOps pilots might charge $99 per technician per month for 90 days with a written option to cancel if median dispatch time does not improve by 40%. Pilots are learning instruments, not permanent discount programs.

A beta traditionally signals incomplete product quality with tolerant early users. In B2B operations software, "beta" can poison trust. Dispatch managers facing Monday emergencies do not want beta; they want reliable narrow scope. RelayOps should call early deployments pilots, not betas, unless the customer explicitly accepts quality risk in writing.

Production readiness is contextual. Production for RelayOps's emergency queue means zero silent job drops, audit log of every routing decision, and 99.5% uptime during business hours. Production does not mean feature parity with ServiceTitan. Confusing production with completeness delays learning.

Scope boundary documents list what the MVP will not do. RelayOps's boundary might exclude native mobile apps, QuickBooks integration, and AI routing. Boundaries prevent pilot customers from renegotiating the test into a custom services project.

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.

Operating glossary and contract language

Vocabulary fails if it stays in founder slides. RelayOps maintains a one-page operating glossary appended to every pilot statement of work (SOW, a document listing deliverables, timeline, and success criteria). The glossary defines MVP scope, RAT metric, kill criteria, and excluded features in plain English. Legal language references the glossary exhibit so customers cannot claim misunderstanding when RelayOps declines a scheduling module request mid-pilot.

Contract drafters should avoid synonyms that collide with glossary terms. If the SOW says "trial" but the glossary says "paid pilot," dispatch managers hear "free." Maya standardizes on "pilot" everywhere customer-facing. Internal engineering docs may say "alpha deployment" but customer comms never do.

Glossary updates require version numbers. When RelayOps adds "live entry" definition (job created within 2 minutes of call timestamp), pilot amendment v1.1 goes to active customers before metrics change. Retroactive redefinition destroys trust the same way restated revenue does in finance.

Investor updates should reuse glossary terms verbatim. When Maya writes "RAT passed on desirability," board members who read prior decks know that means ≥70% emergency job usage with median dispatch time ≤5 minutes, not generic satisfaction. Consistency across legal, product, and fundraising documents is part of MVP strategy, not administrative overhead.

Train customer success and support hires on glossary before they join calls. One confused synonym from a new hire can undo weeks of boundary setting with a pilot champion who hears "beta" and stops enforcing dispatcher compliance.

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.

RelayOps glossary excerpt for pilot SOW:

Maya drafts a pilot proposal for Desert Cool HVAC, a 92-technician Phoenix firm. Jordan's engineering plan mentions "beta mobile web." Sales wants "MVP pricing at $49 per tech." The owner asks whether RelayOps is "production ready." Maya runs a vocabulary audit so all parties sign the same test.

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: Term misreads identified

"Beta mobile web" signals quality risk to dispatch managers. Rename to pilot mobile web with uptime commitment of 99.5% on job confirmation links. "$49 per tech" undercuts ENT 401 WTP (willingness to pay, the price customers accept in exchange for value) range and teaches wrong price anchor. Set pilot price at $99 per tech for 90 days (within $89 to $149 band). "Production ready" is reframed as production ready for emergency queue scope only, with explicit exclusions listed.

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: Pilot terms tied to vocabulary

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

Stated WTP from ENT 401: $89 to $149 per tech/month. Pilot price $99 ✓. Technician count 92. Monthly pilot revenue: 92 × $99 = $9,108. Quarter revenue if renewed three months: $27,324. Success metric uses same 12-minute baseline and 5-minute target from ENT 401 MVP goal ✓. Kill threshold 60% usage vs success 70% daily active dispatchers: consistent (kill is lower bar for early abort) ✓.

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

Owner question: "Are we your guinea pigs?" Answer: "You are a paid pilot with kill switches we publish upfront. If we miss metrics, you exit without migration cost. We learn whether emergency dispatch time drops; you learn whether RelayOps earns renewal at $99 per tech."

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.

CoolFlow Dispatch (fictional) told investors it had "10 MVP customers" but counted free trials with no success metrics. Engineering called the product "beta" while sales promised "enterprise-grade reliability." When a Dallas HVAC firm lost three emergency jobs in one week, the account churned and cited "beta quality." CoolFlow had not defined pilot boundaries or RAT metrics. RelayOps's vocabulary audit prevents the same collapse by separating pilot scope, kill criteria, and production readiness for one narrow job.

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 considers labeling its first deployment a "free beta" to speed sign-ups. Expected uptake: 8 firms vs 3 paid pilots. Maya estimates free beta saves 3 weeks of sales cycle. Jordan warns free users will not follow dispatch protocols.

Tasks: (1) Classify the main assumption being tested under desirability, feasibility, or viability. (2) Compute quarterly revenue difference if 8 firms average 80 techs at $0 vs 3 firms at 92 techs paying $99 (use 92 for all paid pilots). (3) Recommend free beta or paid pilot in one paragraph citing vocabulary from this lesson.

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

The main assumption is desirability: will dispatch teams use the console under live emergency load? Free beta weakly tests desirability because unpaid users tolerate abandonment; paid pilots reveal serious workflow commitment.

Paid pilot quarterly revenue: 3 firms × 92 techs × $99/month × 3 months = 3 × 92 × 99 × 3 = $81,756. Free beta revenue: $0. Difference: $81,756. Even one paid pilot at 92 techs for one quarter: 92 × 99 × 3 = $27,324.

Recommend paid pilot with published RAT metrics. Free beta confuses MVP with marketing and destroys WTP signal. Three-week sales savings does not offset $81,756 learning value and price anchoring damage. Check: paid path stays within ENT 401 WTP band ✓

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

• MVP variants describe how learning is produced, not how polished the UI looks.
• Desirability, feasibility, and viability labels keep assumption maps honest.
• The riskiest assumption test (RAT) targets the highest impact-times-uncertainty belief first.
• Pilots are bounded commercial experiments; betas signal tolerance ops buyers reject.
• Shared vocabulary aligns engineering, sales, and customers on the same scoreboard.

1. Write one-sentence RAT definitions for three RelayOps assumptions from ENT 401.
2. Find an example where a startup misused MVP or beta in public messaging. What confusion resulted?
3. Continue to Lesson 3: Frameworks for Analyzing MVP Strategy and Assumption Mapping.