Problem Statements - An essential guide

It didn’t really click for me how important customer problems are to startup success until I came across Shreyas Doshi’s story ‘Destined to Fail’.

‘Destined to Fail’ was the most significant mindset shift I’ve ever had as a founder. I realized that customers only search for solutions to their highest-priority problems. So many teams fail by only validating that customers experience the problem they’re solving — not whether that problem is a high priority or just a mild inconvenience.

The impact of this mistake is crystal clear — Shreyas says ‘problem severity’ is the biggest contributor to startup failure. Customers don’t go out of their way to find solutions for their mild inconveniences, so solutions to mild inconveniences are destined to fail.

If success hangs on our ability to distinguish high-priority problems from mild inconveniences, we better get pretty good at articulating customer problems. And that’s exactly what this newsletter post is gonna help you accomplish (and why you should bookmark it now).

People instinctively start by writing ideas instead of problem statements. There are plenty of reasons why this is the wrong approach:

The first step is to tie your list of feature ideas to the problem they intend to solve:

~

Writing solutions as problems isn’t the only translation task to complete. It’s common to find teams who think they’re writing problem statements but are actually articulating internal objectives instead. A simple test is to ask whether it’s plausible a customer might say this statement to you in conversation. For example:

~

Imagine you ask your customers to stack rank a bunch of problem statements and this one ranks highest — “When I first created my account, I couldn’t find interesting people to follow or figure out how to complete my profile.”

Multiple variables in a single problem statement eliminate any possible insights about why people ranked it highest. Is it because they struggle with making connections or enriching their profiles? We can't know!

When you’re drafting problem statements, always finish by reviewing your list with a fresh pair of eyes. Might some groups of people interpret this problem differently from others? Have I rolled multiple problems into one statement? If so, your problem statement can’t be relied upon when it comes time to share your results.

~

The more you beat around the bush, the more room there is to misinterpret the problem.

~

We eliminate jargon for the same reason we separate variables and pursue brevity — any opportunity for your problem statement to be misunderstood should be minimized.

~

How someone is affected by a problem depends on who they are and the objective they are pursuing. When we try to appeal to a wide range of customer segments for every problem statement, we end up writing statements that fail to resonate with anyone. Counterintuitively, what's most personal tends to be more universal.

Turn these multi-segment statements into separate problems from the perspective of each customer segment they impact. I like this iterative example from the IBM Design team:

V1 describes a desired outcome (not a customer problem) and could apply to pretty much any customer segment. V2 makes the statement specific to just one type of customer — new drivers. Then V3 translates it from a desired outcome to a customer problem. I would personally add a more direct V4 written from the customer’s perspective:

~

Write each problem statement as if you’re hearing a customer explain it to you in a normal conversation:

Past tense removes urgency by phrasing the problem as if it’s not a current issue needing to be solved. Future tense statements sound like hypotheticals that may or may not even happen. When we write in the present tense, it forces us to be more specific and creates an awareness that someone is being impacted by this problem right now.

~

The most important thing when using a problem-led approach in product management is maintaining consistency across all problem statements. Statements can be tested, compared and prioritized in the most effective way possible when they share the same writing style (tense, perspective, segment, etc.).

Those principles will help you write better quality problem statements, but they’re not so useful if you’re struggling to think of any customer problems in the first place. Here are 7 tips for kickstarting your problem brainstorming session:

~

This story from Teresa Torres changed how I think about problem-solving.

Teresa was attending a talk by Bernie Roth — founder of Stanford’s d.school. Bernie asked attendees to write down something that they wanted in life, giving examples like a new house, a better job, more leisure time, etc.

Then Bernie asked a second question — “If you had whatever you wrote down today, what would that do for you?”. Why would you be better off than before? Bernie gave the example that if you said you wanted a new house, maybe your next answer would be “If I owned a house, I would feel more grounded in my community.”

The real value came in Bernie’s third question — “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? This type of reframing disrupts our fixation on a single solution like owning a house and widens our lens to consider other ways we could accomplish the same goal.

Teresa says every customer opportunity (ie. a need, pain or desire) requires a ‘Desired Outcome’ parent. You shouldn’t solve a customer problem unless it aligns with one of your team’s goals.

You can use this approach in reverse to boost your brainstorming. Map each problem to the customer’s ‘desired outcome’, then use that desired outcome to think of alternative ways the customers might try to accomplish those outcomes.

Those alternative customer journeys will spark a new list of potential solutions, obstacles and problems that customers will encounter.

~

The Smart Sailboat is a SWOT-style post-it 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

The Smart Sailboat quadrant by New Haircut

My favorite part is that, rather than lumping all problems together, it forces you to differentiate between internal weaknesses (anchors) and external threats (icebergs) while drafting your statements.

~

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.

Looking at your list of problems, which statements are dependent on a specific solution medium, process or perspective? Is it possible to imagine a solution that is independent of these factors? If so, try to write an additional problem statement that is a layer removed from that baggage.

~

I love the ban on hypotheticals in the book The Mom Test. Asking questions like “How do you usually approach doing X?” or “What does your typical day look like?” allow people to imagine the best version of themselves — immune from distraction, unbothered by office politics, empowered to make decisions independently... But real life isn’t vague or hypothetical like this.

Asking about specific scenarios like “When was the last time you did X? Can you walk me through what that process looked like?” will you get rich insights about the actual challenges someone faced, who got in their way, and what they had to do to overcome obstacles.

The same applies when writing problem statements. Your user base is likely a diverse group of people. Trying to write statements that address everyone’s problems at once will produce vague problems that don’t actually represent anyone’s experience.

At OpinionX, our customers range from tech founders to government policy teams to high school teachers. If we tried to write problem statements that applied to all of them, we’d end up with a generic pile of crap.

I don’t use fake personas though. I actually think about a specific customer that I know well and have talked to a bunch of times. Focusing on one person lets me soak up all the nuance in their use case, which in turn unlocks a deluge of specific details in brainstorming.

~

For many teams, this brainstorming process will be a calendar event that brings everyone together to think creatively and collaborate.

The best teams use Continuous Discovery Habits to collect quotes, feedback and problems from their customers every week. They test their big hairy assumptions in user interviews and de-risk projects early through iterative experimentation.

~

Validating that people experience the problem you’re solving is meaningless if that problem is only a mild inconvenience they’re hardly even aware of. You need to identify and articulate the wider range of problems that customers are juggling on a day-to-day basis to figure out if you’re chasing a problem that’s high on their priorities list.

These ‘other’ priorities are Peripheral Problems — if you can’t articulate them, you’ll be stuck on the sidelines tinkering away on a solution without knowing if customers will ever care about it. Mapping peripheral problems is key to building a deeper understanding of your customer’s overall context.

~

Ethan Mollick’s summarized 50+ years of academic research on brainstorming in a viral thread in July 2022. 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.

Ethan Mollick @emollickPeople keep starting with group brainstorming because it is fun! And it feels like you are being really creative when everyone is throwing out ideas. 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. July 28th 202282 Retweets582 Likes

The first thing I do before building any new feature is to write a specifications document. The first section in every spec doc is the customer problem statement. Having a clear problem statement means team members can independently answer most questions that will appear during any product development process without intervention or approval bottlenecks.

Rather than creating a product roadmap full of feature ideas, the Opportunity Backloglists the customer needs, pains and desires you intend to address. By prioritizing these opportunities instead of feature ideas, empowered product teams can find the best solutions themselves instead of being prescribed specific solutions by their leadership team.

Every quarter, we create a list of problem statements and ask our most active users to rank them so that we understand the problems impacting their success most. Customer Problem Stack Ranking gives us real data to align behind a common goal rather than debating around vague opinions — I can’t imagine running a startup without it.

We’ve also used problem statement ranking to validate whether an idea solves an important enough customer problem to bother pursuing. For example, in early 2021 we were about to start a 3-6 month project to integrate an external tool for recruiting survey participants. At the last minute, a quick stack ranking survey showed us that customers had plenty of higher impact problems that we could solve in a fraction of the time this one project would have taken.

The best teams are empowered, problem-led and customer-focused.

But the first step to becoming one of these teams isn’t to throw all your existing processes out the window.

Start by creating a home for problem statements — a place where team members can contribute and catalog the problems that they’re encountering in their customer interactions.

I hope the principles and brainstorming tips in this post help you get a step closer to becoming a problem-solving machine.

— Daniel