Testing Assumptions

Assumption tests turn opinions into pre-registered bets

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 401 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.

Customer discovery produces stories. Testing assumptions converts stories into falsifiable statements with instruments, sample sizes, success thresholds, and kill criteria. RelayOps maintains an assumption ledger ranked by impact × uncertainty.

ENT 401 treats validation decisions as gate memos. ENT 301 operationalizes gates weekly. Jordan cannot build beyond the assumption under test without explicit gate passage.

Top RelayOps assumptions entering testing: dispatch managers control pilot budget, dispatchers will adopt a new console during live calls, emergency rebalance is the wedge versus schedule optimization, ServiceTitan integration can wait until post-pilot.

Assumption ledger and ranking

Each assumption gets ID, statement, impact (1-5), uncertainty (1-5), risk score, instrument, owner, due date. RelayOps reviews ledger every Friday.

Impact measures damage if false. Uncertainty measures evidence gap. Multiply for rank.

Assumption A3 "dispatchers adopt during live calls" scores 25 and drives MVP scope in ENT 402.

RelayOps assumption ledger excerpt:

Desirability, feasibility, viability tests

Desirability: will users change behavior? Feasibility: can we deliver reliably? Viability: will economics work? RelayOps tests desirability first because explore proved pain; adoption remains uncertain.

Feasibility tests include uptime on emergency queue, SMS delivery to techs. Viability tests include stated WTP bands and pilot pricing.

Mixing test types in one pilot blurs failure diagnosis.

Riskiest assumption test (RAT)

The RAT (riskiest assumption test, cheapest experiment that could falsify the highest-impact uncertain belief) for RelayOps before full build is dispatcher task test on paper prototype during shadowed live call volume, measuring whether dispatcher completes rebalance logging within 120 seconds.

RAT precedes polished UI. Failure saves $90,000+ build burn.

Kill criteria pre-registered: <60% task completion in shadow tests → pause build.

Pre-registration and interpretation rules

Pre-register success, fail, and inconclusive bands before data collection. Inconclusive triggers sample expansion, not hero narrative.

RelayOps documents interpretation rules in gate memo appendix signed by Maya and Jordan.

Assumption tests without code

Many tests are sales instruments: paid pilot deposits, LOI with metrics, letter from COO confirming budget line. Code is not required to falsify buying authority.

RelayOps runs deposit test with three firms: $5,000 refundable pilot deposit toward first month if metrics hit. Converts WTP from stated to level 2 evidence.

Jordan proposes 5-week emergency queue build. Maya demands RAT on dispatcher adoption first using paper prototype and stopwatch during 8 shadows.

Part A: RAT design

Hypothesis: ≥70% of rebalance events can be logged in paper prototype within 120 seconds during live call periods.

Sample: 8 shadows, 5+ rebalance events each → 40+ events.

Kill: <60% completion or median time >180 seconds.

Part B: Cost comparison

RAT cost: 40 founder hours + $0 build ≈ $3,000 opportunity cost.

Full build: 5 weeks × ~$9,000/week ≈ $45,000.

Check: RAT <10% of build cost ✓

Part C: Outcome simulation

If kill triggers, defer build, run dispatcher exit interviews, consider concierge routing MVP per ENT 402 path.

Part D: Managerial read

Board: "Why delay build?" Answer: "A3 risk score 25. A failed build leaves ambiguous diagnosis. RAT spends $3k to avoid $45k ambiguous burn."

HeatRoute (fictional) assumed owners would sign $200k annual contracts without testing dispatcher adoption. LOIs looked great; usage died week two. RelayOps ranks adoption before contract size.

A4 integration: 4/5 IT calls estimate 75-120 day security review. A1 buying: 3/5 managers say owner must sign >$5k/month.

Tasks: (1) Update risk scores for A4 and A1. (2) Name next RAT for A1 without code. (3) Adjust MVP timeline if both hold.

Solution

(1) A4 uncertainty →5, risk 15; A1 impact stays 5, uncertainty →5, risk 25.

(2) Owner sign-off test: 5 COO calls with written pilot budget confirmation or deposit from owner email.

(3) Add 8 weeks to sales cycle; reduce burn scope; target $99/tech pilot under owner threshold with written SOW.

Check: both assumptions now rank with A3 for attention ✓

Key takeaways

• Assumption ledgers rank impact × uncertainty with owners and dates.
• RAT spends the least cash to falsify the riskiest belief.
• Pre-register success, fail, and inconclusive interpretation rules.
• Desirability, feasibility, and viability tests stay separated.
• Non-code instruments (deposits, SOWs) test buying assumptions.

1. Score three RelayOps assumptions with I and U.
2. Design a no-code RAT for A1 buying authority.
3. Continue to Lesson 4: Demand Signals and False Positives.

Applying Testing Assumptions at RelayOps

When RelayOps applies testing assumptions, 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 customer validation and interview evidence 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 testing assumptions 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 testing assumptions. 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 customer validation and interview evidence 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. Testing Assumptions 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 401. 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 testing assumptions, 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 testing assumptions 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 testing assumptions 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. Testing Assumptions is how teams convert stories into capital-efficient learning.

Applying Testing Assumptions at RelayOps

When RelayOps applies testing assumptions, 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 customer validation and interview evidence 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 testing assumptions 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 testing assumptions. 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 customer validation and interview evidence 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. Testing Assumptions 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 401. 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 testing assumptions, 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.