Part 2: What a Problem Statement Looks Like
In Part 1, we discussed the value of a problem statement. Now we will dive into the essential components that make a good one. So what does go into a good problem statement?
A problem statement is…
Up first is 1. Laser Focused and 2. To the Point. These first two go together because they feed each other. A problem statement should focus in on a problem. It should also not be long winded. In an arbitrary world, an ideal problem statement is 3–4 sentences max.
In this illustration there are two drawings. Their titles might be “A slice of pizza” and, “A slice of pizza sitting on a manhole cover.”
I find the first one conceptually appealing. The second I will leave the second to the Teenage Mutant Ninja Turtles.
How important it is that a problem statement 3. Provides Context! Context gives those working on the problem a better understanding of why. And it doesn’t need a long winded symposium to do so either. The example above provided a world of context with only five words.
As discussed in Part 1, problem statements orient a team on outcomes over output. Essential to this is to craft one that 4. Has a Clear Outcome. Outcomes are illustrated with some means of measurement, though not limited to Quantitative data. What KPI or analytics or emotions are you hoping this problem statement improves?
One of the incredible things that happens with a problem statement is that it will 5. Give a Sense of Ownership to the team working on it. Why wouldn’t it? They now have context to understand why a problem is important and the opportunity to dive in deep. Instead of getting a solution to implement, they have the task of solving a problem and the freedom to decide the solution. They are accountable to measure their success and iterate to reach the desired outcome.
These components come together to give the team ownership over the problem. And with ownership comes empowerment, excitement and motivation.
Finally, a problem statement must be 6. Aware of Business Constraints. We live in a real world and as such sometimes there are things that are outside of our control. There isn’t a need to put these in the problem statement but it may make sense as part of the context.
You may also be wondering, “What about time frames? If I don’t give my team a solution to implement how will I know when they will be done?”
How much runway a team has to work on a problem is part of the business constraints. It is important to communicate this with a team. It is also important that the team creates time estimates to as they get into the problem. And if time frames don’t line up, have those hard conversations.
A problem statement does not…
These four require less explanation so let’s fly through them.
Don’t provide a solution or even suggest one in a problem statement. The point is to inspire and give ownership over the problem. Providing a solution also pivots focus back to just output verses reaching an outcome. Stakeholders assist not by recommending solutions but by providing deeper understanding of the problem.
Assigning blame isn’t helpful and it also can imply a solution. If there are hard conversations that the team needs to have, do so in a retro. It isn’t needed here.
The final two point also go together. If the problem takes a year to solve, there is significant risk that the team will succeed. Keep problems to reasonable size and don’t try to address more than one issue. Yes, I know there are fuzzy grey areas for that last point. Just know that attempting to solve multiple problems will only decrease the chance of success for either.
Example Time!
This example is taken from Lean UX, by Jeff Gothelf:
[Our service/product] was designed to achieve [goals]. We have observed that the service/product isn’t meeting [these goals], which is causing [this adverse effect] to our business. How might we improve [service/product] so that our customers are more successful based on [these measurable criteria]?
Next is a real world example I used with Code for Orlando:
Code for Orlando’s success depends on a model of reoccurring, active participation from members of the community. The National Day of Civic Hacking Hackathon presents an opportunity to connect with members of that community who aren’t currently involved with CfO.
How might we design our event so that attendees are inspired to join CfO and increase our number of monthly contributing members?
So what do we have here? This is how I break down my understanding of the structure of a problem statement:
The first part provides that context of past and present. It is so important to understand why the problem is important and needs a solution.
The second part begins with “How might we.” (Learn more about this method.) It is also important to point to a measurable criteria by which to gauge success.
We are not setting a goal here, just acknowledging something that can measurable improve. This reinforces that we are going after an outcome, not just some output. Allow the team set a goal for this once they have begun to dive into the problem. This way they will buy into the goal they have set and feel motivated to reach it.
So what does this give us?
This is the “Build → Measure → Learn” loop, and that is exactly what problem statements allows us to do. In the illustration I highlighted some parts of the process. Ending with a speed round, here is the explanation:
1. A problem statement allows you to define assumptions with clarity and confidence. Know that the assumptions are at least in the right direction. 2. The word “Experiment” instead of build is to reinforce the permission to fail. No one gets it right on the first go. 3. Measure and Learn are pretty obvious. 4. Adapt shows that we iterate over the process while taking in what we learned. 5. Finally, we succeed by doing so.
Thank you for reading Part 2 of “What’s Your Problem?”
- Next, Part 3 will give you practical advice on How to introduce Problem Statements into your work life and process.
- If you haven’t yet read Part 1, click over there to learn more about The value of a Problem Statement.
I will update this article once Part 3 is published, but you can also keep up to date by following me here on Medium and on twitter @MattPLavoie.
Thank you to:
You — the reader, PowerDMS where I have the opportunity to experiment and learn, Code for Orlando, BarCamp Orlando, OTA and Orlando Tech Week, and Jeff Gothelf (Get his book Lean UX).
