Finding Problems Worth Solving

Most products fail not because they are built badly, but because they solve the wrong problem. The graveyard of startups is full of beautifully engineered solutions to problems nobody has. Finding a real problem, one that people experience frequently, feel acutely, and will pay to solve, is the single most important thing a PM does. Everything else is downstream.

Why This Is Hard

Human beings are naturally drawn to solutions. When someone says "we should build a product," they almost always start with what the product does, not what problem it solves. This is backwards, and it kills more products than bad engineering, bad design, or bad marketing combined.

Solution-first thinking (dangerous):
  "Let's build an AI-powered meeting scheduler."

Problem-first thinking (correct):
  "Scheduling meetings across time zones with external participants
   takes an average of 7 email exchanges and 15 minutes per meeting.
   For salespeople who schedule 10+ meetings per week, this is a
   significant time sink that directly reduces selling time."

The first framing tells you what to build. The second tells you what to solve. The solution might end up being an AI scheduler. Or it might be a shared availability link. Or it might be a Calendly competitor with better time zone handling. You do not know yet, and that is the point.

How to Find Real Problems

Talk to Users

This sounds obvious. It is not done nearly enough. Most PMs spend less than 10% of their time talking to actual users. The ones who build great products spend 20-30%.

Talking to users does not mean sending a survey. Surveys tell you what people say they want. Observation tells you what they actually need. These are different things.

Effective user research:
  - Watch someone use your product (or your competitor's product)
  - Ask them to narrate what they're doing and why
  - Notice where they hesitate, backtrack, or express frustration
  - Ask about their workflow before and after using the product
  - Ask what workaround they used before your product existed

Ineffective user research:
  - "What features would you like us to add?"
  - "Would you use a product that does X?"
  - "On a scale of 1-10, how much do you like this?"
  - Any question that can be answered with yes or no

When Airbnb's founders were struggling to get traction, they did something radical: they flew to New York and stayed with hosts. They watched hosts prepare listings, take photos, set prices, and communicate with guests. They discovered that listing photos were terrible because hosts used phone cameras and bad lighting. The solution was not a better photo upload feature. It was sending professional photographers to hosts for free. They found the problem by watching, not by asking.

Observe Behavior

What people do is more reliable than what people say. Analytics, session recordings, and usage data reveal problems that users cannot articulate.

Behavioral signals that indicate a problem:
  - High drop-off at a specific step in a flow
  - Users repeatedly visiting a page without taking action
  - Workarounds (users exporting data to Excel to do something
    your product should handle)
  - Feature adoption that spikes and then drops
  - Support tickets clustered around the same issue
  - Users rage-clicking or rapidly navigating back and forth

Spotify noticed that users were creating playlists called things like "Monday Morning," "Workout," and "Chill." The behavior data showed that people wanted music organized by context and mood, not just by artist or genre. This insight led to algorithmic playlists and eventually Discover Weekly. Users never asked for an algorithm. Their behavior asked for it.

Read Support Tickets

Support tickets are an underrated gold mine. They represent problems that users care enough about to spend time reporting. Most PMs ignore them because support feels like someone else's job.

How to mine support tickets:
  1. Pull the last 500 tickets
  2. Categorize them by problem type (not by feature area)
  3. Look for clusters: which problems appear most frequently?
  4. Look for severity: which problems cause the most frustration?
  5. Look for workarounds: what are users doing to solve the problem
     themselves?
  6. Talk to the support team directly: "What are you tired of
     answering?"

At Notion, support tickets about table limitations (no rollup fields, no relation filters) directly influenced the product roadmap. The support team was spending hours every week helping users build workarounds for things that should have been product features.

Study Competitors' Reviews

App store reviews, G2 reviews, and Reddit complaints about competitors tell you what problems exist in the market that nobody is solving well.

What to look for in competitor reviews:
  - 2-star and 3-star reviews (not 1-star, which are often noise)
  - Phrases like "I wish it could..." or "The only thing missing is..."
  - Patterns across multiple reviews
  - Workarounds users describe
  - Complaints about pricing (indicates willingness to pay for a
    better alternative)

The Mom Test

Rob Fitzpatrick's "Mom Test" is the best framework for conducting user interviews that produce real signal. The name comes from the idea that even your mom would give you useful feedback if you asked the right questions, because the questions do not let her lie to you.

The Three Rules

Rule 1: Talk about their life, not your idea.
  Bad:  "Would you use an app that helps you track expenses?"
  Good: "How do you currently track your expenses? Walk me through
        the last time you did it."

Rule 2: Ask about the past, not the future.
  Bad:  "Would you pay $10/month for this?"
  Good: "What's the last tool you paid for to solve this problem?
        How much was it?"

Rule 3: Talk less, listen more.
  Bad:  Explaining your product for 15 minutes, then asking
        "What do you think?"
  Good: Asking a question and then shutting up for as long as
        it takes.

Questions That Work

Understanding the problem:
  - "Tell me about the last time you experienced [problem]."
  - "What did you do about it?"
  - "What was the hardest part?"
  - "Why was that hard?"
  - "How are you solving this today?"

Understanding importance:
  - "How often does this come up?"
  - "What does it cost you when this happens?" (time, money, frustration)
  - "Have you tried to find a solution? What happened?"
  - "What would change if this problem went away?"

Detecting false positives:
  - "You mentioned [problem]. When was the last time it happened?"
    (If they can't remember, it's not that important.)
  - "Have you looked for a solution?"
    (If they haven't even Googled it, they don't care enough to pay.)
  - "What's your current workaround?"
    (No workaround = not a real problem.)

What False Positives Look Like

False positive: "Oh yeah, that would be amazing! I'd totally use that."
Reality: They're being polite. They will never use it.

False positive: "We definitely need something like this."
Reality: They said "we" to diffuse responsibility. Ask who specifically
         would use it and how.

False positive: "I'd pay for that."
Reality: Hypothetical willingness to pay is worthless. Ask if they've
         paid for alternatives or ask them to pre-order.

The Mom Test's greatest contribution is distinguishing between compliments and commitments. A compliment is "that sounds great." A commitment is "can I start using it today?" or "here's my credit card" or "let me introduce you to my team." Only commitments are real signals.

Validating the Problem

Once you think you have found a problem worth solving, validate it before building anything.

Validation checklist:
  [ ] Can you describe the problem in one sentence?
  [ ] Can you name 10 specific people who have this problem?
  [ ] Have you talked to at least 5 of them?
  [ ] Do they experience this problem frequently (weekly or more)?
  [ ] Have they tried to solve it (workarounds, competitors, manual
      processes)?
  [ ] Are they willing to pay for a solution (or has their employer
      paid for alternatives)?
  [ ] Can you explain why existing solutions are inadequate?

If you cannot check most of these boxes, you have not found a problem worth solving yet. Keep looking.

The Problem Statement

A good problem statement is specific, measurable, and user-centered. It does not mention solutions.

Weak problem statement:
  "Users need better collaboration tools."

Strong problem statement:
  "Remote engineering teams at companies with 50-200 employees spend
   an average of 45 minutes per day searching for information that
   exists in Slack messages, Google Docs, and Notion pages. This
   fragmentation increases onboarding time for new hires by 2-3 weeks
   and causes duplicate work when team members cannot find existing
   decisions."

The strong version tells you who has the problem, how bad it is, and gives you something to measure against. You can build a solution and then check: did we reduce that 45 minutes?

Common Pitfalls

• Falling in love with your solution. You built a prototype and now you are looking for a problem it solves. This is backwards. Kill the prototype and start with the problem.
• Asking leading questions. "Don't you hate it when..." is not research. It is confirmation bias with a question mark.
• Talking to the wrong users. If you are building for senior engineers, do not interview junior engineers. If you are building for small businesses, do not interview enterprise companies.
• Confusing a vocal minority with a real market. Ten users in your Slack community are passionate about a feature. That does not mean 10,000 users want it. Check the data.
• Skipping the "willingness to pay" question. A problem that people experience but will not pay to solve is a hobby, not a business. Free solutions exist for most problems. Yours needs to be worth paying for.
• Stopping at the first problem you find. The first problem you identify is rarely the best one to solve. Talk to more people. Look for patterns. The best problems are the ones that multiple unrelated users describe in similar terms without prompting.

Key Takeaways

Finding the right problem is more important than building the right solution. Talk to users by observing behavior and asking about the past, not the future. Use the Mom Test to avoid false positives: look for commitments, not compliments. Validate problems before building by checking frequency, severity, existing workarounds, and willingness to pay. Write problem statements that are specific and measurable. The most dangerous thing a PM can do is skip problem discovery and jump to solutioning.