PM Gym

Defining The Problem

Solve the right problem before you solve a problem right

Teams love jumping straight to solutions. But build the sharpest feature to answer a fuzzy or wrong problem, and you've still shipped nothing worth using. This guide covers how to frame a problem so the rest of the process has something solid to stand on.

Step-by-step lessons

Frame the Problem Before You Solve It

Four short lessons: why framing matters, how to write a sharp problem statement, how to dig to the root cause, and the traps to avoid.

1

Solving the Wrong Problem Well

Most product failures aren't features executed badly — they're features that answer the wrong question. Problem framing is the step before ideation and design: get precise about what's actually broken, for whom, and why it matters, before anyone touches a solution.

The support-ticket trap

A team notices users abandon checkout and complain "your checkout is confusing." They redesign the checkout flow end to end. Abandonment barely moves — because the real problem was a shipping-cost surprise on the last step, not the layout. They solved a problem. Just not the one that mattered.

A sharp solution to a fuzzy or wrong problem still fails. Framing comes first.

Quick check

A stakeholder says "users want a dark mode, build it." What's the problem-framing move before writing any code?

2

Writing a Sharp Problem Statement

A good problem statement is specific enough that two different teams reading it would picture the same problem — and specific enough to know when it's solved.

1

Who

The specific user or segment affected — not "users," but "new sellers in their first week."

2

What

The observed friction, stated as behavior, not a guess at cause: "38% abandon the listing form."

3

Why it matters

The cost to the user or business: "It's our single biggest activation leak."

4

Evidence

What tells you this is real: data, quotes, session recordings, support tickets.

Too vague

"Users struggle with pricing"

No segment, no number, no source — impossible to know when it's fixed.

Sharp

"New sellers abandon the pricing step (38%, last 90 days)"

Specific enough to investigate, specific enough to know if a fix works.

Quick check

Which of these is the sharpest problem statement?

3

Digging to the Root Cause

Once you know what's broken, dig into why. The 5 Whys is a simple technique for moving past the first plausible cause to something you can actually act on.

The 5 Whys, in action

Problem: Checkout crashes on Mondays.

Why? Traffic spikes then. Why? Our Monday email blast lands right at 9am. Why does the spike crash it? Servers are scaled for average load, not peak. Why? No autoscaling is configured. Why wasn't it configured? No one owns capacity planning.

The root cause isn't "add more servers" — it's an ownership gap. Fix that, and every future spike stops being a fire drill.

Quick check

Using the 5 Whys, you land on "nobody owns capacity planning" after five whys. What should you do with that?

4

Common Problem-Framing Traps

Problem framing fails in predictable ways. Watch for these three traps every time you or a teammate writes a "problem" down.

Trap 1

Solution-shaped problem

"We need push notifications" names a feature, not a pain. Ask what it's meant to fix.

Trap 2

Too broad to act on

"Users are unhappy" can't be tested or solved. Narrow to a segment and a moment.

Trap 3

Cherry-picked evidence

Hunting only for data that confirms the fix you already wanted defeats the point of framing.

Quick check

A PM writes: "Problem: we lack a referral program." What's wrong with this framing?

Review the concepts

Defining The Problem Flashcards

6 cards covering the essentials. Click a card to flip it.

Foundation Card 1 of 6

Problem Framing

Click to flip

Tip: say the answer out loud before flipping.

Explanation

In practice

1 / 6
Apply what you learned

Practice Scenarios

15 situations that test whether you can spot a fuzzy problem, a solution in disguise, or a root cause hiding beneath a symptom.

Scenario 1

A support lead says: "Problem: we need a live chat widget."

What's your first move?

Scenario 2

Two teammates argue hotly about button color while debating a signup problem nobody has actually defined yet.

What should happen?

Scenario 3

A churn analysis concludes: "users leave because the product is bad."

How do you improve this problem statement?

Scenario 4

A PM's 5 Whys chain stops after one why — "Signups dropped. Why? The homepage changed." — and ships a full revert.

What's the risk?

Scenario 5

Leadership demands: "Problem: we don't have a mobile app."

How do you reframe it?

Scenario 6

A problem statement reads: "New users abandon onboarding (61%, last 30 days, from funnel analytics)."

Why is this a strong statement?

Scenario 7

During a root-cause dig, someone says "let's stop, we all agree it's an API bug" after only two whys — while data shows three teams changed things that week.

What's the caution?

Scenario 8

A researcher notices they're only pulling user quotes that support the "redesign the nav" idea already scoped.

What's happening?

Scenario 9

A problem statement names a segment ("enterprise admins") but no evidence — just "I think they're frustrated."

What's missing and why does it matter?

Scenario 10

A team debates for an hour whether to build feature X or Y, with no written problem statement for either.

What should happen first?

Scenario 11

Analytics shows a spike in a "problem" only three days old, and no one has checked whether it's a one-off event (a marketing blast) or a persistent pattern.

What's the framing risk?

Scenario 12

A doc lists fifteen different "problems," ranging from onboarding to pricing to support tone, with no ranking.

What's the issue with this?

Scenario 13

A junior PM says "the problem is clear, let's move to ideation" after a single Slack message from one user.

Is that enough to move forward?

Scenario 14

A problem statement says: "We're losing to Competitor X, so we need their feature set."

What's the framing flaw?

Scenario 15

After a sharp, evidence-backed problem statement is written, a stakeholder still says: "Just build what I asked for originally."

What's the best response?

Lock it in

Guess the Term

Read the clues and name the concept. The fewer clues you need, the more points you score.

Round 1 Score 0
Keep it handy

Defining The Problem Quick Reference

The whole topic on one screen.

Anatomy of a Problem Statement

Specific enough that two teams would picture the same problem.

1

Who

The specific segment affected.

2

What

The observed friction — behavior, not a guessed cause.

3

Why it matters

The cost to the user or the business.

4

Evidence

Data, quotes, tickets — what makes it real.

Root-Cause Digging

5 Whys

Keep asking why until you hit something structural you can act on.

Don't stop at one why

The first "why" is usually a proximate cause, not the root.

Traps to Avoid

Solution-shaped problem

"We need X" names a feature, not a pain.

Too broad to act on

Narrow to a specific segment and moment.

Cherry-picked evidence

Confirmation bias validates the fix you already wanted.

Problem Space vs. Solution Space

Problem space

What's broken and why — stay here as long as possible.

Solution space

How you'll fix it — enter only once the problem is sharp.

Notification