A Better Problem Statement Template

To improve how you build products, you need to write problem statements defining which problems you intend to solve. This helps your thinking, shapes your strategy, and creates purpose for your people. Writing your problem statements with a good template makes this easier.

There are several different formats which have been developed for problem statements, and you could use free-form narrative as well. After hundreds of hours helping write and utilize problem statements with dozens of teams over the years, I’ve evolved the template I use and recommend; because it works better in theory and in practice.

A Good Problem Statement Template in Theory

To assert what a good problem statement format would be, you have to define explicitly what jobs you are doing when you want to use a problem statement to become better at doing them.

As an aside – this is also how to think about building a product which is better for your customers, but that’s another topic for another day.

There are three primary jobs you need to do when building products.

1. Decide which problem you’re trying to solve. A good problem statement helps you to improve your product thinking about what it means to be better.
2. Make collective decisions to manifest a product strategy. A good problem statement helps you more effectively shape your product to support your strategy.
3. Assure everyone is aligned to the purpose of the work. A good problem statement creates clarity of purpose and aligns teams to outcomes not outputs.

Instead of trying to judge and “score” different problem statement formats, I’m going to share my experience – successes and challenges and failures – at using a good template, and then shifting to one which worked better with real teams.

For many years, I used the same template as other good product folks, like Kent McDonald. In short, what I found is that this template is great for people who already know how to write problem statements, and embodies a challenge for people who are new to shifting their orientation away from outputs and towards outcomes.

A Short Walk Through Problem Statement History

As far as I can tell, the problem statement as artifact goes back to 2002’s Use Case Modeling by Bittner and Spence (p.69). This is the format Kent and I both used, probably along with thousands of others. In 2003, Managing Software Requirements: A Use Case Approach by Leffingwell and Widrig (p.101) introduced a slightly different syntax.

Scaled Agile shares a narrative, free-form approach (figure 4) for problem statement writing. Dean references his work from 2007 & 2011 in support of this page.

In 2009, Esther Derby and Diana Larson shared the use of an Ishikawa diagram to generate a shared understanding of the problem and its root causes in Agile Retrospectives (p.88). I was also using Ishikawa diagrams in 2008. I was using the fishbone diagram exclusively as a root-cause-analysis technique to improve thinking about problems. For me, this evolved out of trying to help people address the challenges with defining problems at the proper level of abstraction. As a spatial thinker, I love using the Ishikawa to build my mental model of reality and improve my thinking. But the approach only helps with that first job.

In my practice, training, and workshops, I’ve evolved into a combination of the two structured text-based templates, because I found this combination to be more effective in practice with people new to writing problem statements, and new to reading problem statements.

Being effective in practice requires solving for additional realities beyond what makes sense purely theoretically. There’s a joke – “In theory, practice matches theory. In practice, it does not.”

A Good Problem Statement Template in Practice

One thing I learned when I began doing formal transformation work as part of my practice in product management was that you will fail if you simply provide someone with “the answer.” You cannot declare that the end-state is the right one, and have people and organizations magically teleport to this new way of doing things. You have to meet people “where they are” and help them make the journey to where they need to be.

Problem statements do three jobs once they are in use – they improve product thinking, they improve product strategy shaping, and they provide clarity of purpose to the teams building the product. A good problem statement template helps with all three.

A bad problem statement template is one which makes it harder to achieve those three benefits. The purpose of the template is not to have a template, or even to capture a problem statement. The purpose of the template is to make problem statements more effective at doing what they need to do. Making the act of writing a problem statement more effective at improving your thinking about the problem, etcetera.

To be good as a template, the format needs to make it easier to improve your thinking about the problem. Ishikawa diagrams help with this, the structured formats from Bittner and others help with this. Free-form narrative structures, while incredibly useful for storytelling and motivation, do not help someone new to problem-definition to shift away from project-definition and solution-dictation. Ad hoc narrative structure doesn’t help, so I don’t encourage product managers to use it.

To be good as a template, the format needs to make it easier to reason across multiple problem statements simultaneously; to have a triggered recall of the essence of a particular problem and to facilitate comparison and organization of a set of problems to be solved. The Ishikawa, while great for understanding and abstracting the nature of a specific problem, is not at all good for simultaneously evaluating multiple problems – primarily because of the inconsistency in levels of abstraction and differing models of problem-decomposition.

To be good as a template, the format needs to make it easier to provide clarity of purpose to the people and teams involved in creating the product, and regularly across the organization to people not intimately familiar with the work being done. I’ve personally shifted away from Ishikawa diagrams and towards impact maps as tools for capturing causal-relationships. I can elevate the development of hypotheses as principle elements of product operations when using impact maps, whereas the Ishikawa effectively embeds assumptions of causal relationship within the diagram, where they are harder to interrogate and are easily assumed to be Truth. Which they are not. The Ishikawa therefore proves to be less effective

I’ve found that engineering teams, designers, product folks, and stakeholders can all leverage impact maps to effectuate their shift from an output-orientation to an outcome-orientation while introducing hypotheses. Asking teams to learn to use both impact maps and Ishikawa diagrams for representing differing perspectives on the same purpose introduces chaos. Ask me how I know. So while I am happy to help a product manager develop an Ishikawa diagram to improve their thinking about a problem, I do not encourage them to use it for providing clarity of purpose across the organization.

A good problem statement template helps the organization on the journey from being output-oriented in a dictatorial system (“build this because someone said so”) to outcome-oriented in a purpose-directed system (“build whatever to solve this problem”).

In theory, you can isolate variables and simplify the definition of ‘good’ while in practice you have to account for the context and environment. The better problem statement template is the one which which works and works in the real world.

A Better Problem Statement Template

• The Problem of…
• Affects Whom…
• The Impact of Which is…
• The Benefits of a Solution Are…

I detailed a couple years ago why these four elements are necessary and appropriate for the problem statement to be useful in the context of writing epics within a system of product operations.

In practical terms, I will add a couple experiences about the exact words used in the template.

“The problem of…” has not caused anyone I’ve worked with to stumble beyond the philosophical shift away from projects to problems. Getting people to think at the right level of abstraction is something I address with other techniques.

“Affects whom…” addresses a grammar nuance in English. I occasionally see people get tripped up by “affects” vs. “effects” when using the more popularized templates. I think this results from having been immersed in feature factories where dictation displaced purpose – “Build this because of that bad thing.” What I do in practice is ask the question “who does this affect?” when presenting the template. Keeping Whom front and center helps shift away from results, and helps in shaping a customer-centric strategy around solving some problems for some customers while deferring the solution of problems for other customers.

“The impact of which is…” has shown to be a better prompt than “and results in…” The problem statement must generate an understanding how big the problem is to inform the decision to solve it. With the latter format, people consistently describe surface-level effects or manifestations, and not the magnitude of consequences of leaving the problem unaddressed. Keeping impact front and center acts as a nudge towards outcome-orientation reinforcing in tiny ways hundreds of times.

“The benefits of a solution are…” has repeatedly proven to be a better prompt than “a successful solution would…” Instead of describing the benefits of a successful solution, people consistently instead describe the solution they imagine building. This is like trying to jog the wagon out of the ruts in the road. In the middle of a workshop, with clarifying text in front of them, people still get stuck in the rut.

Problem Statement Template TL;DR

I’ve reviewed hundreds of problem statements and worked with scores of teams for years to improve, embody, and embrace problem statements throughout their product operations – from developing product strategy to executing to deliver. I recommend the following format for using problem statements to be more effective.

• The Problem of…
• Affects Whom…
• The Impact of Which is…
• The Benefits of a Solution Are…