Opportunity Assessment

Not every problem is worth solving. You can find a real problem, validate that users experience it, confirm they will pay to solve it, and still make a bad bet because the market is too small, the competition is too entrenched, or your team is not the right one to win. Opportunity assessment is the discipline of evaluating whether a validated problem represents a good investment of your company's resources.

Why Assessment Matters

Product teams have finite time, money, and attention. Every initiative you pursue means several others you do not. The cost of building the wrong thing is not just the engineering time. It is the opportunity cost of what you could have built instead, plus the organizational cost of shipping, supporting, and maintaining something that does not move the needle.

The real cost of a bad bet:
  - 3 engineers x 3 months = 9 person-months of engineering
  - Designer time, PM time, QA time
  - Marketing effort to launch
  - Support burden for a feature nobody uses heavily
  - Technical debt that persists long after the feature is forgotten
  - Team morale hit from shipping something that doesn't matter
  - Opportunity cost: what would those 9 person-months have built?

Instagram's decision to kill standalone apps like Bolt and Direct (as a separate app) was an assessment discipline. The problems those apps addressed were real. The opportunity was not large enough relative to investing in the core product.

Assessment Criteria

Market Size

How many people have this problem? How much are they spending (or willing to spend) to solve it? Market size is not about total addressable market slides in pitch decks. It is about realistic estimation of who would actually buy your solution.

Market sizing approaches:

Top-down (rough, directional):
  "There are 500,000 SaaS companies globally. 60% have 10+ employees
   and need project management. 30% of those are dissatisfied with
   their current tool. That's 90,000 potential customers. At $50/month
   average, that's $54M annual revenue opportunity."

Bottom-up (more reliable):
  "We talked to 50 companies in our target segment. 12 said they would
   switch tools in the next year. 8 said they would pay $50-100/month.
   There are 5,000 companies similar to our sample. Conservatively,
   16% would switch (800 companies) at $50/month average = $480K
   annual revenue in year one."

Bottom-up is almost always more reliable. Top-down gives you comfort. Bottom-up gives you reality.

Frequency

How often does the user encounter this problem? Daily problems create habits. Weekly problems create tools. Monthly problems create utilities. Annual problems create services you forget exist.

Frequency and product viability:

Daily problems (strong):
  - Team communication (Slack)
  - Code editing (VS Code)
  - Task management (Linear)
  Users build habits. Retention is high. Switching costs accumulate.

Weekly problems (viable):
  - Expense reporting
  - Sprint planning
  - Performance dashboards
  Users remember the product. Usage is consistent but not habitual.

Monthly problems (harder):
  - Invoice creation
  - Competitive analysis
  - Quarterly planning
  Users forget how to use the product between sessions.

Annual problems (very hard):
  - Tax filing
  - Benefits enrollment
  - Annual reviews
  Users have to relearn the product every time.

Frequency determines whether your product becomes indispensable or forgettable. Slack succeeded partly because team communication is a daily, hourly problem. Products that solve daily problems can charge more, retain better, and grow faster.

Willingness to Pay

There is a gap between "I have this problem" and "I will pay to solve this problem." The gap is enormous and kills more products than any other factor.

Signals of willingness to pay:
  Strong signals:
    - User is currently paying for an inferior solution
    - User has built a custom internal tool (they're paying in
      engineering time)
    - User can quantify the cost of the problem in dollars
    - User has a budget line item for this category

  Weak signals:
    - User says "I'd pay for that" in an interview (hypothetical)
    - User signs up for a free trial (free is not paying)
    - User says the problem is "annoying" (annoyance is not urgency)

  No signal:
    - User says "that's a cool idea"
    - User shares your product on social media
    - User gives you a 5-star review on Product Hunt

Superhuman validated willingness to pay before building. They charged $30/month for email, which seemed absurd. But they found that professionals who spent 3+ hours per day in email and felt overwhelmed by volume would pay for speed and control. The willingness to pay was not hypothetical. People were already paying for email productivity tools, hiring assistants, and using complex filtering systems.

Competitive Landscape

Who else is solving this problem? How well? Where are the gaps?

Competitive analysis framework:

1. Direct competitors (same problem, same solution type):
   - Who are they?
   - What do they do well?
   - Where do their users complain?
   - How are they priced?
   - How fast are they shipping?

2. Indirect competitors (same problem, different solution type):
   - What workarounds do users have?
   - What adjacent products partially solve this?
   - What does "doing nothing" look like?

3. Competitive dynamics:
   - Is the market consolidating or fragmenting?
   - Are incumbents innovating or coasting?
   - Are there network effects or switching costs?
   - Is there a technology shift that changes the landscape?

Linear entered the project management market against Jira, Asana, Monday, Notion, and dozens of others. Their assessment was that the market was large, frequency was daily, willingness to pay was proven, and the competitive gap was "speed and developer experience." Jira had become slow and bloated. Linear bet that a fast, opinionated tool for software teams could carve out a meaningful segment. The assessment was correct.

Your Ability to Win

This is the most honest and most uncomfortable question. Given who your team is, what your technology stack looks like, and where your distribution advantages lie, can you actually win?

Honest capability assessment:
  - Do we have domain expertise in this space?
  - Do we have a technology advantage?
  - Do we have a distribution advantage (existing users, brand,
    partnerships)?
  - Can we build this with the team we have, or do we need to hire?
  - Is this aligned with our existing product or a new direction?
  - Do we have the patience for the timeline this requires?

Stripe could build financial infrastructure because they had deep payments expertise, engineering talent that understood distributed systems, and relationships with banks. A social media company with the same "build a payment platform" idea would fail because they lack all three.

Before committing resources, write a one-page opportunity assessment. One page forces clarity. If you cannot explain the opportunity in one page, you do not understand it well enough.

Opportunity Assessment: [Name]

Problem:
  [2-3 sentences. What is the problem? Who experiences it?]

Target User:
  [1-2 sentences. Who specifically? Not "everyone." Be precise.]

Size of Opportunity:
  [Bottom-up estimate. Number of potential users/customers.
   Revenue potential. Growth trajectory.]

Frequency & Severity:
  [How often? How painful? What's the cost of not solving it?]

Current Solutions:
  [What do users do today? What are they paying? What's broken
   about existing solutions?]

Our Advantage:
  [Why us? Why now? What do we have that competitors don't?]

Risks:
  [What could go wrong? What assumptions are we making?]

Investment Required:
  [Team size. Timeline. Other resources.]

Success Metrics:
  [How will we know this worked? What numbers move?]

Example: Filled Out

Opportunity Assessment: Team Standup Async Tool

Problem:
  Remote engineering teams waste 15-30 minutes daily in synchronous
  standup meetings. For globally distributed teams, no single time
  works for everyone, so some members always attend at inconvenient
  hours or skip entirely.

Target User:
  Engineering managers at remote-first companies with 10-50 person
  engineering teams distributed across 3+ time zones.

Size of Opportunity:
  ~25,000 remote-first companies with 10+ engineers (bottom-up from
  LinkedIn data). At $8/user/month, 30 users average = $240/month
  per company. If 5% convert in year one = $3.6M ARR.

Frequency & Severity:
  Daily. Every team member is affected. Manager spends 30 min/day
  facilitating. Engineers lose context-switching time. Distributed
  team members are systematically excluded.

Current Solutions:
  Slack threads (messy, no structure). Geekbot (basic, poor UX).
  Standup meetings on Zoom (the problem itself). Notion templates
  (manual, no aggregation).

Our Advantage:
  We already have 2,000 engineering teams using our tool for sprint
  planning. Adding async standups extends a workflow they already
  use daily. Distribution advantage is strong.

Risks:
  Slack might build this natively. Low switching costs between async
  standup tools. Risk of being "nice to have" not "must have."

Investment Required:
  2 engineers, 1 designer, PM (part-time). 8-week build.

Success Metrics:
  500 teams using weekly within 3 months. 70% weekly retention.
  10% conversion to paid within 6 months.

Scoring & Comparison

When comparing multiple opportunities, a simple scoring matrix helps make trade-offs explicit. Do not pretend the scores are precise. They are conversation starters.

Opportunity      Market  Freq  WTP  Competition  Our Fit  Total
-----------------------------------------------------------------
Async standups     6      9     5       5           8       33
Analytics dash     8      7     7       3           6       31
API marketplace    7      4     8       6           4       29
Team directory     4      6     3       7           9       29

Scale: 1 (worst) to 10 (best)
WTP = Willingness to Pay

The scores do not decide for you. They make the trade-offs visible. "Async standups scores highest because frequency and fit are strong, but willingness to pay is uncertain." Now you can have a focused conversation about the real risk.

When to Kill an Opportunity

Assessment is not a one-time gate. It is an ongoing evaluation. Some signals that an opportunity should be killed or paused:

Kill signals:
  - User interviews consistently reveal lukewarm interest
  - Bottom-up market sizing keeps shrinking as you learn more
  - You cannot articulate your advantage in one sentence
  - The competitive landscape shifted (a major player launched
    something similar)
  - Early prototype testing shows low engagement
  - The required investment keeps growing as you uncover complexity
  - Your team does not believe in the opportunity (and they're
    usually right about this)

Amazon is famous for killing products. The Fire Phone was killed. Amazon Destinations (hotel booking) was killed. They assess relentlessly and cut when the opportunity does not hold up. Most companies are too slow to kill and too fast to start.

Common Pitfalls

Falling in love with the solution before assessing the opportunity. You already built a prototype and now you are looking for a market. Assessment should come before building, not after.
Top-down market sizing only. "The market for X is $50 billion" means nothing. Who specifically will buy your product and why?
Ignoring your ability to win. The opportunity can be real and large and still be wrong for your team. Honesty about fit is essential.
Treating the one-pager as a formality. If leadership rubberstamps every opportunity assessment, the exercise is theater. The one-pager should generate genuine debate about whether to proceed.
Analysis paralysis. Assessment should take days, not months. You are making a decision under uncertainty. Gather enough information to have conviction, then commit. You can always kill the initiative later if you learn something that changes the picture.
Anchoring on sunk costs. "We already spent a month on this" is not a reason to continue. If the opportunity assessment reveals the bet is bad, stop.

Key Takeaways

Not every validated problem is worth solving. Assess opportunities across market size, frequency, willingness to pay, competitive landscape, and your ability to win. Use bottom-up market sizing, not top-down. Write a one-page assessment that forces clarity. Use scoring to make trade-offs explicit, not to automate decisions. Kill opportunities aggressively when the data does not support them. The cost of building the wrong thing is not just engineering time; it is the opportunity cost of what you did not build.