How to Write a Clear Problem Statement: A Practical Guide

A good solution begins with a clear understanding of the problem. When a problem is described vaguely, people may agree that something should improve but interpret the situation in completely different ways.

A clear problem statement creates a shared starting point. It explains who is affected, what they are trying to accomplish, what prevents them from succeeding and why the issue matters. It does not need to prove that the problem is widespread or prescribe the final solution.

This guide presents a practical method for turning an observation, frustration or unmet need into a useful problem statement.

What is a problem statement?

A problem statement is a concise description of a situation that should work better.

It identifies:

• the people or organizations affected;
• the goal they are trying to achieve;
• the context in which the difficulty occurs;
• the barrier or unmet need;
• the consequences of the current situation.

A problem statement gives other people enough information to understand the issue and begin investigating it. It can be used in product development, service design, innovation work, internal improvement projects and early business development.

It is not necessarily a formal document. In many situations, a few clear sentences are enough.

Why start with the problem instead of the solution?

People naturally move from noticing a problem to imagining a solution. Someone who struggles to compare local suppliers may immediately propose a new comparison platform. A person who cannot find suitable transport after a late shift may suggest a new ride-sharing application.

These solutions may be promising, but presenting them too early can narrow the discussion.

Starting with the problem allows people to ask:

• Is the problem understood correctly?
• Do other people experience it?
• What causes it?
• How is it handled today?
• Are there simpler ways to improve the situation?
• Could several different solutions address the same need?

The purpose is not to prevent people from suggesting solutions. It is to ensure that the solution responds to a real and sufficiently understood problem.

The five elements of a clear problem statement

A practical problem statement can be built around five questions.

1. Who is affected?

Identify the person, group or organization experiencing the problem.

Descriptions such as “everyone,” “customers” or “businesses” are usually too broad. A more specific group makes the problem easier to understand and investigate.

For example:

• adults studying alongside irregular work shifts;
• small food businesses preparing products with uncertain daily demand;
• employees whose shifts end after public transport services;
• homeowners trying to find suitable local service providers;
• product teams collecting improvement suggestions from several channels.

The group does not need to be defined perfectly at the beginning. It should be specific enough to indicate whose experience needs further investigation.

2. What are they trying to accomplish?

Explain the goal or task behind the problem.

A useful problem statement does not only describe what people dislike. It shows what they are trying to achieve.

For example:

• compare suitable software products before purchasing;
• travel home safely after a late shift;
• find a qualified local supplier;
• reuse materials left over from a renovation;
• identify recurring customer needs;
• fit learning into a changing weekly schedule.

This makes it easier to consider different ways of supporting the desired outcome.

3. When or where does the problem occur?

Describe the relevant situation or context.

The same task may be easy in one situation and difficult in another. A transport problem may occur only late at night. A purchasing problem may affect small companies that do not have a dedicated procurement team. A learning service may work well for full-time students but poorly for adults with changing shifts.

Useful context may include:

• time;
• location;
• type of organization;
• available resources;
• stage of a process;
• technical environment;
• relevant constraints.

Context helps prevent the problem from becoming so general that it loses practical meaning.

4. What makes the situation difficult?

Identify the barrier, limitation or unmet need.

This could involve:

• fragmented information;
• unclear pricing;
• limited availability;
• incompatible systems;
• repetitive manual work;
• insufficient knowledge;
• inaccessible services;
• uncertain demand;
• coordination between several parties.

Avoid assuming a cause unless there is evidence for it. If you know only what people experience, describe the observed difficulty and treat its possible causes as questions to investigate.

5. What consequences does the problem create?

Explain why the issue matters.

Consequences may include:

• wasted time;
• unnecessary costs;
• delayed decisions;
• avoidable errors;
• lost sales;
• unused resources;
• frustration or uncertainty;
• safety concerns;
• reduced accessibility;
• missed opportunities.

A consequence gives the problem significance. However, avoid exaggerating the impact. Describe what is known and separate it from what still needs to be validated.

A practical problem statement template

The five elements can be combined into this template:

[Affected group] struggles to [goal] when [situation] because [barrier], resulting in [consequence].

Not every problem statement has to follow this exact sentence structure. The template is a tool for checking whether essential information is missing.

A longer version can use two or three sentences:

[Affected group] needs to [goal] when [context]. Currently, [barrier or difficulty]. This can lead to [consequence].

The longer format is often easier to read and leaves room for important context without producing an overloaded sentence.

Weak and strong problem statement examples

Example 1: Finding suppliers

Weak:

Finding suppliers is difficult.

This identifies a general difficulty but does not explain who is affected, what makes the task difficult or why it matters.

Stronger:

Small businesses without dedicated procurement resources may need to search several websites and request information from suppliers individually. Comparing offers is time-consuming because pricing, availability and service information are presented differently.

The stronger version gives enough context for other people to recognize and investigate the problem without prescribing a specific solution.

Example 2: Employee transport

Weak:

There should be an application for employees working late shifts.

This begins with a solution and provides little information about the underlying need.

Stronger:

Employees whose shifts end late may have limited options for travelling home when public transport is no longer available. This can leave driving alone, arranging informal rides or using expensive alternatives as the only practical options.

Several solutions could now be considered instead of limiting the discussion to one application.

Example 3: Customer feedback

Weak:

Companies need a better feedback system.

“Better” is not defined, and the statement does not explain what currently goes wrong.

Stronger:

Product teams may receive customer feedback through support requests, sales conversations, surveys and informal messages. When these observations are stored in separate places, recurring needs can be difficult to identify and prioritize.

This version connects the current situation with a clear consequence.

Example 4: Food surplus

Weak:

Food businesses waste too much food.

This may sound accusatory and does not explain the operational difficulty behind the outcome.

Stronger:

Small food businesses must prepare enough products to meet demand, but daily sales can vary considerably. By the time surplus becomes visible, there may be little time to find another use for the remaining products.

The stronger statement focuses on the situation rather than assigning blame.

Describe what should work better—not who is at fault

Constructive problem statements focus on the situation, process or unmet need.

Statements built around blame can make people defensive and discourage useful participation. Compare:

The company does not care about employee ideas.

with:

Employees submit improvement suggestions through several informal channels, but there is no shared way to track how the suggestions are evaluated or what happens to them.

The second description does not ignore the problem. It makes the process visible and creates a better foundation for improvement.

This principle is especially important when describing public services, workplaces, products or organizations. Focus on observable circumstances and their effects rather than assuming motives.

Keep facts, assumptions and interpretations separate

A problem statement often contains a mixture of:

• observations;
• reported experiences;
• assumptions about causes;
• estimates of impact;
• proposed solutions.

Separating these makes the description more credible.

For example:

Observation: Customers repeatedly ask sales representatives to explain differences between service packages.

Possible interpretation: The information available before purchase may be difficult to compare.

Assumption to test: A clearer comparison would shorten the purchasing process.

The interpretation and assumption may be correct, but they should not be presented as established facts before they have been investigated.

Do not make the problem too broad

A statement such as “education should be more flexible” may describe an important theme, but it is difficult to act on.

A narrower statement could focus on:

• a particular learner group;
• a specific stage of the learning process;
• a recurring scheduling conflict;
• an accessibility limitation;
• a type of course or learning environment.

Broad issues can often be divided into several connected problems. These smaller descriptions are easier to validate, compare and address.

Narrowing the problem does not mean ignoring the larger context. It means choosing a useful starting point.

Do not make it too narrow either

A problem statement can also be written so narrowly that it describes only one person, one incident or one predetermined feature.

For example:

The export button should be moved to the top-right corner.

This may be a valid interface improvement, but it does not explain the underlying difficulty. A more useful statement might be:

Users exporting reports have difficulty locating the export function, which delays a task they perform regularly.

This leaves room to investigate whether placement, terminology, navigation or another factor causes the problem.

How to test whether the statement is clear

Ask someone unfamiliar with the issue to read the statement and explain it in their own words.

Then check whether they can answer:

1. Who experiences the problem?
2. What are they trying to do?
3. In what situation does the problem occur?
4. What makes the situation difficult?
5. Why does the issue matter?
6. Does the statement describe a problem rather than demand one solution?
7. Which parts are known, and which remain assumptions?

If the reader has to guess essential details, revise the statement. If the statement contains every possible detail, remove information that is not necessary for understanding the core issue.

A problem statement is a starting point

Writing a clear problem statement does not prove that the problem is widespread, commercially attractive or technically solvable.

The next step is to investigate:

• whether other people recognize the same need;
• how often it occurs;
• how important it is relative to other problems;
• what people currently do;
• what evidence supports the described consequences;
• whether the affected group is defined correctly.

Feedback may reveal that the original statement needs to be narrowed, expanded or divided into separate problems. That is part of the process rather than a sign that the first description failed.

If you are deciding where to begin that discussion, read Where Can I Share My Idea and Get Useful Feedback?.

Turn the problem into an Opportunity

A clear problem statement makes an unmet need easier to recognize, discuss and discover. It gives people who experience the same difficulty a way to add their perspective. It also helps companies, innovators and startups understand whether the situation could represent an opportunity for improvement.

Before sharing, check that your description:

• identifies the affected group;
• explains the situation;
• describes the difficulty without unnecessary blame;
• communicates the consequences;
• avoids confidential or identifying information;
• leaves room for different possible solutions.

If something should work better, share it as an Opportunity on Opporio. A well-defined problem can be the starting point for validation, collaboration and a better way forward.