Opportunity Discovery: When "Find a Problem" Isn't Working
The Problem in Concrete Terms
You've read the advice: "Talk to customers," "Scratch your own itch," "Look for complaints on Reddit." You've done the interviews. You've scanned the forums. You've listed fifty problems. And you're still stuck—either because every problem feels too small, too crowded, too hard to monetize, or because you can't tell which ones are real versus just loud.
The stuckness usually looks like one of three things:
- The "So What?" Problem: You found a genuine pain point, but the people who have it won't pay to solve it. They workaround. They complain. They don't buy.
- The "Already Solved" Problem: Every problem you find has three funded competitors and a graveyard of failed attempts. You can't articulate why you would win.
- The "Vague Hunch" Problem: You sense an opportunity in a space you know (your industry, your hobby, your workflow), but you can't sharpen it into a specific, testable hypothesis. You're paralyzed by the gap between "this feels broken" and "here's a product people will pay for."
The common thread: you're treating opportunity discovery as research when it's actually hypothesis generation under uncertainty. Research gathers facts. Hypothesis generation makes bets. You're stuck because you're trying to research your way to certainty before placing a bet—and that certainty doesn't exist.
Why the Usual Fixes Fail
Customer interviews fail when you ask "What problems do you have?" People invent problems they think you want to hear, or they describe symptoms without root causes. They can't tell you what they'd pay for because they don't know what's possible.
Scratch-your-own-itch fails when your itch is too niche, too idiosyncratic, or already solved by a tool you haven't found yet. It also fails when you're the only one with that itch.
Forum/complaint mining fails because complaints are noise. People complain about things they'll never pay to fix. They complain about pricing, about missing features that only they want, about bugs in free tools. The signal-to-noise ratio is terrible without a filter.
Market sizing spreadsheets fail because TAM/SAM/SOM for a new opportunity is fiction. You're multiplying guesses by assumptions. The precision creates false confidence.
Competitor analysis fails when you study what exists instead of what's missing. You end up building a "better" version of a product nobody wants, or you talk yourself out of a space because "it's crowded" without understanding why the incumbents are vulnerable.
All these methods share a flaw: they assume the opportunity is out there waiting to be discovered. It's not. An opportunity is a match between a specific problem, a specific audience, a specific solution approach, and a specific go-to-market motion. You don't find it. You construct it—and then you test whether the construction holds.
Step-by-Step Solution: From Vague Space to Testable Hypothesis
Step 1: Pick a Hunting Ground You Can Actually Reach
Stop hunting "everywhere." Pick one domain where you have either:
- Access: You can reach decision-makers this week without cold outreach (former colleagues, communities you're in, industries you've worked in)
- Insight: You understand the workflow, constraints, and language better than 90% of outsiders
Write down the domain. Be specific: not "healthcare" but "outpatient physical therapy clinics with 3-10 providers." Not "e-commerce" but "Shopify merchants doing $100K-$2M/year who manage their own fulfillment."
If you have multiple domains, rank them by (access × insight) and pick the top one. You can run this process in parallel later. For now, one.
Step 2: Map the Workflow, Not the Problems
Get access to 3-5 people in that domain. Don't interview them about problems. Watch them work.
Ask: "Can I screen-share for 30 minutes while you do [core task: scheduling, quoting, reporting, onboarding, inventory reconciliation]?" Take timestamped notes on:
- Every tool they switch between
- Every copy-paste, export-import, manual calculation
- Every "I have to remember to..." or "I always forget to..."
- Every spreadsheet that shadows a SaaS tool
- Every time they ask a colleague "Hey, did you...?"
- Every complaint about their current stack—especially the ones they've stopped complaining about because "that's just how it is"
You're not looking for problems. You're looking for friction that has become invisible to them.
Do this with 3-5 people. Pattern-match across the sessions. The opportunities live in the overlaps.
Step 3: Extract Candidate Opportunities Using the "Three Filters"
For each friction pattern you observed, write a one-sentence candidate in this format:
[Specific role] spends [time/frequency] doing [manual workaround] because [root constraint], and they'd pay [proxy for value] to eliminate it.
Example: "Clinic office managers spend 4-6 hours/week manually reconciling insurance payments against bank deposits because their EHR doesn't auto-match remittance codes, and they'd pay $200-400/mo to eliminate it."
Now apply three filters. Kill any candidate that fails any filter.
Filter 1: Budget Authority Access
Can the person feeling the pain also sign the check? Or is there a clear, short path to the buyer? If the office manager feels the pain but the clinic owner decides—and you can't reach clinic owners—kill it. You don't have a distribution path.
Filter 2: Workaround Cost > Switching Cost
Quantify the current workaround in hours × hourly rate (or revenue loss). Compare to your estimated implementation effort for them. If the workaround costs $500/mo in time and your tool takes 20 hours to onboard, that's a 4-month payback. Acceptable. If payback is 18 months, kill it.
Filter 3: No Strategic Incumbent Lock-in
Is the friction caused by a missing feature in their core system (EHR, ERP, POS)? If yes, the incumbent will build it—or already has it on the roadmap. You're a feature, not a product. Kill it unless you have a structural reason they won't/can't (regulatory, architectural, business model conflict).
You should have 3-8 candidates surviving. If zero, go back to Step 2 with a different hunting ground.
Step 4: Sharpen Each Survivor into a Testable Hypothesis
For each surviving candidate, write a hypothesis card with these fields:
| Field | Example |
|---|---|
| Target | Office managers at 3-10 provider PT clinics |
| Pain | Manual insurance payment reconciliation (4-6 hrs/wk) |
| Current Workaround | Export CSVs from EHR + bank, VLOOKUP in Excel, flag mismatches |
| Why Now | Payers shifting to ERA/835 but EHRs lag on auto-posting; clinics adding providers faster than admin headcount |
| Solution Concept | Browser extension that reads bank + EHR exports, auto-matches, surfaces exceptions |
| Value Proxy | $300/mo = 10 hrs saved @ $30/hr loaded cost |
| Go-to-Market | Direct to office managers via PT billing Facebook groups + state association newsletters |
| Riskiest Assumption | Office managers can install a browser extension without IT approval |
| Test | Build a Google Sheet + Apps Script prototype; get 3 offices to use it for 2 weeks; measure time saved |
The Riskiest Assumption and Test fields are the only ones that matter. Everything else is context. If you can't name a specific, cheap test that would falsify your riskiest assumption in 2 weeks, the hypothesis isn't sharp enough. Sharpen or kill.
Step 5: Run the Cheapest Test That Could Fail
Do not build an MVP. Do not design a landing page. Do not set up ads.
Run the test from your hypothesis card. The test must:
- Cost < $100 and < 20 hours of your time
- Produce a clear pass/fail signal on the riskiest assumption
- Involve real people from your target doing real work (or a realistic simulation)
Examples of valid tests:
- Concierge: You manually do the task for 3 users using their actual data; measure time/errors vs. their current process
- Wizard of Oz: Build a form that looks automated;
Top comments (0)