Writing Problem Statements Improves Product Thinking

Most of the teams I’ve helped either didn’t use problem statements, or didn’t use them well. Without improving, they spend more time and money than needed to build things, and much of what they build is worthless or wasted.

The problem statement exists to address three critical flaws in most product development processes.

1. To deepen shallow product thinking to identify meaningful outcomes.
2. To empower product leaders to shape the product strategy through choosing what to do and choosing what not to do.
3. To reduce the confusion, delays, and waste teams face as a result of not knowing why something is being asked for and not knowing what good enough looks like.

Let’s focus on the first challenge – shallow product thinking.

A problem statement both captures and communicates a shared understanding of a problem. Capturing your understanding is maybe the wrong metaphor – distilling your understanding is probably better. It is the act of writing and rewriting the problem statement which increases your depth of understanding of the problem you want to address.

While there are multiple formats you can use to document a problem statement, there are four aspects of the problem you must clearly articulate. What you are capturing is

1. Your impressions of what’s wrong
2. Who this problem hurts
3. Why addressing this problem matters
4. How much better things will be if you can somehow find a way to solve the problem.

Two aspects of how you shape the problem statement are critical to delivering outcomes.

1. The Goldilocks Problem: is the problem you are tackling the right size?
2. The Insight Problem: are you framing the problem in a way which is meaningful and potent?

The Goldilocks Problem

The problems you define must be small enough to be deliverable

Your product development process embodies a cadence for focusing teams on the work, and then asking “what’s next?” Scaled Agile, for example, uses program increments (PIs) to establish the heartbeat for delivery of solutions to problems – and a 12 week PI is the most common. Other operating models commonly use a quarterly cadence for product roadmapping and recurring business reviews (QBRs). Defining problems which can be addressed inside a quarterly increment is a rational constraint. This is your yardstick: problems which are large enough and small enough to deliver on a relatively consistent cadence.

The problems you define must be large enough to be meaningful

Problems which are too small become very expensive – the overhead incurred to align on the problem, prioritize the problem, and manage the activities of solving the problem is somewhat fixed. For a particularly small problem, it may cost the company more to manage the process than it costs to implement the solution. The problem being defined in your problem statement could be too small. Size is less important than clarity, but both matter. This is your lower-bound: problems which make economic sense to pursue, given the overhead and opportunity costs of pursuing them.

The problems you define must be focused enough to be actionable

A problem defined too abstractly is not a problem your teams can internalize, understand, and execute to address. Without guidance a team will either stall or jump to conclusions and run in whatever direction makes sense from their vantage point.

When the definition of a problem is wide open – “we need to be 2% more profitable” – there is no guidance to the team. More profitable by any means necessary? There are so many ways to become more profitable – increase prices, reduce costs, increase volume to better allocate fixed costs. There is no guidance to the team. This level of abstraction needs to be reduced until something is actionable. “Reduce material costs by 2%” or “Increase sales to new customers by 10%.” The exact level of specificity you need depends on how senior your team is and how steeped in the domain they are. This is your litmus test: problem statements which provide clarity of purpose without providing dictation of approach.

With an overly-abstract problem statement, you never initiate the conversations about how your team might approach solving the problem. With an overly prescriptive dictation, you prevent the conversations which allow your team to bring better ideas to the table and improve the ideas you already have.

The Insight Problem

How you think about the problems you’re trying to solve may be as important as the selection of which problems you want to solve. In What’s Your Problem?, Thomas Wedell-Wedellsborg encourages us to ‘break the frame’ when thinking about the problems we’re trying to solve. His main point is that how we describe a problem – to ourselves and to others – both biases and constrains how we approach solving the problem.

Consider the ‘not enough profit’ problem above – making the problem more concrete in terms of needing to increase revenues or needing to decrease costs to increase profitability is a necessary but not sufficient step in fixing your problem statement.

Take the problem of not having enough revenue, consider the consequences of framing the problem in different ways. Revenue for the company is simply the revenue per customer times the number of customers. To increase revenue do you need more customers, or do you need more revenue per customer? When increasing revenue per customer, are you trying to increase your share of their total spending in your category, or are you trying to increase their loyalty to you in terms of repeat purchases in a narrow slice of your category?

How you frame the problem will drive how you imagine solving it. More repeat purchases or larger purchases? The direction in which you act is biased by how you frame the problem. The context in which you find yourself can cause one framing to be strategically well-aligned, where the other is not. Are you in a modularized market where best-of-breed competitors win their niches, or an integrated market where broader solution providers have greater appeal to customers? Is your strategy to be all things to some people, or one thing to all people?

When your problem identification starts in the context of a product strategy and measurable objectives, this “are we aligned?” question is easier to answer. When you lack that context, you should start by identifying a set of problems (and problem statements) which are aligned with each other. Infer a strategic outcome which would result from solving this set of problems, and confirm with your leadership that this is what is desired.

Start Improving Right Now

You can start right now by writing meaningful, actionable problem statements. Then you can invest to optimize the flow of work by resizing the problems to better match the cadence of your process. Once those foundational skills are under your belt, only then should you begin to shape your product with improved framing of the problems you choose to solve.