There is a kind of product sentence that sounds sophisticated and still tells you almost nothing. “We need a better dashboard experience.” “We need a more intuitive export workflow.” “We need an AI powered support experience.” Those sentences feel like problem statements because the team added words such as “better,” “intuitive,” or “experience.”
They are still solution statements. A simple test helps:
Remove every feature word.
If the problem stops making sense, you probably have not defined the problem yet.
Feature words quietly close the solution space
Imagine Store Operations is missing curbside orders that are at risk of failing the pickup promise and asks for an exception dashboard. The team tries to reframe it: “Store teams need a better exception dashboard so they can intervene earlier.” Better. Still a dashboard project.
The proposed feature has already decided the answer. Remove it: “Store teams cannot reliably identify curbside orders at risk of missing the pickup promise early enough to recover before the customer arrives.” That is different. Now the team can ask useful questions.
Are the signals late? Is inventory state unreliable? Does the handoff between picking and staging break? Is the information available but spread across systems? Do associates know what action to take once an order is at risk?
The problem statement has stopped dictating the interface. That is the point.
The test is not anti solution
Product people sometimes take problem framing so far that it becomes an identity. “We are problem people, not solution people.” I do not find that useful. We build solutions. Eventually someone has to decide what the product should do.
The discipline is about sequence. If the solution appears before the problem is understood, it starts pulling every later conversation toward itself. Research becomes validation. Metrics get selected to prove the feature mattered. Engineering debates implementation instead of whether the thing should exist. Stakeholders hear “discovery” but experience a project whose destination was already chosen. Removing feature words creates a temporary boundary.
For this moment, describe reality without smuggling the answer into the description. Then earn the right to solution.
A problem statement should describe a failure in the world
A useful problem statement usually contains a few things.
Who is affected?
Not “users.” Which customers, operators, buyers, administrators, or teams are experiencing the failure?
What are they unable to do, decide, understand, or accomplish?
Describe the broken behavior or decision, not the missing artifact.
When or where does it happen?
Context matters. “Store teams lack visibility” is vague. “Associates discover a curbside order is at risk only after the customer has already arrived” gives you something to investigate.
What is the consequence?
Time, revenue, trust, errors, effort, abandonment, exposure, cost, or another observable effect.
What evidence makes us believe this is real?
A problem statement is not improved by sounding confident. It is improved by being connected to evidence. Notice what is absent from that list. Dashboard. Workflow. Integration.
Copilot. Export. Those may become excellent solutions. They simply have not earned their place in the problem statement.
The language exposes weak thinking
This is why writing the problem down matters. A team can survive a vague spoken conversation because everyone silently fills in the gaps with their own assumptions. The sentence makes that harder. Take: “Our admins need a custom export.”
Delete the feature: “Our admins need…” Need what? Maybe: “Enterprise audit teams cannot verify which employees have access to sensitive information without reconstructing permission data outside the product.”
Now there is a problem. And the new sentence immediately creates better discovery questions. Why are they reconstructing it? Is the access model opaque? Are permission changes hard to trace?
Do they need audit history rather than an export? Is the issue limited to one prospect or common across regulated customers? The writing did not solve the problem. It exposed where the thinking was unfinished.
Problem statements should be upstream artifacts
Teams also get confused because they expect one document to do every job. A problem brief is not a product requirements document. The problem brief exists upstream. It creates shared understanding of what is failing, why it matters, what evidence supports it, and what constraints shape the decision.
A requirements document lives later. It can describe the chosen solution because the team has already decided what it intends to build. When teams collapse those artifacts, problem framing becomes a preamble to the requirements. The “problem” section says: “Users need easier reporting.”
Then twelve pages explain the reporting feature everybody already agreed to build. That is not framing. That is justification.
The constraint is useful in executive rooms too
Feature words carry momentum. A dashboard. An integration. An AI assistant. Once the proposed solution enters the room, people start negotiating it. Removing it gives the room permission to challenge the diagnosis without forcing anyone to defend or abandon a favored answer yet.
That can be the difference between reframing the problem and having another feature debate.
Try the deletion test
When a team brings you a problem statement, scan it for the answer already hiding inside it. Dashboard. Report. Export. App.
Integration. Notification. Portal. Assistant. Automation.
AI agent. Delete them. Then ask whether the sentence still describes something real and consequential. If it does, good. You probably have a problem worth investigating. If it collapses, that is useful too.
You have discovered that the organization knows what it wants to build before it knows what is broken. That does not mean the proposed feature is wrong. It means the reasoning is incomplete. And incomplete reasoning is exactly what good problem framing is supposed to expose.