For better products, start with a problem statement

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 is clearly defining for your team the problem that you’re setting out to solve. A great problem statement provides this definition and supercharges the product development process. It inspires and guides your design team, it makes evaluation simple, and it provides direction for scoping and iteration.

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 great problem statement contains three key parts to ensure that it defines what your customer needs, not what you think the solution should be.

The three parts of a great problem statement

To effectively guide development of great features, your problem statements should always contain three pieces of information: the outcome that the customer wants, why they want that outcome, and what’s painful about the status quo. Let’s look at each of these in more detail.

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 refer to customer needs, and not to any specific feature.

At Intercom our customers would often ask us for “tickets”, a system to assign a unique ID number to every customer query.

“By focusing on the outcome your customers want, your team can solve for this outcome in new and innovative ways”

But when we talked to our customers, we realized that the outcome they wanted was to easily track the status of all their queries and to ensure that queries didn’t get lost, especially as they were passed through multiple teams. A 12-digit ticket ID number is one way to achieve this, but it’s not actually necessary. In the end we built a suite of new workflow tools, but no ticket numbers. We enabled the outcome for our customers, but in a uniquely Intercom way. The key to achieving this was focusing on the outcome our customers wanted, not the features they asked for.

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.” Your customers will talk about features that they want (faster horses) but by focusing on the outcome they want, your team can solve for this outcome in new and innovative ways.

2: Why they want that outcome

Understanding why a customer wants an outcome enables you to consider more creative and possibly more effective solutions than you’d consider if you focused simply on the result.

The reason that our customers want to track and measure queries from their customers is that they want to orchestrate great customer experiences easily and efficiently.

“We avoided a slew of urgent follow-up requests that are common to feature launches that miss the core problem”

Because we knew that efficiency was a driving reason for this feature request, we prioritized workflow features such as rules. Automation isn’t necessarily a core part of a traditional ticket, but because we understood why our customers wanted the outcome of tracking conversations, we could confidently develop features that solved the problems our customers really faced. As a result, we avoided a slew of urgent follow-up requests that are common to feature launches that miss the core problem, and thus requires significant iteration.

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 provides focus for your new solution, and creates clear criteria to use in evaluating potential solution concepts.

“Knowing these pain points helped us prioritize where we spent our time and clarified for us what our customers were really trying to do”

When we talked to customers who wanted us to create tickets, they pointed to complex conversation workflows that they wanted to create but couldn’t, as well as situations where conversations could get lost when passed between multiple teams.

Knowing these pain points helped us prioritize where we spent our time and clarified for us what our customers were really trying to do. We realized that we could overcome these specific issues with new automation and reporting capabilities and without resorting to long, impersonal numbers. This realization enabled us to make Intercom better for power-users while preserving the personal touch that fits our mission to make internet business personal.

Setting yourself up for success

A crisp understanding of what our customers found painful about managing support queries enabled us to provide the efficiency benefits of a ticketing system within Intercom without resorting to an impersonal ID number. We were only able to do this because we deeply understood the outcome that our customers wanted, why they wanted that outcome, and what was painful about achieving that outcome today.

By starting with the problem and defining these three key aspects in your problem statement, you’ll be setting your team up to ship creative, effective, and highly distinctive products to your own customers.