theonline.mba
← Back to unit 1: Opportunity Discovery

ENT 301 · Unit 1 · Lesson 3 of 5

Problem Discovery

Opportunity Discovery

Lesson

Problem discovery names the job before the product

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 (Customer Discovery and Opportunity Validation) 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.

Problem discovery is the disciplined search for pains customers already pay to cope with, described in their workflow language, narrow enough to test in weeks. RelayOps did not discover "field service software." It discovered that operations leaders at 80-200 technician HVAC and plumbing firms lose same-day capacity when dispatchers rebalance schedules across phone calls, whiteboards, and CRM tabs without live skill, location, and parts visibility.

Problem discovery differs from brainstorming. Brainstorming generates ideas. Problem discovery generates hypotheses with segments, symptoms, and falsifiers. The output is a ranked problem stack, not a feature list.

With $400,000 runway and $45,000 monthly burn, RelayOps cannot discover twelve problems deeply. It must discover one problem worth six weeks of structured interviews before MVP spend.

Problem-first framing and the job story

A job story describes situation, motivation, and outcome without your solution: "When a senior tech calls in sick during a heat wave, I need to rebalance same-day jobs without losing SLA windows, so I avoid overtime and angry maintenance-plan customers." RelayOps founders test whether dispatchers and operations leaders tell versions of that story unprompted.

Problem-first framing forbids leading with "AI dispatch platform." Cover the product name and read the job story aloud. If operators nod and add details ("and parts are on the wrong truck"), you have language fit. If they ask what your software does, you are still solution-first.

Narrow jobs beat category labels. "Scheduling" is too broad. "Same-day rebalance under live call load" is testable in interviews and shadows.

Hypothesis stacks and parallel explore

RelayOps generated five hypotheses (H1 dispatch rebalance, H2 parts stockouts, H3 technician onboarding, H4 unreliable appointment windows, H5 invoice disputes). Parallel explore with time caps prevents emotional attachment to the first idea.

Each hypothesis carries a learning budget: max interviews, max founder hours, review date. H2 stalled because stockout pain clustered in firms with immature inventory modules, a different buyer. H3 showed low frequency outside hiring season. H1 accumulated severity, frequency, and spend signals fastest.

Problem discovery ends explore when one hypothesis clears promotion rules to validate. Promotion is a decision, not a vibe.

RelayOps explore-stage hypothesis snapshot:

IDProblemPromoted?Reason
H1Same-day dispatch rebalanceYesPain + frequency + overtime spend
H2Parts stockoutsPausedBuyer/integration path diverges
H3Tech onboardingPausedSeasonal frequency
H4Unreliable windowsMonitorSymptom linked to H1
H5Invoice disputesNoWeaker founder edge

Pain intensity, frequency, and existing spend

Three filters separate hobbies from opportunities. Pain intensity: does the problem hit revenue, cost, or risk metrics operations leaders defend? Frequency: does it happen weekly, not annually? Existing spend: do firms already buy overtime, modules, temp staff, or consultants to cope?

RelayOps H1 clears all three: 10-15% overtime on peak weeks, daily rebalance fires during weather spikes, spend on aftermarket scheduling tools and dispatcher headcount.

Problems with intensity but no spend may be vitamins. Problems with spend but low frequency may be services businesses, not SaaS.

Observation: shadows and artifacts

Interviews reveal language; shadowing reveals sequence and timing. RelayOps pairs every third interview with a dispatch shadow. Discrepancies between recall and observation are high-value learning.

Artifacts include overtime PDFs, CRM screenshots, whiteboard photos, and SLA penalty reports. Artifacts upgrade evidence from anecdote to pattern when multiple firms show similar workarounds.

Ethics require consent and minimal disruption. No shadows during 911-level peaks unless invited.

Translating dispatcher pain to buyer metrics

Users feel tab chaos; buyers fund overtime and SLA metrics. Problem discovery must translate: "five tabs" becomes "14% overtime on heat weeks when rebalance loops exceed ten minutes."

Budget-hook probes: "What did you spend last quarter coping with same-day schedule breaks?" Answers reveal whether economic buyers exist.

RelayOps stops discovery on user enthusiasm alone. COO must recognize metric language.


Worked example: RelayOps H1 promotion decision

After 12 exploratory calls and 4 shadows, Maya synthesizes evidence for H1 dispatch rebalance versus H4 appointment reliability.

Part A: Evidence table

SignalH1 rebalanceH4 unreliable windows
Unprompted mention9/12 calls6/12 calls
Weekly frequency cited11/128/12
Quantified overtime7/123/12
Existing software spend8/124/12
Dispatcher shadow time >10 min loop4/4 shadows2/4 shadows

Part B: Problem statement (promoted)

Operations leaders at 80-200 technician residential-heavy HVAC and plumbing firms lose profitable same-day capacity because dispatchers rebalance schedules across disconnected tools without live skill, location, and parts visibility, producing 10 to 15 percent overtime on peak weeks and missed first-visit appointment windows and missed first-visit windows.

Part C: Kill criterion for validate stage

If fewer than six of ten structured interviews describe same-day rebalance pain unprompted, RelayOps pauses H1 and reopens H4/H2 comparison.

Check: promotion threshold 6/10 = 60% unprompted prevalence ✓

Part D: Managerial read

Investor read: H4 is real but often downstream of H1. Solving rebalance may improve window reliability; solving reviews alone may not fix dispatch loop. Promote the causal job.


Worked example: Contrast: problem discovery as feature survey

RouteBuddy (fictional) asked prospects to rank 20 features from a spreadsheet. Prospects checked many boxes. Founders built top five features. Dispatchers used none during live emergencies because the core job (rebalance when demand spikes) was never isolated. Feature surveys discover preferences, not jobs.


Common mistakes beginners make

MistakeReality
Starting from technology capabilityDiscover jobs customers already struggle to finish
Accepting broad category painNarrow to weekly, high-stakes workflows
Trusting user enthusiasm without buyer metricsTranslate symptoms into overtime and SLA language
Running explore without time capsParallel hypotheses need scheduled kill dates
Skipping shadowsRecall smooths chaos; observation reveals loops

Practice problem

Interview notes: 7/10 dispatchers mention "customers angry about windows." Only 4/10 mention rebalance loops. COO cites online reviews, not overtime.

Tasks: (1) Is this H1 or H4 evidence? (2) What shadow metric would clarify causality? (3) Write one budget-hook question for the COO. (4) Recommend promote, pause, or deepen discovery.

Solution

(1) Mixed H4 symptom with partial H1 mechanism; insufficient to demote H1 alone.

(2) Time rebalance loop length and correlate with missed window rate same day.

(3) "What did overtime and SLA penalties cost last peak month versus review remediation spend?"

(4) Deepen discovery: 4 more shadows focused on heat-week days; promote only if rebalance loops predict window misses.

Check: need ≥6/10 unprompted H1 before validate ✓

Key takeaways

  • Problem discovery produces ranked, narrow job hypotheses, not feature lists.
  • Promote problems with intensity, frequency, and existing spend.
  • Shadows and artifacts upgrade interview recall into workflow truth.
  • Translate user language into buyer metrics before validation spend.
  • Write kill criteria when promoting a hypothesis to validate.

After this lesson

  1. Draft a job story for RelayOps without product nouns.
  2. Which RelayOps hypothesis would you pause if IT integration exceeds 60 days?
  3. Continue to Lesson 4: Market Trends and Timing.

Applying Problem Discovery at RelayOps

When RelayOps applies problem discovery, 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 opportunity discovery and problem selection 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 problem discovery 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 problem discovery. 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 opportunity discovery and problem selection 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. Problem Discovery 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 (Customer Discovery and Opportunity Validation). 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 problem discovery, 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 problem discovery 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 problem discovery 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. Problem Discovery is how teams convert stories into capital-efficient learning.

Applying Problem Discovery at RelayOps

When RelayOps applies problem discovery, 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 opportunity discovery and problem selection 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 problem discovery 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 problem discovery. 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 opportunity discovery and problem selection 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. Problem Discovery 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 (Customer Discovery and Opportunity Validation). ENT 301 integrates the full arc; electives provide textbook-depth units you can take after this core course.

Lesson exercise

30 min

H1 Promotion and Job Story Workshop

1. Complete the Practice Problem on mixed H1/H4 interview evidence (7/10 windows, 4/10 rebalance loops) without viewing the solution. 2. Draft a job story for RelayOps using situation-struggle-outcome with no product nouns. 3. Build the H1 evidence table (unprompted mention, weekly frequency, quantified overtime, shadow loops) and verify ≥6/10 promotion threshold logic. 4. Transfer: write one budget-hook COO question from the lesson and test it on a public field-service case. 5. Recommend promote, pause, or deepen discovery with one shadow metric that clarifies causality.

Deliverable

Job story, evidence table, budget-hook question, and promotion recommendation in your ENT 301 workbook.

Rubric

  • Job story avoids solution-first language
  • Evidence table distinguishes H1 mechanism from H4 symptom
  • Budget-hook ties to overtime or SLA spend, not reviews alone
  • Recommendation matches ≥6/10 unprompted rule from lesson