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 sell. Every idea feels either too small to matter, too crowded to enter, or too vague to act on. You've read about "finding your niche" and "scratching your own itch," but your itches are either already solved or not monetizable. You've tried brainstorming sessions, trend reports, and competitor analysis—yet you keep landing on ideas that feel derivative, risky, or simply unexciting.

The stuckness isn't a creativity deficit. It's a filtering problem. You're generating possibilities but lack a reliable way to test them against reality before committing months of work. You need a process that moves you from "maybe this could work" to "here's evidence this works" without requiring a full build.


Why the Usual Fixes Fail

1. "Scratch your own itch" assumes your problems are representative and monetizable. They often aren't. Your workflow quirks might be too idiosyncratic, or the solution might be a feature, not a product.

2. Trend-chasing (AI wrappers, no-code tools, Web3) puts you in a crowd of thousands with the same timing. By the time a trend is visible in newsletters, the low-hanging fruit is gone.

3. Keyword research and SEO analysis reveal demand for information, not necessarily for paid solutions. People search for free tutorials; they pay for outcomes.

4. Competitor analysis teaches you what worked for them under their conditions—audience, timing, capital, distribution. Copying their surface-level features misses the underlying mechanics.

5. "Talk to customers" is correct but incomplete. Without a hypothesis and a concrete artifact to react to, conversations drift into polite feature requests that don't predict purchase behavior.

6. Building an MVP to test is expensive validation. You're committing engineering time before you know if the problem is real, urgent, and paid for.


Step-by-Step Solution

Phase 1: Map Your Asymmetric Advantages (Days 1–2)

List every asset you control that others don't. Be ruthlessly specific.

Category Prompts Example Output
Technical APIs you've integrated, infra you've scaled, weird bugs you've fixed "Built real-time sync for 50k+ concurrent users on Firebase"
Domain Industries you've worked in, regulations you've navigated, workflows you've owned "Implemented HIPAA-compliant data pipelines for 3 health-tech startups"
Distribution Newsletters you run, communities you moderate, SEO authority you hold "Run a 4.2k-subscriber newsletter for indie SaaS founders (42% open rate)"
Capital/Labor Cash you can deploy, contractors you trust, co-founders aligned "$15k risk capital + designer who owes me a favor"
Taste/Judgment Products you've killed, bets you've won, patterns you recognize "Correctly predicted 3/4 YC W23 batch failures from demo day videos"

Action: Write 15–20 items. Keep only the ones that are provable and hard to replicate. Discard "I'm a fast learner" or "I know Python."

Phase 2: Generate Problem Hypotheses from Advantage Intersections (Days 3–4)

Cross-reference your advantages. Each intersection is a hypothesis: "Because I have [Advantage A] and [Advantage B], I can solve [Problem] for [Buyer] better than alternatives."

Template:

Advantage 1: [Specific asset]
Advantage 2: [Specific asset]
Buyer: [Role, company size, context]
Problem: [Specific, recurring, expensive pain]
Current Workaround: [What they do now, why it fails]
Why Me: [Why your intersection makes this winnable]

Example:

Advantage 1: Built HIPAA pipelines for 3 startups
Advantage 2: Run newsletter for 4.2k health-tech founders
Buyer: CTO at Series A digital health company (50–200 employees)
Problem: De-identifying PHI for ML training takes 4–6 weeks per dataset and fails audits 30% of the time
Current Workaround: Manual scripting + external consultants ($15k–40k/project)
Why Me: I've solved the technical edge cases; I have direct access to buyers; I know the audit failure patterns

Action: Produce 8–12 hypotheses. Keep only those where:

  • The buyer has budget authority (not just influence)
  • The problem recurs (not one-off)
  • The workaround is demonstrably expensive (time, money, risk)
  • Your advantage intersection is causal to the solution, not decorative

Phase 3: Design a "Smoke Test" for Each Hypothesis (Days 5–7)

A smoke test is a concrete artifact that elicits a binary signal from a real buyer. Not a landing page. Not a survey. An artifact.

Hypothesis Type Smoke Test Artifact Success Signal
Service/agency One-page scope + fixed price + 2-week delivery guarantee Buyer signs SOW and pays deposit
SaaS tool Clickable Figma prototype + pricing page + Calendly for paid pilot Buyer books pilot and pays $500–2k setup fee
Data/productized Sample deliverable (real data, real format) + Loom walkthrough Buyer requests full dataset and negotiates contract
Marketplace Curated list of 20 vetted suppliers/buyers + intro email template Both sides reply asking for intros
Content/course Module 1 delivered free + paid upgrade path 20%+ of recipients purchase within 7 days

Rules:

  • Build the artifact in ≤ 8 hours. If it takes longer, scope it down.
  • Price it. Free signals interest; paid signals value.
  • Target 5–10 specific buyers per hypothesis. Use your distribution advantages (newsletter, LinkedIn, warm intros).
  • Track: contacted → replied → meeting → paid/letter of intent.

Action: Run smoke tests in parallel. Kill hypotheses that don't generate ≥ 1 paid signal or LOI from 10 contacts. Keep the 1–2 that do.

Phase 4: Validate the Economics (Days 8–14)

For each surviving hypothesis, answer these with numbers, not adjectives.

Question How to Answer
What's the TAM for this specific wedge? Count buyers in your ICP on LinkedIn/Sales Navigator × average contract value. Ignore total market size.
What's the CAC? (Hours to close × your hourly rate) + ad spend + tooling. Divide by closed deals.
What's the payback period? CAC / (monthly margin per customer). Must be ≤ 6 months for bootstrapped; ≤ 12 for funded.
What's the expansion path? List 3 adjacent problems the same buyer has. Can you upsell without new distribution?
What's the moat at 10 customers? 100? Data network effects? Switching costs? Brand? Regulatory? If "nothing," it's a service, not a product.

Action: Build a simple spreadsheet. If the math doesn't work at your target scale (lifestyle vs. venture), kill it or reshape the wedge.

Phase 5: Commit to a Wedge and Ship V1 (Day 15+)

You now have:

  • A specific buyer you can reach
  • A problem they pay to solve
  • Evidence they'll pay you
  • Economics that work at your target scale

Build the smallest thing that delivers the paid outcome. Not the full vision. The wedge.

Constraints for V1:

  • Timebox: 4–6 weeks max. If longer, slice thinner.
  • Manual first: Use humans behind the API. Automate only what breaks.
  • Instrument: Log every user action, support request, and churn signal.
  • Price from day one: No "beta free" unless you're testing a network effect.

Short Checklist

  • [ ] Listed 15+ provable, hard-to-replicate advantages
  • [ ] Generated 8+ hypotheses from advantage intersections
  • [ ] Filtered to hypotheses with

Start here

Top comments (0)