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.
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]
[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.
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.
Three Steps for More Effective Projects on ProjectConnections.com
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.