Info iconLetter I in a circle

By continuing to use this site you consent to the use of cookies in accordance with our cookie policy

For better products, start with a problem statement

Main illustration: Kitkat Pecson

At Intercom, we believe product managers (PMs) should focus on problems, not solutions. Indeed, our first R&D principle is “Start with the problem.”

The secret to shipping successful product, then, is clearly defining for your team the problem that you’re setting out to solve. A great problem statement supercharges product development. It inspires and guides your design team, it makes evaluation simple, and it creates direction for scoping and iteration.

Intercom’s R&D Principles from Intercom

But a problem statement is useless if it’s not written correctly. It isn’t a product requirements document (PRD) or a specification (spec). A problem statement focuses on what the customer needs, not what you think the solution should be. This makes it hard and counterintuitive, because as humans we’re wired to think in solutions.

So what should your problem statement include, and how can you write a great one?

The three parts of a great problem statement

A problem statement should always contain three pieces of information: the outcome that the customer wants, why they want that outcome, and problems with the status quo.

1: The outcome the customer wants

We build our products for our customers, and the core of a good problem statement is a clear description of the result that a customer is seeking to achieve. Well-framed outcomes will refer to customer needs, and not to your product specifically. For example, various forms of transport deliver the outcome of getting from A to B quickly and comfortably.

This spirit is summed up by a quote commonly attributed to Henry Ford: “If I had asked people what they wanted, they would have said faster horses.” Consumers talk about what they want (faster transport) with reference to the current product, but by focusing on the need a new product (automobiles) comes into view.

2: Why they want that outcome

Understanding why a customer wants an outcome enables more effective, more creative solutions than are possible when focusing simply on the result.

“We made sure to get a deep understanding of why Intercom customers were asking for tickets”

Consider the delay between disembarking a flight and picking up our baggage. Everyone wants to get their luggage off the carousel as quickly as possible. Why? Because standing around at the airport is tedious. Growing traveler volumes make it difficult for airports to reduce baggage delivery times, but some airports are breaking up the boredom and reducing perceived delay by spicing up terminals and walkways with digital jungles and other curiosities. By focusing on why travelers want their bags quickly, airport designers unlock creative solutions to an otherwise seemingly intractable problem.

Closer to home, we made sure to get a deep understanding of why Intercom customers were asking for tickets, which in turn allowed us to solve these customer problems without creating tickets as they exist in many other products.

3: Problems with the status quo

The final element of a problem statement is pinpointing what’s wrong with the current solution. Describing what’s most painful about the current solution creates clear criteria to use in evaluating how successful a potential solution is.

For people who wanted to travel from A to B for business, automobiles were a superior solution to horses due to their speed and comfort. A century later, Zoom solved the same problem in a radically different way, removing any delay or discomfort by eliminating the need to travel at all.

By including these three things in each problem statement you’ll be setting your design team up for a productive, successful process that should lead to a product or feature that users love.

Use a job story to avoid common mistakes

The most useful tool that I’ve found for writing crisp problem statements that include all three key parts is job stories. A job story describes the situation in which a problem occurs, the outcome that the customer wants, and the reason that they want that outcome. It’s a sentence with the following formula:
[ When _____ ] [ I want to _____ ] [So I can _____ ]

Job stories look simple, but can be surprisingly difficult to write. That’s a good thing, as it forces you to understand your customer more deeply. Job stories also contain some clever constraints that help avoid common mistakes in problem framing.

It describes a problem for a person. The starting point for product design should always be a customer problem. This applies even if you’re building internal tools for an internal customer. You may find that you want to work with business problems, for example encouraging a certain customer behavior or driving a financial metric such as revenue. For these projects, you first need to identify the customer problem that you believe prevents the desired behavior or business outcome. I use the Product Impact Framework to do this.

“Job stories focus on what the customer wants to do, not what your product is capable of”

It doesn’t prescribe a solution. Job stories focus on what the customer wants to do, not what your product is capable of. Focusing on the customer’s objective expands the potential ways you can solve the problem and reduces the chance you miss disruptive changes, such as from horses to cars. If you find yourself starting from a desired solution, ask yourself what it is about that solution that you believe customers will find so compelling and use that to craft your problem statement.

It provides a clear definition of success. When you’ve written a good job story, it becomes easy to evaluate the relative success of potential designs or the performance of shipped product against the stated problem. Rather than a simple metric that you move (or don’t move), a problem statement based on a job story provides rich detail to help understand to what extent you’ve solved a problem and point towards potential changes or improvements on the initial solution.

It surfaces assumptions but doesn’t demand validation. Writing a problem statement as a job story lays bare what you believe about customers, and their goals and motivations. It’s best to create them based on customer research, but this isn’t necessary for a good job story. If you’re embarking on a visionary project you can still articulate the problems that you believe exist for customers and how your product solves them. If the product doesn’t perform exactly as you expect, you’re well placed to identify and adapt any assumptions that may be faulty, and avoid making the same mistake next time.

Many mistakes that we make as product managers can be traced back to a poor understanding of the customer problem that we were trying to solve. By investing time to deeply understand the customer problem and framing it the right way, you’ll create a sharp focus for your team, accelerate the cycle of designing, building, and learning, and overall improve your ability to ship product that customers (and your finance team) will love.