How to Write Effective Problem Statements & Deliver Products That Matter
Several years ago I began incorporating User Problem Statements into my team’s product design process. It’s a critical step early in the process that focuses the team’s collective efforts to deliver a product that matters to their target audience.
Why Problem Statements?
I’m a big advocate for using language to frame an opportunity without bias. Developing problem statements at the beginning of a project helps teams establish their purpose & goals, and allows for exploration & innovation without boxing team members into a specific design solution from Day 1. Sadly, all too often as designers we’re presented with the solution by a client or business partner/product owner at the onset of a project. Being handed a solution from the start frames a product team’s thinking around the most effective way to deliver that predetermined solution rather than questioning whether the solution is the most effective way to meet a user’s needs.
Since by nature I’m a pain in the ass, my first instinct when provided with a design solution at the beginning of a project is to ask, “Why?” I’m not trying to be difficult; I truly want to understand the information and decisions that led to the current solution that’s being proposed/mandated. Usually these decisions are based on one or more of the following:
- Our biggest competitor just launched (or is about to launch) a similar product/feature
- This new technology is all the rage (mobile applications, chatbots, voice assistants, AR/VR, wearables, etc.), and we need to be part of the trend
- Executive leadership has made this a priority
These reasons don’t help a product team understand what’s valuable to their end users. On the contrary, they only make clear what’s important to senior executives within their organization. Starting a project under these conditions can at best lead to mediocre/me-too products, and at worst complete failures in the marketplace. These reasons certainly don’t start teams on the path toward innovation or delighting users.
A well-written and validated problem statement helps in the following ways:
- Having a clearly stated user problem defines a mission for the team, building empathy for the end user and uniting team members around the purpose of designing solutions that will improve users’ lives
- Most people get a sense of pride when helping others. Knowing that you’re working on a solution to someone’s problem makes the work you’re doing more rewarding and more enjoyable
- How do you measure success when the goal is feature parity with the competition? What metrics do you track when the goal is to build a new widget because it’s the flavor of the week? If you know what the user problem is, the only metric that truly matters is how well the problem gets solved
- Another critical benefit of starting with the problem is it opens the door to innovative thinking (and what organization isn’t dying for more innovation?). Truly understanding a problem and its root causes allow for a myriad of creative solutions that can be prototyped and tested with users
If you’re not convinced that starting with the problem is the most effective way to begin a project, you can stop reading now. If you want to understand the mechanics of creating & implementing an effective problem statement, read on…
Steps to Writing an Effective Problem Statement & What to do Once You’ve Written it
Before I dive into the nuts & bolts of writing problem statements, I’d like to clarify the semantics of the word, “problem” as some are turned off by the negative connotation of the word. A problem in this sense isn’t necessarily harmful to the person; e.g. “I HAVE A PROBLEM — THERE ARE FIRE ANTS CRAWLING UP MY TROUSERS!!!” The problems that we tend to focus on from a design standpoint are more akin to scientific or mathematical problems:
PHYSICS•MATHEMATICS
an inquiry starting from given conditions to investigate or demonstrate a fact, result, or law.
GEOMETRY
a proposition in which something has to be constructed.
The problems we’re identifying have a strong relationship to “Jobs” in the Jobs-To-Be-Done Framework. They may be tasks a person needs to complete or impediments to goals they want to achieve. Often a user problem can focus on ways to make a process more convenient, simpler, or more effective. Problems can be large: Help me save for retirement. Problems can be small: I can’t find the Submit button. Either way, user problem statements will articulate a user need without telegraphing a solution.
1. Research
The first step in the process is understanding what your users’ problems actually are which will require a bit of research. The research can take many forms depending on your audience, the state of your product (a brand new offering is different from a mature product), and business priorities.
An analysis of the various research methods that could be used to identify user problems is another article unto itself, but at a high level your goal is to ask questions, listen, and observe actual user behavior. Again, techniques will vary depending on the product you’re designing, but options may include contextual inquiry, ethnography, quantitative surveys, usability studies, or analyzing usage metrics. Talk to your customers (or prospective customers). Talk to people who talk to your customers (or prospective customers). Listen for pain points — ways to make a process smoother. You’ll uncover a myriad of possible problems to solve.
2. Prioritize
After conducting research into potential user problems you will more than likely end up with several potential problems upon which to focus your team’s efforts. It’s time to rank problems by importance; importance is determined by two things: 1. Value to the user, and 2. Value to the business. Some problems will be less important to the majority of users. Some may be too costly for the business to solve or beyond the scope of its business model. It’s critical at this point to focus on the sweet spot — identifying a problem that meets a critical customer need while simultaneously aligning with an organization’s mission and ultimately how it makes money. When you find that, you’ve struck gold!
3. Document
Now that you’ve identified and agreed on the most important problem, it’s time to write it up. When I began writing problem statements, I did some research and had a hard time finding a standard syntax. I experimented with some different formats in order to document them consistently. Ultimately, I settled on and used two problem statement syntaxes consistently; I’ll explain the use & nuances of both:
Syntax A:
The format I began using consistently is similar to what’s taught in the Stanford’s D School Design Thinking program. I’ve simplified it a bit by modifying the first line to “I am a…” which allows for a description of the user as well as an opportunity to provide some context about the situation. For example: “I am a busy mother of three young children on my way home from work.” The first line immediately conjures an image of a real person, and starts the empathy process. (Avoid simply writing something like, “I am a customer,” or “I am a user.”) Using “I” versus “you” in the problem statement also helps team members feel ownership and connection to the problem.
“Trying to…” is the desired outcome. “But…” is the barrier/problem, and “Because” is the root cause of the problem. Understanding the outcome, immediate barrier, and broader root cause of the barrier helps teams think of more creative ways to solve the problem (See: Innovation).
Finally, “Which makes me feel…” is an explicit description of the user’s emotional state related to the problem. The last line is intended to build empathy and a deeper connection with the team who’s job it is to design solutions to the stated problem.
Syntax A worked very well (and continues to work) over the course of several projects/years. Over time, I noticed that the statements — in an effort to be complete — began to get wordy; i.e. the font on the PowerPoint slide got smaller in order to fit the entire thing. While it’s important to write a clear problem statement, there is a danger that it loses its effectiveness the longer it gets.
Syntax B:
About the same time I noticed that Syntax A was leading to bloated statements, I stumbled across Alan Klement’s awesome article on Job Stories as a replacement for User Stories. I realized that by adding a single word to the end of his Job Story format, “But,” I could introduce a user problem. This led to Syntax B as another way to document user problem statements.
In addition to more concise problem statements, the “When…” statement in Syntax B defines a trigger that leads the user to take action. Understanding these triggers is very helpful for setting context.
Syntax A does a better job identifying a persona and building empathy, while Syntax B is agnostic re. the persona and focuses more on the relationship to trigger/task (job)/outcome. One important thing to note about both formats: the solution is not contained within the problem statement! Problem statements articulate problems. If you’re hinting at a solution in the problem statement, you’re doing it wrong.
A combination of both: Syntax A for an overarching problem statement that covers an entire organization or product line, and Syntax B for more specific features may make sense for some teams. Feel free to experiment and see what works best for your situation (and let me know what works & doesn’t work).
4. Validate
After you and your team have written a solid problem statement (this is a great effort for a small group!) it’s time to go back to your users and show it to them. This step is similar to the original research effort (Step 1), but it’s focused solely on determining whether the problem statement reflects the actual attitudes & problems of your target audience.
Asking simple questions like, “Do you agree with this statement?” and “Do you see yourself in this statement?” is a great place to start. This step is critical to ensure that the problem you & your team have prioritized and focused on actually reflects a real user need.
5. Agree*
You did the research. You prioritized the problems. You wrote a killer problem statement and showed it to your target audience again to validate it — which they did. Now it’s time to share it more broadly within your organization. Share it with other teams. Share it with management and senior execs. When you share it, explain how you arrived at the problem, and, most importantly, ask for feedback. Your goal is to socialize the problem internally, and get agreement from anyone who may have an opinion (today or in the future) on the work your team be doing related to the problem.
At the start of any workshop or presentation, reference the problem statement. Make sure that everyone still agrees that it’s a problem worth solving. And use the problem as a benchmark for the work that’s being done. In other words, is what you’re making solving the problem?
*This step applies mostly to people who work within larger, matrixed organizations.
6. Rally
Now that you have a problem to solve, plus buy-in from your users, team, and internal stakeholders, it’s time to use that problem statement as a rallying cry. Make a cool problem statement poster, and hang it in an area where the entire team will see it. Write the problem statement on a whiteboard. Make it known to everyone that solving this problem (not that problem) is your team’s number 1 priority.
Great — We Have a Problem Statement! Now What?
It’s time to start designing & testing solutions of course! But that’s a post for another day. In the mean time, let the problem be your guide.
If you enjoyed this, you’ll definitely enjoy my article on an alternative to the product roadmap.
