Separating User Needs from Proposed Solutions in Product Problem Statements

Welcome back. In the previous lesson, you translated a broad business goal into a measurable product outcome: a defined user group, a target metric, a timeframe, and guardrails. That tells a team what change would count as success.

This lesson focuses on the preceding and equally important question: what problem is worth solving? You will learn to write a concise product problem statement that names the affected user, their context and unmet need, and the impact of the problem—without quietly deciding that an AI feature, dashboard, chatbot, or any other proposed solution is the answer.

For an AI Product Manager, this separation is especially important. AI can make many concepts feel technically possible; it does not establish that they are needed, valuable, or the best way to improve a user’s experience.

---

The three statements that keep product thinking honest

Product discussions often collapse three distinct ideas into one sentence. Keeping them separate makes your reasoning clearer to stakeholders and protects the team from premature solution choice.

Artifact	Main question	What it contains	What it excludes
Product outcome	What measurable change do we want?	Target population, metric, baseline, target, timeframe, guardrails	A commitment to a particular feature
User need statement	What does a user need to accomplish, and why?	Specific user, need framed as an action, deeper goal	Technology, interface, feature
Product problem statement	What is going wrong now, for whom, in what context, and why does it matter?	Context, affected people, pain or unmet need, user and business impact	The proposed fix
Solution hypothesis	What might improve the problem, and why might it work?	A possible intervention and assumptions to test	A claim that the intervention is already validated

The distinction matters because each artifact supports a different decision.

• An outcome statement guides measurement.
• A need statement maintains empathy and expands the range of possible ideas.
• A problem statement focuses discovery and establishes scope.
• A solution hypothesis gives a team something testable to explore later.

Consider these two statements:

“Build an AI support copilot that drafts responses for agents.”

“Support agents handling routine billing and account-access tickets struggle to locate current approved guidance while a customer is waiting, extending resolution time and creating avoidable handling costs.”

The first is a solution proposal. It may be a good idea, but it assumes the cause of slow resolution is response drafting and that generative AI is the best intervention.

The second is a problem statement. It tells us enough to investigate and act, while leaving open several possible approaches: better documentation, improved internal search, templates, workflow changes, rules-based automation, training, or an AI-assisted experience.

A practical rule is:

A problem statement describes the undesirable present state. A solution hypothesis describes a possible future intervention.

---

Need is a verb; a solution is usually a noun

A common source of weak problem statements is confusing an artifact with the underlying need.

Users rarely need “a dashboard,” “a comparison table,” “an LLM,” or “a chatbot.” Those are nouns: implementations a team might build. The user instead needs to compare options, understand relevant information, choose confidently, find policy guidance, or complete a task accurately. These are verbs and end states.

The short NNgroup video introduces the structure before showing the key distinction between desired outcomes and implementation mechanics.

Here is a useful rewrite pattern:

Solution-biased wording	Need-focused rewrite
“Shoppers need an AI assistant.”	“Shoppers need to narrow a large set of similar products to options that fit their constraints.”
“Support agents need a response-generation tool.”	“Support agents need to find and apply current approved guidance while resolving a ticket.”
“Admins need a dashboard.”	“Administrators need to understand which accounts require attention and why.”
“Users need a comparison table.”	“Users need to evaluate meaningful differences among options before committing.”

The need-focused version is not deliberately vague. It still identifies a real action, a real context, and a real user. What it avoids is treating one implementation as inevitable.

A reusable need-statement format is:

[Specific user] needs to [action or desired state] in order to [human or practical goal].

For example:

A returning mobile shopper comparing similar skincare products needs to identify which options match their skin concerns and preferences in order to choose confidently without spending excessive time researching.

Notice what this does not say. It does not prescribe conversational AI, product filters, recommendations, reviews, a quiz, or a product-comparison page. Those are all possible hypotheses to consider after the team understands the problem.

---

From a user need to a product problem statement

A need statement is deliberately concise and user-centered. A product problem statement gives the team a little more operating context: what happens today, where it occurs, who is affected, and why it matters to both users and the organization.

A strong product problem statement normally answers five questions:

1. Who is affected?
   Name a meaningful segment, not “users” in general.

2. What is difficult, inefficient, risky, or impossible today?
   Describe an observable pain, behavior, or unmet need.

3. When and where does it happen?
   Identify the journey moment, workflow, channel, or situation.

4. What is the consequence for the user?
   Lost time, uncertainty, errors, frustration, reduced trust, inability to complete a task, or another specific consequence.

5. Why does it matter to the organization?
   Lower conversion, avoidable operating cost, support burden, lower retention, compliance risk, or missed strategic value.

NN/g describes a problem statement as a concise scoping device. It should direct discovery toward one coherent problem, make clear what is currently in scope, and help stakeholders understand why investigating it is worthwhile.

A practical product-problem template

Use this adaptable format:

[Target user] experiences [specific pain or unmet need] when [context or trigger]. This leads to [user consequence]. It matters to [organization or team] because [business or operational impact].

You may add a fifth sentence to clarify known evidence or a critical uncertainty:

Current evidence suggests [fact], but we need to understand [unknown cause, segment difference, or behavioral pattern].

This last sentence is valuable when you are early in discovery. It prevents a polished problem statement from overstating certainty.

Worked SaaS example

Recall the outcome from the prior lesson: reduce median handling time for routine billing and account-access tickets from 16 to 13 minutes, while maintaining customer satisfaction and the ticket reopen rate.

A weak, solution-first framing would be:

“We need an AI copilot to answer billing tickets faster.”

It tells us neither whether agents actually lack information nor whether customer-facing automation would be safer or more useful than agent assistance.

A stronger need statement is:

Support agents handling routine billing and account-access tickets need to locate and apply current approved guidance quickly in order to resolve customer issues accurately without spending unnecessary time searching across systems.

A corresponding product problem statement is:

Support agents handling routine billing and account-access tickets often spend substantial time locating current approved guidance and preparing accurate responses while customers wait for help. This contributes to a median handling time of 16 minutes for the targeted ticket types and can delay resolution for customers. The problem creates avoidable support effort and may weaken the service experience that supports customer retention.

This statement is focused, specific, and connected to the earlier outcome. Yet it does not state that an AI copilot should be built. It preserves room for a team to investigate the underlying friction:

• Is the relevant information missing, outdated, or scattered?
• Do agents struggle most with search, interpretation, drafting, approvals, or another part of the workflow?
• Are all ticket categories affected, or only certain policies, languages, or customer tiers?
• Would an improved knowledge base solve most of the problem before an AI capability is justified?

Those questions move naturally into customer and user discovery, the focus of the next module.

---

Evidence, assumptions, and the confidence of your wording

A problem statement should be grounded in what you know, but early product work rarely provides complete certainty. The solution is not to write vague language. It is to distinguish evidence from interpretation.

Suppose you have the following information:

• Helpdesk data shows a 16-minute median handling time for the selected ticket categories.
• Several agents report searching across multiple knowledge sources.
• The ticket reopen rate is 6.5%.
• You do not yet know whether the central bottleneck is finding information, interpreting policy, drafting responses, or handling complex exceptions.

The first three may be evidence, depending on data quality and sample size. The last point is an uncertainty. Do not turn a plausible explanation into a fact:

“Agents cannot resolve tickets because they lack an AI tool.”

That sentence contains an unsupported causal claim and a solution.

Instead, write with appropriate precision:

“Agents report moving among multiple guidance sources during routine tickets. We need to determine which part of this workflow contributes most to handling time.”

This distinction is especially important in AI product management. A model demo can make a workflow look solvable, but it cannot by itself establish:

• that the proposed user segment has a high-priority pain,
• that the pain is large enough to justify the cost and risk,
• that an AI system is more appropriate than a non-AI workflow improvement,
• or that the underlying data is sufficient for reliable behavior.

You are not weakening your case by noting an uncertainty. You are defining the most important learning goal.

---

A second example: e-commerce without assuming an AI shopping assistant

Imagine an e-commerce business that wants to improve conversion among returning mobile shoppers. A stakeholder proposes:

“Add an AI shopping assistant to the product-detail page.”

That might eventually be worth testing, but it is not a problem statement. Start with the customer behavior and context.

Need statement

Returning mobile shoppers who are comparing similar products need to understand the meaningful differences among options in order to select a product that fits their needs with confidence.

Product problem statement

Returning mobile shoppers who view several similar products within a category have difficulty identifying which differences are relevant to their specific needs on a small screen. They may leave product-detail pages without purchasing or spend significant time switching between pages to compare information. This reduces the likelihood of conversion in a high-intent part of the shopping journey and may push shoppers toward external research or competing retailers.

Again, this leaves several pathways open:

• clearer product attributes,
• improved search and filters,
• better comparison support,
• more useful reviews,
• personalized recommendations,
• a guided product-selection flow,
• or an AI shopping assistant.

These are options, not embedded conclusions. In the later e-commerce portfolio case, you will explicitly compare an AI assistant with improved search, filters, and recommendations rather than assuming AI is the intervention.

The following Product School segment provides useful examples of solution-first versus customer-focused problem statements and introduces practical ways to structure one.

---

Keep the solution in a separate “parking lot”

Separating problem from solution does not mean pretending you have no ideas. It means handling ideas in the right place.

After drafting the problem statement, create a visibly separate section in your notes titled Possible approaches to investigate. For the SaaS support problem, this might include:

• consolidate and improve approved support guidance;
• improve internal search and information retrieval;
• introduce templates for repeated response patterns;
• test an AI-assisted draft workflow with human review;
• automate a narrow, low-risk account-status lookup.

These are not commitments. They are hypotheses with different costs, risks, data requirements, and expected benefits.

A quick diagnostic is the three-plausible-approaches test:

Can you name at least three meaningfully different ways to address the stated problem?

If the answer is no, reread the statement for hidden solution language. A problem that can only be solved by “an AI chatbot” is usually actually phrased as a feature request.

This separation also improves stakeholder conversations. Rather than rejecting a request such as “We need a chatbot,” you can reframe it constructively:

“The proposed chatbot may be one approach. Before choosing it, let’s align on the customer problem: shoppers cannot confidently compare similar products on mobile. We can then evaluate whether an assistant is the most effective and responsible intervention.”

That response neither dismisses AI nor accepts it on faith. It turns a technology request into a product decision.

---

A final quality check before sharing your draft

Before treating a problem statement as ready for discovery, review it against this checklist.

Check	A strong draft	Warning sign
Specific user	Names a segment with a shared context or behavior	Refers only to “users” or “customers”
Real context	Says when and where the problem appears	Describes a generic, context-free complaint
User need	Uses an action or outcome, such as compare, find, understand, decide, resolve	Names a feature, interface component, model, or tool
Focused scope	Describes one connected problem	Lists unrelated issues for many user groups
Impact	Explains user consequences and organizational stakes	Mentions only a company goal, such as “increase revenue”
Evidence discipline	Separates observed facts from assumptions to investigate	States an untested cause as certain
Solution separation	Keeps proposals in a distinct hypothesis section	Contains phrases such as “build,” “add,” “use AI,” or “launch a dashboard”

A concise product problem statement does not need every available detail. If it takes a page to explain, it may include research findings that belong in a separate evidence summary. Aim for two to four sentences that make the team’s focus unmistakable.

---

Key takeaways

A product outcome defines the measurable change you seek; a product problem statement defines the current user-centered problem that makes that change valuable. Neither should lock the team into a particular feature.

A strong problem statement identifies:

• the specific people affected;
• the moment and context in which the difficulty occurs;
• the user’s pain or unmet action-oriented need;
• the consequence for the user;
• and the organizational impact if the issue persists.

Keep needs as verbs and goals, not nouns or implementations. An AI assistant, retrieval system, dashboard, or automated workflow belongs in a separate solution hypothesis, where it can be compared with alternatives and tested against evidence.

Next, you will use this framing discipline to evaluate feature requests through user evidence, strategic fit, expected value, and practical constraints.