“A problem statement describes a customer’s problem in their own words, separate from any solution. Get them right and you can test, compare and prioritise which problems are actually worth solving; get them wrong and your research measures the wrong thing.”

Seven principles make a problem statement research-ready: translate solutions into the underlying problem, write from the customer's perspective, keep each statement to a single variable, be brief, cut the jargon, make it specific to one segment, and use the present tense. This guide walks through all seven with before-and-after examples, then shares seven ways to brainstorm problems in the first place and four places these statements earn their keep.

Over 42,465 problem statements have been written and stack-ranked on OpinionX, and after analysing them, plus the many teams I talk to every week, a clear pattern emerges: most teams struggle to translate the opportunities they're weighing into a clean list of problem statements.

Every product development framework, from Design Thinking and Lean Startup to Jobs-To-Be-Done, agrees that building a great product rests on your understanding of customer problems. Yet years after these frameworks went mainstream, I still meet product teams every week who get stuck at this first step.

This post summarises the advice I share with those teams. There are no Miro templates, fill-in-the-blanks sentence recipes, or overused Einstein quotes. Just a simple list of principles for brainstorming and writing research-ready problem statements.

Here’s what you’ll find in this post:

Why problem statements matter
7 principles for writing great problem statements
7 tips for problem statement brainstorming
When and where I use problem statements

If you don't understand your customer's biggest problems, you're destined to fail

It didn't really click for me how important customer problems are until I came across Shreyas Doshi's story "Destined to Fail".

It was the biggest mindset shift I've had in building products. I realised customers only search for a fix for their highest-priority problems. So many teams fail by validating only that customers have the problem they're solving, not whether it's a high priority or just a mild inconvenience.

The cost of this mistake is stark. Shreyas says "problem severity" is the biggest contributor to startup failure. Customers don't go out of their way to fix mild inconveniences, so products aimed at mild inconveniences are destined to fail.

If success hangs on our ability to distinguish high-priority problems from mild inconveniences, we'd better get pretty good at articulating customer problems. That's what this post will help you do.

7 principles for writing great problem statements

Principle	What it means
1. Translate solutions	Tie each idea back to the problem it's meant to solve
2. Customer perspective	Write it the way a customer would actually say it
3. Single variable	One problem per statement, so results stay interpretable
4. Brevity	The longer it runs, the more room to misread it
5. Eliminate jargon	Cut anything that could be misunderstood
6. Segment specific	Write for one segment; the personal reads as universal
7. Present tense	Someone is being affected by this problem right now

Principle 1: Translate solutions

People instinctively start by writing ideas instead of problem statements. There are plenty of reasons this is the wrong approach:

Ideas get revised and reshaped many times before shipping. If you haven't captured the initial problem you're solving, the final version often ends up so far removed that it no longer solves any customer problem at all.
Giving your team a list of features to build kills their creative potential. You spent all that time hiring skilled developers and designers, only to hand them a colour-by-numbers development process.
It's common to find different functional teams working in opposite directions on the same project when a clear problem statement isn't agreed upfront. Internal confusion is an expensive mistake.
While product roadmaps are often used to store features for later, Jira tickets tend to harden into commitments over time, not ideas to reinterrogate later.

The first step is to tie your list of feature ideas back to the problem they intend to solve:

[Solution statement] I want my current inventory of dog food continuously monitored so that a new pack is automatically ordered before my current supply runs out.
[Problem translation 1] I sometimes forget that I have to manually order my next batch for delivery.
[Problem translation 2] Ordering my next batch of dog food online can leave me with no supply for a few days while I wait for the delivery.

Principle 2: Customer perspective

Writing solutions as problems isn't the only translation task. Teams often think they're writing problem statements but are actually writing internal objectives. A simple test: could a customer plausibly say this to you in conversation? For example:

[Internal perspective] We need to build an online property auction tool to help real estate agents unlock additional sales channels.
[Customer perspective] As a property agent who sells primarily through online channels, I feel like I lose customers to competitors because I can only sell via traditional pen-and-paper contracts.

Principle 3: Single variable

Imagine you ask customers to stack rank a set of problem statements and this one ranks highest: "When I first created my account, I couldn't find interesting people to follow or figure out how to complete my profile."

Multiple variables in a single statement wipe out any insight about why people ranked it highest. Is it because they struggle with making connections, or with enriching their profiles? We can't know.

When you're drafting, always review your list with fresh eyes. Might some groups read this problem differently? Have I rolled multiple problems into one statement? If so, you can't rely on it when it's time to read your results.

[Multiple variables] Screening interview applicants is time-consuming, prone to bias, and reliant on recruiters' understanding of the traits that predicted candidate success in the past.
[Single variable] Our recruiters don't have prior experience hiring employees for our function.

Principle 4: Brevity

The more you pad it out, the more room there is to misread the problem.

[Wordy]The excess degree of packaging creates a feeling of unsustainability among customers like me because it looks as though the materials used could have been drastically reduced without impacting product or delivery quality standards.
[Concise] I don't like how much excess packaging is used for deliveries.

Principle 5: Eliminate jargon

We cut jargon for the same reason we separate variables and keep things brief: minimise any chance the statement gets misread.

[Jargon]The .csv uploader doesn't fully replace the need for a native CDP integration as it currently requires significant manual formatting for my CRM to ingest accurately.
[Accessible]I have to spend a lot of time manually fixing issues in my data when I try to upload it using a spreadsheet export.

Principle 6: Segment specific

How someone is affected by a problem depends on who they are and what they're trying to do. When we try to appeal to a wide range of customer segments in every problem statement, we end up writing statements that land with no one. Counterintuitively, what's most personal tends to be most universal.

Turn multi-segment statements into separate problems from the perspective of each segment they affect. I like this iterative example from the IBM Design team:

[V1]We need to build better tire inflation machines that last at least one year without maintenance.
[V2]We need to provide more tire inflation machines to new drivers.
[V3]New drivers struggle to keep their tires properly inflated because they don't know they need to maintain their cars this way.

V1 describes a desired outcome, not a customer problem, and could apply to almost any segment. V2 makes it specific to one type of customer, new drivers. V3 translates it from a desired outcome into a customer problem. I'd add a more direct V4 written from the customer's perspective:

[V4] As a new driver, I don't feel like I know how to manage tire pressure maintenance.

Principle 7: Present tense

Past tense removes urgency by phrasing the problem as if it's no longer a current issue. Future tense statements sound like hypotheticals that may never happen. The present tense forces us to be specific and makes clear that someone is being affected by this problem right now.

[Past tense] I struggled to capture the best quotes during my user interviews because they were speaking so fast that I was already trying to come up with the next question.
[Future tense] I will have to skip ahead and think of the next question because the interviewee will be speaking so fast that I won't be able to keep up.
[Present tense] When a user speaks too fast, I'm left trying to recall and capture their original phrasing after the interview ends.

Summary of principles: stay consistent

The most important thing in a problem-led approach is consistency across all your problem statements. You can test, compare and prioritise them best when they share the same writing style (tense, perspective, segment, and so on).

7 tips for problem statement brainstorming sessions

Those principles will help you write better problem statements, but they're not much use if you're struggling to think of any customer problems in the first place. Here are 7 tips for kickstarting a brainstorming session.

I. Desired outcomes

This story from Teresa Torres changed how I think about problem-solving. Teresa was attending a talk by Bernie Roth (founder of Stanford's d.school). Bernie asked attendees to write down something they wanted in life, giving examples like a new house, a better job, or more leisure time.

Next, Bernie asked a second question: "If you had whatever you wrote down today, what would that do for you?" Why would you be better off than before? If you said you wanted a new house, maybe your next answer would be "If I owned a house, I'd feel more grounded in my community."

The real value came in his third question: "How else could you feel more grounded in your community?" Instead of buying a house, couldn't you join a social club or volunteer locally? That reframing breaks our fixation on a single solution and opens up other ways to reach the same goal.

Teresa says every customer opportunity (a need, pain or desire) requires a "desired outcome" parent. You shouldn't solve a customer problem unless it aligns with one of your team's goals. You can run this in reverse to boost your brainstorming: map each problem to the customer's desired outcome, then use that outcome to think of alternative ways customers might try to reach it. Those alternative journeys spark a fresh list of obstacles and problems customers encounter.

II. The Smart Sailboat

The Smart Sailboat (by New Haircut) is a SWOT-style sticky-note exercise. Starting with team objectives (the harbour) and successes to date (the wind) gives your brainstorming clear context to draw from. My favourite part: instead of lumping all problems together, it forces you to separate internal weaknesses (anchors) from external threats (icebergs).

III. The value of abstraction

I love this short explanation from Patrick Whitney (Co-Founder of Harvard's Design Lab) about how "abstracting design problems" led to the success of iTunes in the early 2000s.

Look at your list of problems: which statements depend on a specific medium, channel, process or perspective? Could you imagine a fix independent of those factors? If so, try writing an extra problem statement a layer removed from that baggage.

IV. Specific scenarios

I love the ban on hypotheticals in the book The Mom Test. Questions like "How do you usually approach doing X?" let people imagine the best version of themselves, immune from distraction and office politics. But real life isn't vague like that.

Asking about specific scenarios ("When was the last time you did X? Can you walk me through it?") gets you rich insight about the actual challenges someone faced, who got in their way, and what they did to overcome it.

The same applies to writing problem statements. Your user base is a diverse group, and trying to write statements that cover everyone at once produces vague problems that represent no one. At OpinionX, our customers range from product teams to government policy teams to high school teachers. If we tried to write statements that fit all of them, we'd end up with a generic pile of nothing.

I don't use fake personas, though. I think about a specific customer I know well and have talked to many times. Focusing on one person lets me soak up the nuance in their use case, which unlocks a deluge of specific details in brainstorming.

V. Continuous discovery

For many teams, brainstorming is a calendar event that brings everyone together to think creatively. The best teams use Continuous Discovery Habits to collect quotes, feedback and problems from their customers every week. They test their biggest assumptions in user interviews and derisk projects early through iterative experimentation.

VI. Peripheral problems

Validating that people experience the problem you're solving is meaningless if that problem is only a mild inconvenience they're barely aware of. You need to identify the wider range of problems customers are juggling day to day to work out whether you're chasing something high on their priority list.

These other priorities are peripheral problems. If you can't articulate them, you'll be stuck tinkering on a fix without knowing whether customers will ever care about it. Mapping peripheral problems builds a deeper understanding of your customer's overall context.

VII. Brainstorm alone, shortlist together

Ethan Mollick summarised 50+ years of academic research on brainstorming in a viral thread. His conclusion: group brainstorming feels fun and creative, but as soon as you're in a group, people self-censor and get influenced by others, so you end up with fewer and worse ideas. The fix? Brainstorm alone, shortlist together.

When and where I use problem statements

A. Feature spec docs

The first thing I do before building any new feature is write a specifications document, and the first section in every spec doc is the customer problem statement. A clear problem statement means team members can independently answer most questions that come up during development, without approval bottlenecks.

B. Opportunity backlogs

Instead of a product roadmap full of feature ideas, the Opportunity Backlog lists the customer needs, pains and desires you intend to solve. By prioritising opportunities over feature ideas, empowered product teams can find the best fixes themselves instead of getting handed prescribed features by leadership.

C. Roadmap prioritisation

Every quarter, we create a list of problem statements and ask our most active users to rank them, so we understand which problems affect their success most. Customer Problem Stack Ranking gives us real data to align behind, not vague opinions to debate. I can't imagine running a product team without it.

D. Idea validation experiments

We've also used problem statement ranking to validate whether an idea solves an important enough customer problem to pursue. For example, we were once about to start a 3-6 month project to integrate an external tool for recruiting survey participants. At the last minute, a quick stack ranking survey showed us that customers had plenty of higher-impact problems we could solve in a fraction of the time.

Taking the first step

The best teams are empowered, problem-led and customer-focused. But the first step to becoming one isn't to throw out all your existing processes.

Start by creating a home for problem statements: a place where team members can contribute and catalogue the problems they hit in their customer conversations. I hope the principles and brainstorming tips here get you a step closer to becoming a problem-solving machine.

Book a free setup call ➡️

Frequently asked questions

What is a problem statement? A problem statement describes a customer's problem in their own words, kept separate from any solution. In user research, good problem statements are what you test, compare and prioritise, so writing them cleanly is what makes the results trustworthy.

How do you write a good problem statement? Follow seven principles: translate any solution back into the underlying problem, write from the customer's perspective, keep each statement to a single variable, be brief, cut the jargon, make it specific to one customer segment, and use the present tense.

Why do problem statements matter in research? Because customers only go looking for fixes to their highest-priority problems. If you validate that a problem exists but not whether it's a priority, you can build something nobody cares enough about to adopt. Problem statements let you rank severity, not just confirm existence.

How do you come up with problem statements to write? Start from your customers' desired outcomes and work backwards, run a structured exercise like the Smart Sailboat, abstract problems away from a specific medium, ask about specific past scenarios, not hypotheticals, and brainstorm alone before shortlisting as a group.

Daniel, Founder & CEO, OpinionX

OpinionX is the platform for advanced market research surveys. Product teams use it to get real data on their customers' biggest needs, so everyone can align behind the most important problems worth solving.

Create your first survey for free.

How To Write Problem Statements for UX Research (With Examples)