What It Is
The problem statement is a structured set of statements that describe the purpose of an effort in terms of what problem it’s trying to solve.
An Example
Since the most important part of this technique is the conversations that occur rather than the end product, I’d like to relay a story about a time when I used this technique with a team that was in the midst of an effort to revise their commission system. There were 11 people involved, including the sponsor, a couple of subject matter experts, and the majority of the delivery team. I had them do the problem statement exercise partly to build that shared understanding, but also to see where they were in relation to their understanding of the problem.
The problem of
[Describe the problem]
Affects
[Who are the stakeholders affected by the problem?]
The impact of which is
[What is the impact of the problem?]
A successful solution would be
[List the critical benefits or key capabilities that the solution–however implemented–must have to be successful]
When I had the group build their individual problem statements—for the same project, mind you—we ended up with 11 different perceptions of what the project was about, ranging from making some changes to the commission system to make it easier to maintain, to completely overhauling how the organization paid its agents. Needless to say, the team was a bit surprised about the differences in perspectives, especially considering that the project had been under way for a few months by that point. Everyone just assumed that they were “all on the same page” regarding what the project was all about until they did this exercise.
By working through each of the different portions of the problem statement, we were able to converge to a shared understanding of the purpose of the project. Later, the team members were able to use this as one way of deciding what they should and shouldn’t focus on.
When to Use It
During kickoff activities, a problem statement activity is a good way to help a team build a shared understanding about the problem you are trying to solve with the new product or change to the product. You may use this technique to structure discussions around the first question from the project opportunity assessment.
If work on a product is already under way, you still may find it helpful to take a little time to create or revisit a problem statement, especially if you sense that the team does not have a shared understanding about why you are creating or changing that product.
Why Use It
This technique provides a structure for conducting productive conversations. It describes things in term of a problem, but it provides some context around who is most concerned about the problem and why. It also focuses on characteristics of the solution without implying a solution by itself. That makes this a good technique to use when your team is dealing with a potential build/buy situation and needs a way to organize their thoughts on what they are looking for.
How to Use It
- Get the sponsor, stakeholders, and delivery team together, and ask them to grab four sticky notes (or index cards) and a marker.
- On each of the cards, each person should write his or her version of the four parts of the problem statement. For example, my cards for the conference submission system might look like those listed below.
- Once everyone has written their cards, ask participants to read their statements in order and place their cards on four parts of the wall (if you have self-sticking cards or sticky notes) or four parts of a table, each part corresponding to a part of the problem statement.
- After everyone has read their statements, have the group work through each part of the problem statement and come up with a statement that they can all support.
Here’s an example for the Agile Alliance submission system:
Card1: The problem of selecting conference sessions
Card 2: Affects presenters
Card 3: The impact of which is they frequently do not receive actionable feedback on their session proposals or know why they were/were not selected.
Card 4: A successful solution would be open and transparent.
Caveats and Considerations
This technique could easily become a check-the-box exercise, where people complete it for the sake of completing it, but I’ve found a way to make the problem statement an interactive exercise, which is good for sparking a great deal of conversation.
Chances are you will have as many different views of the problem as you do people involved in the exercise. By having them write their ideas on cards, you enable a large group to sort, combine, and move the various ideas to aid the discussion and converge on a problem statement.
You probably won’t end up changing the real problem the effort is focused on (though you might), but you will certainly create a much better understanding of the problem you are trying to solve, assuming everyone in the group is involved in the discussion.
The best outcome of this exercise is not the problem statement specifically, but the conversations that occur as the group tries to converge on a single understanding of the product.
Assumptions that people have in their heads but had never voiced come to the surface. The shared understanding consists of not only the resulting problem statement but also the information shared during the discussions.
Additional Resources
Epic Problem Statement
Here is Scott Sehlhorst’s take on the problem statement along with a description of how he views backlog hierarchy (Epic -> Feature -> User Story) He also views problem statements as a creation and communication technique.
Jobs of the Problem Statement
Scott Sehlhorst expanded on his initial discussion of problem statement with a series of articles covering the three critical flaws in most product development processes a problem statement exists to address.
- To deepen shallow product thinking to identify meaningful outcomes. (Writing Problem Statements Improves Product Thinking)
- To empower product leaders to shape their product strategy through choosing what to do and choosing what not to do. (Problem Statements Shape Better Products)
- 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. (Problem Statements Provide Purpose)
- Once you start reshaping into a description of a problem, a good problem statement template nudges you towards more in-depth discussion of who is affected.
- A good problem statement also drives a discussion about the context in which people experience the problem.
- A good problem statement is from the perspective of your customers.
- Quantifying the impact of your problems puts them in perspective.
- When you quantify the impact, express it in a range so that you recognize the uncertain nature of estimates.
- Use the problem statement – and the power of quantification – to identify when there is value in learning before making a decision.
A Better Problem Statement Template
Scott followed up his series of posts on problem statement with an article describing his favorite formulation for Problem Statements. Turns out it’s roughly the structure described above.
The Software Requirements Memory Jogger: A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements by Ellen Gottesdiener
Beyond Requirements: Analysis with an Agile Mindset
Analysis Techniques for Product Owners Live Lessons
It’s a Catastrophe – how does an agile coach respond?
Want to know more?
If you learn better with video rather than reading, you may want to check out Analysis Techniques for Product Owners Live Lessons, a set of video training sessions that show you how to apply analysis techniques to product ownership. Lesson 4.3 focuses on the problem statement.
Analysis Techniques for Product Owners is available on Safari – O’Reilly’s online learning platform. Sign up for a 10-day free trial to view the video lessons.