Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Problem

Pattern

A reusable solution you can apply to your work.

“Fall in love with the problem, not the solution.” — Uri Levine, co-founder of Waze

Understand This First

Context

At the strategic level, before any product, feature, or system takes shape, there must be a problem worth solving. A problem is a real unmet need, friction, risk, or desire experienced by a specific person or organization. It’s the foundational pattern in product judgment; everything else in this section depends on it. Without a genuine problem, there’s no Value Proposition, no Customer willing to pay, and no path to Product-Market Fit.

In agentic coding, where AI agents can generate working prototypes in hours, the temptation to skip problem validation grows stronger. It’s easier than ever to build something, and just as easy to build something nobody needs.

Problem

How do you know whether the thing you’re about to build addresses a real need? Teams routinely fall in love with a technology, an architecture, or a clever idea and then go looking for a problem to justify it. The result is a solution in search of a problem: software that works perfectly and matters to no one.

The difficulty is that problems aren’t always obvious. Some are latent: the person experiencing the friction has adapted to it and no longer notices. Others are aspirational: the desire exists, but the person can’t articulate it until they see a solution. And some “problems” are imaginary, projected by the builder onto a market that doesn’t share the pain.

Forces

  • Builder enthusiasm pulls toward building first and validating later.
  • Latent needs are invisible until surfaced through observation or conversation.
  • Aspirational needs can’t be discovered through surveys alone. People can’t ask for what they can’t imagine.
  • Proxy signals (competitor activity, market trends) can be mistaken for evidence of a problem.
  • Sunk cost makes it painful to abandon a problem framing once work has begun.

Solution

Start by describing the problem in plain language, independent of any solution. A useful test: can you explain the problem to someone who’s never seen your product and have them nod in recognition? If you can only explain the problem by first explaining the solution, you may not have a real problem.

Validate problems through direct contact with the people who experience them. Watch how they work. Ask what frustrates them. Look for workarounds: improvised solutions are strong evidence of unmet needs. A person who’s built a spreadsheet to manage something that should be automated is showing you a problem with their behavior, not just their words.

Distinguish between problem severity and problem frequency. A rare but catastrophic problem (data loss, compliance failure) can justify a product just as well as a frequent but mild one (clumsy UI, slow report). The combination of severity and frequency determines whether the problem is worth solving commercially.

Tip

When directing an AI agent to build something, start your prompt with the problem statement, not the feature request. “Users lose unsaved work when the browser crashes” gives an agent far more useful context than “add auto-save.” The problem framing lets the agent reason about edge cases and alternative solutions.

How It Plays Out

A startup founder notices that freelance designers spend hours chasing invoice payments. She interviews twenty designers and finds that sixteen have cobbled together reminders using calendar apps and sticky notes. The workarounds confirm the problem is real, frequent, and painful enough to pay to solve. She hasn’t designed a product yet, but she has a problem worth building for.

A development team is asked to build a dashboard for executives. Before writing code, they shadow three executives for a day. They discover that the executives never look at the existing dashboard; they get their numbers by texting a direct report. The real problem isn’t “lack of dashboard” but “information is locked inside one person’s head.” This reframing changes the entire product direction.

An engineering lead asks an AI agent to “build a microservice for order tracking.” The agent produces clean code, but the lead realizes there’s no articulated problem. She rephrases: “Customers call support because they can’t see where their order is after payment.” Now the agent, and the team, can evaluate whether a microservice, a status page, or a simple email notification best addresses the actual need.

Consequences

Clearly articulating the problem focuses the team and reduces wasted effort. It provides a stable anchor when debates arise about features, scope, or technical approach. You can always return to the question “does this help solve the problem?”

Problem statements can become stale, though. Markets shift, workarounds become products, and yesterday’s burning problem becomes tomorrow’s solved one. Revisit the problem regularly, especially before major investment.

There’s also a risk of problem worship: spending so long validating and refining the problem that you never ship. At some point, you must commit to a solution and learn from the market’s response.

  • Enables: Customer — a problem only matters commercially when someone will pay to solve it.
  • Enables: Value Proposition — the proposition is the bridge between problem and solution.
  • Enables: User Story — stories express the problem from the user’s perspective.
  • Refined by: Use Case — a more concrete description of the problem in interaction terms.
  • Depends on: Build-vs-Don’t-Build Judgment — the decision about whether to act on this problem at all.
  • Contrasts with: Zero to One — some problems only become visible after the solution exists.