Problem Statement Workshop

The Most Expensive Mistake in Product Is Solving the Wrong Problem

In 2010, Google launched Wave. It was technically brilliant — real-time collaboration, threaded conversations, embedded media. The engineering was some of the best work Google had ever done. It shut down within a year. Not because of execution. Because nobody could explain what problem it solved.

This story gets repeated constantly. Teams fall in love with a solution and retrofit a problem onto it. The discipline of problem framing — spending time to get the *problem* right before touching solutions — is the most underrated skill in product management.

Why Teams Skip Problem Definition

It feels unproductive. You're in a meeting, everyone has ideas, and someone says "let's step back and define the problem." Eyes roll. "We know the problem — users are churning." But do you? Are they churning because onboarding is confusing, because the core value takes too long to reach, because a competitor launched a free tier, or because your billing emails look like spam?

According to a Harvard Business Review study, 85% of executives surveyed said their organizations were bad at problem diagnosis, and 87% said this flaw carried significant costs. The research found that teams who spent 20% more time on problem framing reached effective solutions 35% faster, because they avoided the rework loop of building the wrong thing.

The "How Might We" framework and the 5 Whys technique exist specifically for this. "Users are churning" becomes "Users who signed up from paid ads churn 3x faster than organic users in the first 14 days." That's a problem you can actually solve. The first version is a vague worry. The second is an actionable brief.

How This Prompt Helps

This prompt facilitates a problem statement workshop. It takes your initial problem area and guides you through progressive sharpening — using 5 Whys to dig to root causes, reframing into "How Might We" questions, and stress-testing whether you're describing a symptom or a cause. By the end, you have a problem statement specific enough to evaluate solutions against.

The structured output also captures who's affected, how severely, and what evidence supports the problem's existence. This matters because it prevents the "phantom problem" — something the team *assumes* is an issue but has never validated.

When to Reach for This

• You're kicking off a new initiative and the team has jumped straight to solution brainstorming
• Discovery interviews revealed multiple problems and you need to sharpen which one to focus on
• Your team built something that didn't move metrics, and you suspect you solved the wrong problem
• A stakeholder handed you a solution ("build X") and you need to unpack the underlying problem to evaluate alternatives
• You're running a design sprint and need a well-framed problem to anchor Day 1

What Good Looks Like

A sharp problem statement names the specific user segment, the specific behavior or outcome that's problematic, the measurable impact, and the evidence source. "Users" becomes "first-time B2B users on the Team plan." "Bad experience" becomes "fail to invite a second team member within 7 days, leading to 62% Day-30 churn." That's a problem statement a team can rally around.

Sources

• Are You Solving the Right Problems? — Harvard Business Review
• Continuous Discovery Habits — Teresa Torres