If you want to ship a great products that users love, you need to start with a clear understanding of what problem you’re trying to solve for your user and why.

Start with the problem 

<ul><li>Start with the solution. While a problem statement comes before design in the process of product development, as people we tend to think in solutions.</li><li>Try wrong answers. Ask yourself what it is about the wrong solution that makes it unacceptable, and include that in your problem statement.</li><li>Talk to customers again.</li><li>If you’re having trouble getting your head around a problem space, try laying out the specific problems felt by the people involved.</li><li>Start designing. Particularly when feeling blocked, this approach can open up perspectives and possibilities that you might not have considered beforehand.</li><li> A focused problem statement will help align the rest of your team throughout the design and build process.</li><li>Eliminate judgment words (“too slow”, “badly designed”, or “confusing”).</li></ul>

Techniques for writing a great problem statement

<figure><img src="https://blog.intercomassets.com/blog/wp-content/uploads/2021/09/Harry-Woodgate-1800x840.jpeg" alt="Intercom illustration by Harry Woodgate" width="785" height="366"></figure>If you want to ship great product that users love, you need to start with a clear understanding of what problem you’re trying to solve for your user and why.At Intercom, we always “<a href="https://www.intercom.com/blog/?p=26393&amp;preview=true" dir="ltr">start with the problem</a>” when beginning any project – it’s part of how we apply the <a href="https://www.intercom.com/resources/books/intercom-jobs-to-be-done" dir="ltr">Jobs-to-be-Done framework</a>. As product managers, this means we must carefully research and understand the problems we’re actually solving for our customers. To capture our thoughts and give clear definition to our team, we write a document called a <a href="https://www.intercom.com/blog/how-to-write-problem-statements/" dir="ltr">problem statement</a>.<BLOCKQUOTE>“It takes thought, writing, re-writing, and research. And it’s easy to get stuck along the way”</BLOCKQUOTE>Writing a problem statement can seem like a formality, but when you get down to it the process is deceptively hard, requiring a deep understanding of customers and the ability to grapple with abstract concepts.I have yet to sit down and simply dash off a problem statement in a single session. It takes thought, writing, re-writing, and research. And it’s easy to get stuck along the way. Here are seven techniques that I’ve found helpful to un-stick yourself as you draft a problem statement.<h2>1. Start with the solution</h2>While a problem statement comes before design in the process of product development, as people we tend to think in solutions. As a result, you’ll often find problems come to you as solutions or feature ideas, and you’ll need to work backwards towards the underlying problem.<BLOCKQUOTE>“A&nbsp;good problem statement will lay out what you assume matters to customers and force you to describe what’s most useful to customers about your proposed solution”</BLOCKQUOTE>To do this, ask yourself “what problem would this solution solve?” and “why do I think customers will prefer this solution to the status quo?” Even if you’re already committed to building a particular thing, a good problem statement will lay out what you assume matters to customers and force you to describe what’s most useful to customers about your proposed solution. Having this on paper helps your team focus its energy on the parts of the feature that solve the most important parts of the problem for your customers.<h2>2. Try wrong answers</h2>It’s common to struggle with figuring out what the real problem for a customer is. Using the <a href="https://www.intercom.com/blog/accidentally-invented-job-stories/" dir="ltr">job story structure</a> guides your problem statement to the right zoom level, but thinking up seemingly wrong solutions to your problem helps define the criteria for a good solution.Ask yourself what it is about the wrong solution that makes it unacceptable, and include that in your problem statement. If you can’t find a customer-centric justification for eliminating the wrong solution, perhaps it’s actually worthy of consideration.<h2>3. Talk to customers again</h2>Talking to customers is standard advice for PMs, but even when you’ve immersed yourself in your customers’ worlds, you’ll find at times that you struggle to articulate the detail of what a customer wants to achieve, or nail down what’s wrong with the status quo.<BLOCKQUOTE>“After even a handful of discussions you’ll quickly uncover what does (and doesn’t) matter to your customers”</BLOCKQUOTE>At this point, the fastest way to make progress is to simply go back and clarify these points with your customers. Concepts that seemed vague or issues that seemed important usually come into sharp relief when you talk to the people who use your product. After even a handful of discussions you’ll quickly uncover what does (and doesn’t) matter to them.<h2>4. Focus on a person</h2>It’s common to struggle with the right level at which to frame a problem: maybe you are trying to resolve a problem for your business, or you see an issue which affects a whole organization rather than one person.Because it’s people who buy and use your product, a good problem statement will be focused on a problem (or problems) for a person (or people). If you’re having trouble getting your head around a problem space, try laying out the specific problems felt by the people involved.<h2>5. Start designing</h2>Most problem statements are created iteratively. It’s very difficult to perfectly specify all the constraints in a solution space up front, so sometimes it’s easier to start designing solutions.<BLOCKQUOTE>“This approach can open up perspectives and possibilities that you might not have considered beforehand”</BLOCKQUOTE>Particularly when feeling blocked, this approach can open up perspectives and possibilities that you might not have considered beforehand. This can also bring into sharp relief what problems with the status quo are most challenging to resolve.<h2>6. Skip the preamble</h2>For some reason PMs (myself included) are inclined to begin a problem statement with historical scene-setting. Don’t do this, it’s usually an indication that you don’t understand the customer problem.Instead of starting with “Last quarter we launched XYZ feature and…”, skip straight to what the customer wants, when this need occurs, and what they’re trying to achieve by wanting this. A focused problem statement will help align the rest of your team throughout the design and build process.<h2>7. Eliminate judgment words</h2>Great problem statements describe facts about your customers and what they want. As such, avoid using judgmental words about your product in your problem frame. Judgment terms such as “too slow”, “badly designed”, or “confusing” are ambiguous and could be interpreted differently by each person reading the problem statement.<BLOCKQUOTE>“If your product doesn’t solve a meaningful problem, then customers just won’t use it”</BLOCKQUOTE>You should replace these with data-based statements. Instead of saying “our onboarding flow is confusing,” clearly state what customers are confused about. Instead of saying “we need to redesign our settings page,” state what specifically customers can’t do from the settings page that they need to, and why they want to do that.Framing problems is hard. But getting it right is of critical importance as it determines the quality of the product your team ships. Regardless of how well-designed and scalable your product ultimately ends up, if it doesn’t solve a meaningful problem, then customers just won’t use it. Hopefully some of these practices can help you get moving again when you’re stuck. Embrace the struggle, it’s worth it.<img src="https://blog.intercomassets.com/blog/wp-content/uploads/2018/10/JTBD-book-CTA.png" alt="JTBD book CTA" width="434" height="181">

Writing a problem statement can be deceptively hard – here are 7 techniques to un-stick yourself as you draft a problem statement.

Stashed ideas

If you want to ship great product that users love, you need to start with a clear understanding of what problem you’re trying to solve for your user and why.

At Intercom, we always “<a dir="ltr" href="https://www.intercom.com/blog/?p=26393&amp;preview=true">start with the problem </a>” when beginning any project – it’s part of how we apply the <a dir="ltr" href="https://www.intercom.com/resources/books/intercom-jobs-to-be-done">Jobs-to-be-Done framework </a>. As product managers, this means we must carefully research and understand the problems we’re actually solving for our customers. To capture our thoughts and give clear definition to our team, we write a document called a <a dir="ltr" href="https://www.intercom.com/blog/how-to-write-problem-statements/">problem statement </a>.

“It takes thought, writing, re-writing, and research. And it’s easy to get stuck along the way”

Writing a problem statement can seem like a formality, but when you get down to it the process is deceptively hard, requiring a deep understanding of customers and the ability to grapple with abstract concepts.

I have yet to sit down and simply dash off a problem statement in a single session. It takes thought, writing, re-writing, and research. And it’s easy to get stuck along the way. Here are seven techniques that I’ve found helpful to un-stick yourself as you draft a problem statement.

While a problem statement comes before design in the process of product development, as people we tend to think in solutions. As a result, you’ll often find problems come to you as solutions or feature ideas, and you’ll need to work backwards towards the underlying problem.

“A good problem statement will lay out what you assume matters to customers and force you to describe what’s most useful to customers about your proposed solution”

To do this, ask yourself “what problem would this solution solve?” and “why do I think customers will prefer this solution to the status quo?” Even if you’re already committed to building a particular thing, a good problem statement will lay out what you assume matters to customers and force you to describe what’s most useful to customers about your proposed solution. Having this on paper helps your team focus its energy on the parts of the feature that solve the most important parts of the problem for your customers.

It’s common to struggle with figuring out what the real problem for a customer is. Using the <a dir="ltr" href="https://www.intercom.com/blog/accidentally-invented-job-stories/">job story structure </a>guides your problem statement to the right zoom level, but thinking up seemingly wrong solutions to your problem helps define the criteria for a good solution.

Ask yourself what it is about the wrong solution that makes it unacceptable, and include that in your problem statement. If you can’t find a customer-centric justification for eliminating the wrong solution, perhaps it’s actually worthy of consideration.

Talking to customers is standard advice for PMs, but even when you’ve immersed yourself in your customers’ worlds, you’ll find at times that you struggle to articulate the detail of what a customer wants to achieve, or nail down what’s wrong with the status quo.

“After even a handful of discussions you’ll quickly uncover what does (and doesn’t) matter to your customers”

At this point, the fastest way to make progress is to simply go back and clarify these points with your customers. Concepts that seemed vague or issues that seemed important usually come into sharp relief when you talk to the people who use your product. After even a handful of discussions you’ll quickly uncover what does (and doesn’t) matter to them.

It’s common to struggle with the right level at which to frame a problem: maybe you are trying to resolve a problem for your business, or you see an issue which affects a whole organization rather than one person.

Because it’s people who buy and use your product, a good problem statement will be focused on a problem (or problems) for a person (or people). If you’re having trouble getting your head around a problem space, try laying out the specific problems felt by the people involved.

Most problem statements are created iteratively. It’s very difficult to perfectly specify all the constraints in a solution space up front, so sometimes it’s easier to start designing solutions.

“This approach can open up perspectives and possibilities that you might not have considered beforehand”

Particularly when feeling blocked, this approach can open up perspectives and possibilities that you might not have considered beforehand. This can also bring into sharp relief what problems with the status quo are most challenging to resolve.

For some reason PMs (myself included) are inclined to begin a problem statement with historical scene-setting. Don’t do this, it’s usually an indication that you don’t understand the customer problem.

Instead of starting with “Last quarter we launched XYZ feature and…”, skip straight to what the customer wants, when this need occurs, and what they’re trying to achieve by wanting this. A focused problem statement will help align the rest of your team throughout the design and build process.

Great problem statements describe facts about your customers and what they want. As such, avoid using judgmental words about your product in your problem frame. Judgment terms such as “too slow”, “badly designed”, or “confusing” are ambiguous and could be interpreted differently by each person reading the problem statement.

“If your product doesn’t solve a meaningful problem, then customers just won’t use it”

You should replace these with data-based statements. Instead of saying “our onboarding flow is confusing,” clearly state what customers are confused about. Instead of saying “we need to redesign our settings page,” state what specifically customers can’t do from the settings page that they need to, and why they want to do that.

Framing problems is hard. But getting it right is of critical importance as it determines the quality of the product your team ships. Regardless of how well-designed and scalable your product ultimately ends up, if it doesn’t solve a meaningful problem, then customers just won’t use it. Hopefully some of these practices can help you get moving again when you’re stuck. Embrace the struggle, it’s worth it.

7 proven techniques for writing a great problem statement

Start with the problem

Techniques for writing a great problem statement

It's time to

READ

LIKE

A PRO!

Problem Statements in UX Discovery

7 Sales Techniques With Proven Success

Tackling the problem: A simple three-part framework to align your team’s efforts