DANIEL KYNE

6 JUL 2023

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 startups all the way up to the biggest companies in the world. Great products solve important problems.

Despite how important problem statements are, teams don’t tend to be very good at finding and articulating their customers’ problems. I often talk to teams with decades of experience that still struggle to think of good quality problem statements.

I’ve spent the past few years very focused on this topic. I built a research tool called 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 my experience, I decided to write two blog posts about problem statements:

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 realize that customers only search for solutions 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 that this ‘problem severity’ ingredient is the biggest single contributor to failure amongst startups. Fundamentally, customers just don’t go out of their way to find solutions for their mild inconveniences, so solutions to mild inconveniences are destined to fail.

If our success depends on our ability to distinguish between high-priority problems and mild inconveniences, then we better get pretty good at identifying and articulating customer problems!

Click here to read ‘Destined to Fail’

1. Reframing Outcomes

2. The Value of Abstraction

3. Specific Scenarios

4. Continuous Discovery

5. Peripheral Problems

6. The Smart Sailboat

7. Brainstorm Alone, Shortlist Together

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 tends to be much harder. Bernie’s reframing method helps us take a known problem, map it to what the customer wants to achieve, and then use that to brainstorm alternative problems your customers might experience while trying to achieve their outcome. Here’s an example:

I love this 4-minute 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 are dependent on a specific channel, process or perspective? Is it possible to imagine a solution independent of those factors? If so, try to write an additional problem statement that’s a layer removed from this baggage.

Click here to watch the video

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?” While this might seem counterintuitive, focusing on details about people’s personal experiences actually surfaces insights that are more likely to represent others’ experiences too. As the quote from Carl R. Rogers goes, “What is most personal is most universal.”

The same principle applies to problem brainstorming. Instead of fumbling around with a vague hypothetical, use some customer personas or relevant scenarios to anchor your brainstorming and find more detailed problem statements.

For many teams, this brainstorming process will be a single calendar event that brings everyone together to think creatively and collaborate. The best teams, however, use Continuous Discovery Habits to collect quotes, feedback and problems from their customers on an ongoing basis. Teresa Torres has a bunch of tips in her book and on her blog to help you unlock these interactions with customers if you don’t have this kind of access to them already.

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 solving 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:

Mapping peripheral problems is key to building a deeper understanding of your customer’s context. If you can’t articulate peripheral problems, then you’re working on a solution without knowing if customers will ever care about it.

The Smart Sailboat turns the SWOT matrix into a sticky-note brainstorming exercise. By starting with team objectives (harbor) and successes to date (wind), your brainstorming has clear objectives and context to draw inspiration from. Then, rather than lumping all problems in together, the Smart Sailboat forces you to differentiate your problem statements between internal weaknesses (anchors) and external threats (icebergs).

In July 2022, Ethan Mollick published his summary of 50+ years worth 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 solution? Brainstorm alone; shortlist together. Many of the brainstorming techniques in this post — like Reframing, Abstraction, Scenarios, and Peripherals — are most useful when you’ve already got some problem statements to work with. The best brainstorming sessions iterate between solo and group ideation, using the techniques I’ve described to explore the detail in and gaps between the problems that individuals share with the group.

RIP tweet embeds in Substack, here’s the original tweet

The first step to becoming a problem-focused team isn’t to throw all your existing processes out the window. The easiest first step is to create a home for problem statements where team members can continuously contribute and catalog the problems they encounter in their customer interactions.

Once you’ve finished brainstorming problems, you’ll need to edit and improve your statements. I created a guide explaining the 7 principles for writing high-quality problem statements in UX research — it’s the perfect companion piece to this guide.

Now that you’ve got a working list of problem statements, it’s time to figure out which ones your customers care most about solving. My guide to Customer Problem Stack Ranking — a research process that came out of Stripe’s product management team — went viral on Reddit and has been shared by top startup publications for its simple yet super-effective approach to spotting problems worth solving.