When you’re building a product, it’s easy to get excited about the “how.” The sleek design, the advanced tech stack, the long feature list. But here’s the hard truth that separates great products from forgettable ones: don’t fall in love with the solution; fall in love with the problem.

This mindset shift can be the difference between a product that thrives and one that just exists. Albert Einstein once said, “If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions.” The best product builders know this to be true.

Consider Airbnb. Before scaling globally, its founders lived with hosts, took photos of their homes, and listened carefully to their frustrations. They didn’t start with “how to build an online rental platform.” They started with the problem: people struggled to find affordable, authentic places to stay, and hosts struggled to attract guests. By falling in love with this problem, they built a solution that scaled.

Why Focus on the Problem?

Our brains are wired to leap into solution mode. But this creates danger: assumptions are the most dangerous trap in product management. When teams build on assumptions, they risk creating features no one truly values. This is how companies become “feature factories,” busy shipping but failing to create traction or business impact.

The goal isn’t just to build things right—it’s to build the right things. Robust infrastructure and pixel-perfect design mean little if the product doesn’t solve customer problems or deliver business value.

Melissa Perri, author of Escaping the Build Trap, describes this trap as the endless pursuit of features without focusing on outcomes. Avoiding it requires a disciplined focus on understanding and framing the problem first (SVPG on discovery vs. documentation).

How to Fall in Love with the Problem

Shifting to a “problem-first” mindset takes deliberate practice. Here are seven techniques to help cultivate it.

1. Separate Problem from Solution

Too often, teams collapse the two spaces: “the customer struggles with onboarding, so let’s build a better tutorial.” Slow down. The problem space is about what challenge exists; the solution space is about how to address it.

Framing these separately ensures you’re solving the right issue. A clear problem statement (“Customers abandon onboarding because they can’t connect integrations easily”) is sharper than a solution-first statement (“We need more tutorials”).

Takeaway: Write problems and solutions in separate columns. Ensure the problem is clear before brainstorming how to solve it.

2. Talk to Customers (Often)

There’s no substitute for direct, frequent customer conversations. Surveys and dashboards are useful, but they’re not a replacement for hearing motivations, frustrations, and workarounds firsthand.

Airbnb succeeded because its founders met hosts where they lived. Dropbox’s Drew Houston validated demand by showing people a demo before building infrastructure. Both started with conversations, not code.

Takeaway: Schedule at least three customer conversations per week during discovery phases. Don’t ask for feature requests—dig into pains, motivations, and current workarounds.

3. Ask Naïve Questions

It takes humility to ask what feels like a “dumb” question. But probing until you can explain a problem to a 10-year-old forces clarity. If you can’t explain it simply, you probably don’t understand it deeply.

Case study: The iPod
Apple’s breakthrough wasn’t “a portable MP3 player.” That already existed. Their reframed problem was simpler: “How do we give people a thousand songs in their pocket?” The clarity of this framing shaped the product vision.

Takeaway: In problem discussions, challenge yourself to reframe in plain language. If you’re relying on jargon, you may be hiding confusion.

4. Define Outcomes Before Solutions

Before you sketch wireframes, define the change you want to see. Outcomes are customer or business impacts; outputs are features.

Marty Cagan emphasizes this distinction: great teams focus on outcomes over outputs (SVPG on outcomes vs. output). For example:

  • Output: “Build a loyalty program.”
  • Outcome: “Increase repeat purchase rate by 15%.”

Takeaway: For every proposed feature, ask: What outcome will this deliver? How will we measure it?

5. Counter Confirmation Bias

We’re all prone to seeking data that validates our beliefs. But confirmation bias blinds us to real problems. To counteract it:

  • Think in bets: Frame initiatives as bets with conditions. “We bet customers will adopt this if X, Y, Z hold true.”
  • Seek contrary evidence: Actively look for signals that disprove your assumptions (HBR on confirmation bias).
  • Generate multiple options: Force yourself to brainstorm at least three viable solutions. The first idea is rarely the best.

Takeaway: Add “what would prove us wrong?” as a standing question in discovery sessions.

6. Involve Your Team in Discovery

Problem discovery is not the PM’s solo job. Engineers and designers need exposure to customers too. When engineers understand the problem firsthand, they shift from building “cool features” to solving meaningful challenges.

As SVPG notes, empowered teams succeed when engineers contribute to discovery as problem-solvers, not just coders (SVPG on engineers in discovery).

Case study: Atlassian
Atlassian’s teams invite engineers into customer interviews. As a result, engineers often propose creative solutions that PMs wouldn’t have considered.

Takeaway: Rotate engineers into user interviews. Debrief as a team, not just in PM summaries.

7. Visualize the Future Impact

A powerful technique for anchoring on the problem is to imagine the product already exists and has succeeded. Then, write from the perspective of that future.

  • Customer letter: Imagine a customer writing to your CEO. What problem did you solve for them? How did their life improve?

  • CEO memo: Imagine the CEO writing to your team. What business outcomes did the solution drive? Increased retention? Reduced churn?

This “future-back” framing clarifies which problems are worth solving and aligns customer and business value.

Takeaway: Incorporate a “Customer Promise Letter” into discovery. Use it as a test for whether the problem and solution align with customer progress.

The Ongoing Journey

Falling in love with the problem isn’t a one-off event. Customer needs evolve, markets shift, and competitive landscapes change. Assumptions that were valid last year may already be outdated.

Microsoft Zune is a reminder: a sleek solution, but with no compelling customer problem compared to the iPod. By contrast, products like Figma thrive because they continue to adapt to evolving customer needs—remote collaboration, multiplayer design, and browser-based workflows.

Great product leaders treat problem discovery as an ongoing discipline, not a phase to “get through.”

Closing Thought

When you fall in love with the problem, solutions follow naturally. You avoid the trap of building features for their own sake, and instead create products that truly matter—for your business and for the people you serve.

Pick one of the seven techniques this week—whether it’s separating problem from solution, involving engineers in discovery, or writing a future customer letter—and put it into practice. Over time, this becomes a habit, and that habit becomes your advantage.