If you don’t understand your customer’s biggest problems, you’re destined to fail.
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).
7 Principles For Writing Great Problem Statements
Principle 1: Translate Solutions
People instinctively start by writing ideas instead of problem statements. There are plenty of reasons why this is the wrong approach:
- Ideas tend to get revised and reshaped multiple times before shipping. If you haven't captured the initial problem you’re trying to solve, odds are the final version ends up so far removed that it no longer addresses any customer problem at all.
- Giving your team a list of features to build kills their creative potential. You spent all that time hiring skilled developers and designers only to give them a ‘color-by-numbers’ development process.
- It's common to find different functional teams working in opposite directions on the same project if a clear problem statement is not agreed upon upfront. Internal confusion is an expensive mistake.
- While product roadmaps are commonly used to store features for later consideration, Jira tickets often become solid commitments over time rather than ideas to later reinterrogate.
The first step is to tie your list of feature ideas to the problem they intend to solve:
Solution Statement — I want my current inventory of dog food continuously monitored so that a new pack can be automatically ordered for delivery before my current supply runs out.
Problem Translation 1 — I sometimes forget that I have to manually order my next batch for delivery.
Problem Translation 2 — Ordering my next batch of dog food online can leave me with no supply for a few days while I wait for the delivery.
~
Principle 2: Customer Perspective
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:
Internal Perspective — We need to build an online property auction tool to help real estate agents unlock additional sales channels and opportunities.
Customer Perspective — As a property agent who uses sells primarily through online channels, I feel like I lose customers to competitors because I can only sell via traditional pen-and-paper style contracts.
~
Principle 3: Single Variable
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.
Multiple Variables — Screening interview applicants is time-consuming, prone to bias, and reliant on recruiters' understanding of the traits that determined candidate success in the past.
Single Variable — Our recruiters don't have prior experience hiring employees for our function.
~
Principle 4: Brevity
The more you beat around the bush, the more room there is to misinterpret the problem.
Wordy — The excess degree of packaging creates a feeling of unsustainability amongst customers like me because it looks as though the materials used could have been drastically reduced without impacting product or delivery quality standards.
Concise — I don’t like how much excess packaging is used for deliveries.
~
Principle 5: Eliminate Jargon
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.
Jargon — The .csv uploader does not fully replace the need for a native CDP integration as it currently requires significant manual formatting for my CRM to ingest accurately.Accessible — I have to spend a lot of time manually fixing issues in my data when I try to upload it using a spreadsheet export.
~
Principle 6: Segment Specific
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 — We need to build better tire inflation machines that last at least one year without maintenance.
V2 — We need to provide more tire inflation machines to new drivers.
V3 — New drivers struggle to keep their tires properly inflated because they don’t know that they need to maintain their cars this way.
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:
V4 — As a new driver, I don’t feel like I know how to manage tire pressure maintenance.
~
Principle 7: Present Tense
Write each problem statement as if you’re hearing a customer explain it to you in a normal conversation:
Past Tense — I struggled to capture the best quotes during my user interviews because they were speaking so fast that I was already trying to come up with the next question.
Future Tense — I will have to skip ahead and try to think of the next question because the interviewee will be speaking so fast that I won’t be able to keep up.
Present Tense — When a user speaks too fast, I’m left trying to recall and capture their original phrasing after the interview ends.
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.
~
Consistency is Key
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.).
7 Tips For Problem Statement Brainstorming Sessions
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:
~
I. Desired Outcomes
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.
~
II. The Smart Sailboat
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.
~
III. The Value of Abstraction
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.
~
IV. Specific Scenarios
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.
~
V. Continuous Discovery
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.
~
VI. Peripheral Problems
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.
~
VII. Brainstorm Alone, Shortlist Together
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
When and where I use problem statements:
A. Feature Spec Docs
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.
B. Opportunity Backlogs
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.
C. Roadmap Prioritization
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.
D. Idea Validation Experiments
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.
Taking the first step…
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