7 Problem Statement Brainstorming Methods [with Examples]
Great products solve important problems, but most teams are surprisingly bad at finding and articulating their customers' problems in the first place. This guide is a problem statement brainstorming playbook, the first half of a two-part series (the other covers how to write them up).
“Seven techniques help you generate a fuller list of customer problems: reframe outcomes to find adjacent problems, abstract a problem away from its specific channel, anchor on real scenarios instead of hypotheticals, run continuous discovery instead of one workshop, map the peripheral problems your customer is also juggling, use the Smart Sailboat to split internal weaknesses from external threats, and brainstorm alone before shortlisting together.”
If you look at any of the frameworks for building a great product, from Lean Startup and Jobs-To-Be-Done to Design Thinking and Discovery Research, you'll find customer problems at their core. This is true for small teams all the way up to the biggest companies in the world. Great products solve important problems.
Despite how important problem statements are, teams tend not to be very good at finding and articulating their customers' problems. I often talk to teams with decades of experience who still struggle to think of good ones.
I've spent the past few years focused on this topic. I built OpinionX to help product teams rank customer problems, so I've seen thousands of problem statements and helped process over a million ranking votes on them. Based on that experience, I wrote two blog posts about problem statements:
7 Problem Statement Brainstorming Methods (this post)
First, why are problem statements important at all?
I never really understood why people talk about customer problems so much until I read Shreyas Doshi's story "Destined to Fail", which made me realise that customers only search for a fix to their highest-priority problems. The reason so many teams fail is that they only validate that their target customers experience a problem, not whether that problem is a high priority or just a mild inconvenience.
Shreyas says this "problem severity" ingredient is the biggest single contributor to failure among startups. Customers don't go out of their way to fix mild inconveniences, so products aimed at mild inconveniences are destined to fail.
If our success depends on our ability to distinguish between high-priority problems and mild inconveniences, then we'd better get pretty good at identifying customer problems and figuring out which ones are the high priorities.
7 techniques for brainstorming problem statements
| Method | What it does |
|---|---|
| 1. Reframing outcomes | Map a problem to the outcome the customer wants, then find other problems on the way to it |
| 2. The value of abstraction | Strip a problem of its specific channel or process to reveal a broader one |
| 3. Specific scenarios | Anchor on a real past situation, not a hypothetical, to bring out detailed problems |
| 4. Continuous discovery | Collect problems from customers every week, not in one calendar event |
| 5. Peripheral problems | Map the other problems a customer is juggling, so you know where yours ranks |
| 6. The Smart Sailboat | A SWOT-style exercise that splits problems into internal weaknesses and external threats |
| 7. Solo storming | Brainstorm alone first, then shortlist as a group, for more and better ideas |
1. Reframing outcomes
In 2016, product discovery coach Teresa Torres attended a workshop hosted by Bernie Roth, founder of Stanford's Institute for Design Thinking. Bernie opened his session by asking attendees to "write down something they wanted in life, like a new house, a better job, or more leisure time."
Next, Bernie asked, "If you had whatever you wrote down today, what would that do for you? Why would you be better off than before? For example, owning a house would help me feel more grounded in my community."
Then Bernie landed his big-hitter: "How else could you feel more grounded in your community? Rather than buy a house, couldn't you join a social club or volunteer in a local impact program?"
With these three simple questions, (1) What do you want? (2) What outcome will that deliver for you? (3) How else could you obtain that outcome?, Bernie exemplified the power of reframing.
Even teams that seldom talk with their customers can brainstorm a couple of problem statements, but unlocking the full range of problems is much harder. Bernie's reframing method helps us take a known problem, map it to what the customer wants to achieve, then use that to brainstorm other problems they might hit on the way to that outcome.
2. The value of abstraction
I love this short explanation from Patrick Whitney (Co-Founder of Harvard's Design Lab) about how "abstracting design problems" led to the success of iTunes in the early 2000s. Look at your current list of problem statements: which ones depend on a specific channel, process or perspective? Could you imagine a fix independent of those factors? If so, try writing an extra problem statement a layer removed from that baggage.
3. Specific scenarios
Asking questions like "How do you usually approach doing X?" or "What does your typical day look like?" lets people imagine the best (unrealistic) version of themselves, immune from distraction, unbothered by office politics, fully empowered to make independent decisions.
In real life, things aren't so hypothetical. That's why Rob Fitzpatrick banned hypothetical questions in his book The Mom Test. Instead, ask people about recent situations from their real life, like "When was the last time you did X? Can you walk me through what that process looked like?" It might seem counterintuitive, but the details of one person's real experience tend to produce insights that represent other people's too. As Carl R. Rogers put it, "What is most personal is most universal."
The same principle applies to problem statement brainstorming. Instead of fumbling around with a vague hypothetical, use customer personas or relevant scenarios to anchor your brainstorming and find more detailed problem statements.
4. Continuous discovery
For many teams, this brainstorming process is a single calendar event that brings everyone together to think creatively. The best teams use Continuous Discovery Habits to collect quotes, feedback and problems from their customers every week. Teresa Torres has plenty of tips in her book and on her blog to help you unlock these interactions if you don't already have that kind of access to your customers.
5. Peripheral problems
One of the most common mistakes teams make when brainstorming problems is setting their scope too narrow. To identify your customers' high-priority problems, you need to know which other problems they're considering solving.
These other priorities are peripheral problems. For example, imagine you're building a product to make it easier to book group holidays, and the main problem you're focused on is "Dividing the cost of a hotel booking is frustrating and complicated when planning a group holiday." Peripheral problems would be the other pains a customer experiences when planning their holiday, such as:
It's difficult to plan activities when I haven't organised a transport method like car rental or public transport.
It's hard to find out how expensive a destination is for general things like food and transport.
Agreeing on dates that suit everyone is a pain.
Some destinations are very different depending on the time of year, but good information on seasonality is hard to come by.
Keeping a list of potential Airbnbs and hotels turns into a giant messy spreadsheet.
Mapping peripheral problems matters for building a deeper understanding of your customer's context. If you can't articulate them, you're working on a fix without knowing whether customers will ever care about it.
6. The Smart Sailboat
The Smart Sailboat turns the SWOT matrix into a sticky-note brainstorming exercise. Starting with team objectives (the harbour) and successes to date (the wind) gives your brainstorming clear context to draw from. Then, instead of lumping all problems together, the Smart Sailboat forces you to split your problem statements into internal weaknesses (anchors) and external threats (icebergs).
7. Solo storming
Ethan Mollick published a summary of 50+ years of academic research on brainstorming. His conclusion: "People start with group brainstorming because it's fun … but as soon as you're in a group, everyone starts to self-censor and be influenced by others. You end up with less and worse ideas."
The answer? Brainstorm alone; shortlist together. Many of the techniques in this post, like reframing, abstraction, scenarios and peripherals, are most useful once you've already got some problem statements to work with. The best problem statement brainstorming sessions iterate between solo and group ideation, using these techniques to explore the detail in, and the gaps between, the problems that individuals share with the group.
People keep starting with group brainstorming because it is fun! And it feels like you are being really creative when everyone is throwing out ideas.
— Ethan Mollick (@emollick) July 28, 2022
But as soon as you are in a group, everyone starts to self-censor & be influenced by others. You end up with less & worse ideas. pic.twitter.com/nFnsobG5Nv
After brainstorming: what comes next
1. Create a problem repository. Becoming a problem-focused team doesn't mean throwing out all your existing processes. The easiest start is to create a home for problem statements, a place where team members can continuously contribute and catalogue the problems they hit in their customer conversations.
2. Write great problem statements. Once you've finished brainstorming, you'll need to edit and improve your statements. I wrote a guide to the 7 principles that make for high-quality problem statements in UX research, which is the perfect next step.
3. Identify the high-priority problems. Now that you've got a working list, it's time to figure out which ones your customers care most about solving. My guide to Customer Problem Stack Ranking, a research method coined by Shreyas Doshi, covers a simple but effective approach to spotting the problems worth solving.
Frequently asked questions
How do you brainstorm problem statements? Problem statement brainstorming works best with structured techniques, not staring at a blank page: reframe the customer's desired outcome to find adjacent problems, abstract a problem away from its specific channel, anchor on real past scenarios, run continuous discovery, map peripheral problems, use the Smart Sailboat exercise, and brainstorm alone before shortlisting as a group.
Why do teams struggle to find customer problems? Usually because they set their scope too narrow and only validate the one problem they're already focused on, without mapping the other problems the customer is juggling. That makes it impossible to tell whether their problem is a high priority or just a mild inconvenience.
What do you do after brainstorming problems? Two steps: write the problems up cleanly using the principles of good problem statements, then prioritise them, usually by asking customers to rank them, so you know which ones are actually worth solving.
Is group brainstorming effective? On its own, not really. Research summarised by Ethan Mollick found that groups tend to self-censor and influence each other, producing fewer and worse ideas. Brainstorming alone first and shortlisting together works better.
If you enjoyed this post, consider subscribing to my newsletter The Full-Stack Researcher, where we share actionable research advice for product teams and researchers.
About The Author:
Daniel Kyne is the Founder & CEO of OpinionX, the platform for advanced market research surveys. OpinionX is used by thousands of teams at companies like Google, Amazon and Shopify. Create a free problem ranking survey on OpinionX to discover and measure your customers' biggest problems.