Problem Statement · Discovery · Problem Formulation · PTOS

Problem Statement: How to Formulate a Problem So the Team Doesn't Jump to Solution Space

A detailed guide on creating a Problem Statement—a key Discovery artifact that clearly defines the problem without offering solutions and serves as a compass for the team.

Problem Statement: How to Formulate a Problem So the Team Doesn't Jump to Solution Space

One of the product manager's main tasks is to keep the team from prematurely jumping into Solution Space. As soon as "let's add a button" is uttered, the focus shifts from the user's real pain to discussing interfaces, technologies, and timelines.

A Problem Statement (problem formulation) is a key artifact of the Discovery phase that serves as an "anchor" and prevents the team from losing its way. It's a short, yet concise, description of the problem, completely stripped of any hints of a solution.

Why is a Problem Statement Needed?

Creates shared context. Ensures that the entire team—from developers to marketers—has a common understanding of the problem they are working on.
Protects against the "feature factory." Prevents tasks from being added to the backlog simply because "it seems like a good idea."
Focuses on value. Reminds everyone that the goal is not "to build a feature" but "to solve a problem" and change user behavior.
Acts as a "shield" from stakeholders. Instead of debating tastes and opinions, you discuss facts and data that formed the basis of the Problem Statement.

Problem Statement Template in PTOS

A good Problem Statement should answer several key questions, combining data from WHAT-HOW-WHY analysis.

For [segment]
in the situation [scenario/trigger]
fails [WHAT: observed symptom]
because [HOW: mechanism/reason]
due to this [consequence for the user]
and this is important for the business because [WHY: metric/bet]
evidence: [2-3 pillars: data/support/observation]

Practical Example

Let's break it down using a B2B CRM example:

For new sales managers in their first 2 weeks after hiring,
in the situation "after the first client call,"
fails to set the next step (35% of leads remain without a next step within 15 minutes),
because the task creation form requires too many decisions and lacks a "default" quick option,
due to this the manager postpones the task "for later," forgets about it, and leads "cool down,"
and this is important for the business because we lose conversion to deal and lengthen the sales cycle.
evidence: [funnel analytics, complaints from sales team leads, recordings of 5 interviews with new managers].

How Does This Work?

No mention of solutions. Notice, this Problem Statement contains no mention of "buttons," "integrations," or "redesign." It is entirely focused on the problem.
Based on facts. It doesn't just say "managers find it inconvenient," but backs it up with specific data (35% of leads) and evidence from various sources (triangulation).
Unites user and business. It connects the user's pain ("losing control over the deal") with the business's pain ("losing conversion").

Conclusion

A Problem Statement is your compass. If, after the Discovery phase, you cannot create such a document, you are not yet ready to move on to finding solutions. Return to research until you achieve crystal clear understanding of the problem.

This simple yet powerful artifact will save your team countless hours spent building products that no one needs.