DEV Community

Alan Descure
Alan Descure

Posted on Originally published at smtm-store.pages.dev

opportunity-discovery: a practical guide

Opportunity Discovery: A Practical Guide for When You're Stuck

The Problem in Concrete Terms

You have time, skills, and maybe some capital. What you don't have is a clear signal on what to build or pursue next. Every idea feels either too small, too crowded, or too vague to commit to. You've read about "finding problems worth solving" but when you sit down to do it, you produce either a list of trivial annoyances (better to-do app, nicer weather widget) or massive systemic issues you can't touch (healthcare reform, climate change).

The stuckness shows up in specific ways:

  • You open a blank document to brainstorm and close it 20 minutes later with nothing usable
  • You've validated three ideas in the past year and killed all of them after talking to 5–10 people
  • You keep returning to "scratch your own itch" but your itches are either already solved or too niche to support a business
  • You consume endless content about opportunity discovery (newsletters, podcasts, frameworks) but none of it translates into a decision
  • You feel paralyzed by opportunity cost: picking one means not picking the others, and you have no confidence in your filtering criteria

This isn't "I need more ideas." This is "I need a reliable process to filter and commit."


Why the Usual Fixes Fail

1. "Talk to customers" without a hypothesis

You schedule calls hoping the customer will hand you a problem. They won't. They'll describe symptoms, workarounds, and feature requests for existing tools. Without a specific hypothesis to test, you collect noise, not signal.

2. Market research reports and trend databases

These tell you where the market was 6–18 months ago. By the time a trend appears in a report, the early opportunity window has narrowed. They're useful for context, not for finding your entry point.

3. "Build something for yourself" taken literally

Your personal problems are real but rarely representative. Unless you're in a role/industry with many peers sharing the exact same workflow, you'll build a tool for an audience of one.

4. Idea generation frameworks (SCAMPER, Jobs-to-be-Done, etc.)

These are thinking tools, not discovery processes. They help structure exploration but don't tell you where to explore or when to stop. You can run JTBD interviews indefinitely without converging.

5. Waiting for "founder-market fit" to strike

This is passive. Founder-market fit is built through deliberate exposure to a domain, not discovered by introspection.


Step-by-Step Solution

Phase 1: Define Your Constraints (Days 1–2)

Before looking outward, define the box you're searching inside. Write down honest answers to:

  • Time horizon: How long can you work without revenue? (3 months? 12? 24?)
  • Capital: What can you invest without jeopardizing your baseline?
  • Team: Solo? Co-founder? Willing to hire contractors?
  • Distribution advantage: What channels do you already have access to? (Email list, community, industry network, SEO domain authority, paid ad skill, cold outreach skill)
  • Technical ceiling: What can you build yourself vs. need to hire for?
  • Domain depth: Which industries/roles do you understand well enough to spot fake problems?
  • Exit criteria: What does "good enough to commit" look like? (e.g., "10 people say they'll pay $X/month" or "I can get 5 pilot users in 2 weeks")

Output: A one-page "Opportunity Filter" document. Every idea gets scored against this. If it fails a hard constraint, discard it without guilt.


Phase 2: Map Your Adjacent Possible (Days 3–7)

Don't search broadly. Search adjacent to what you already know. List:

A. Roles you've held (current + past 5 years)

For each: core workflows, tools used, handoffs, complaints heard, spreadsheets that shouldn't be spreadsheets, manual workarounds.

B. Communities you're embedded in

Slack/Discord groups, forums, subreddits, professional associations, conferences, newsletters you read. Where do people ask "how do I...?" or "does a tool exist for...?"

C. Problems you've paid to solve

Software subscriptions, consultants, agencies, courses, workarounds you've funded. What did you pay for? What was still broken after paying?

D. Upstream/downstream of your expertise

If you're a frontend engineer: designers (upstream), backend/API teams (downstream), QA, product managers, devops. If you're in B2B sales: marketing (lead gen), customer success (onboarding), revops (tooling).

Action: For each item above, write 3–5 "friction statements" in this format:

[Role/Person] spends [time/frequency] doing [manual task] because [tool gap/process break], resulting in [wasted time/errors/revenue loss].

Example:

Marketing ops managers spend 4–6 hours/week manually reconciling UTM parameters across ad platforms because naming conventions drift, resulting in misattributed pipeline and wasted ad spend.

Output: 30–50 friction statements. No filtering yet—just capture.


Phase 3: Rapid Disqualification (Days 8–10)

Score each friction statement against your Opportunity Filter. Hard constraints first:

  • ❌ Requires regulatory expertise you don't have
  • ❌ Sales cycle > 6 months but you need revenue in 3
  • ❌ Needs enterprise distribution you can't access
  • ❌ Technical complexity exceeds your build capacity + budget

Then soft constraints (score 1–5):

  • Pain intensity: Is this a "hair on fire" problem or a "nice to fix"?
  • Frequency: Daily/weekly/monthly/quarterly?
  • Budget ownership: Who pays? Do they have budget authority?
  • Switching cost: How hard to displace current workaround?
  • Your unfair advantage: Distribution, domain knowledge, technical approach, network?

Keep only statements scoring ≥ 18/25 on soft constraints and passing all hard constraints.

Output: 3–5 qualified problem areas. Not ideas—problem areas.


Phase 4: Micro-Validation (Days 11–21)

For each qualified problem area, run a 3-day validation sprint. Do not build. Do not make a landing page. Do not run ads.

Day 1: Find 10 people who have this problem

Use your mapped communities. Cold DM/email with a specific ask:

"I'm researching how [role] handles [specific workflow]. Not selling anything. 10-minute call, I'll share what I learn from 10 others like you."

Target people who currently do the workflow, not people who "would be interested."

Day 2: Run structured interviews

Use this exact script:

  1. "Walk me through the last time you did [workflow]."
  2. "What tools/processes did you use?"
  3. "Where did it break or slow down?"
  4. "What did you do when it broke?" (reveals current workaround)
  5. "Have you looked for a better way? What did you try?"
  6. "If magic wand: what would the ideal solution do?"
  7. "Who else on your team deals with this?"
  8. "If a solution existed that [specific value prop], what's the max your team would pay monthly?"

Day 3: Synthesize

Create a one-pager per problem area:

  • Verbatim quotes on pain
  • Current workarounds + costs (time/money)
  • Budget signals (what they pay now, what they'd pay)
  • Decision-maker identified?
  • Your confidence score (1–10) on: pain reality, budget existence, accessibility

Kill criteria: If fewer than 3/10 confirm the problem and have budget and you can reach the decision-maker, kill the problem area. Move to the next.


Phase 5: Commit to a Wedge (Day 22)

You now have 1–2 problem areas with evidence. Pick one. Define your wedge: the smallest, highest-value slice you can build and deliver in 4–6 weeks.

Wedge criteria:

  • Solves one step of the workflow completely
  • Deliverable as a productized service, no-code tool, or minimal code
  • Priced at 10–20% of the customer's current cost (time

Start here

Top comments (0)