29 June, 2025
In the rush to deliver solutions, we often skip the crucial step of precisely defining the problems we're trying to solve. That's where a good problem statement comes in. Concise, yet conveying enough information to properly explain what you're trying to improve, and for whom. Here's a quick guide to writing clear problem statements.
Just as a doctor's diagnosis guides the right treatment for a patient, a well-crafted problem statement ensures everyone understands the true nature of a problem before jumping to solutions. It acts as a foundation for effective decision-making and team alignment.
A well-crafted problem statement:
This simple yet powerful format breaks the definition of a problem down into four key components:
Before we jump into some examples it's important to understand why this structure works for product managers. Keeping the focus on user needs rather than jumping to solutions helps teams to identify the right problems to solve. It creates a natural flow from understanding the user's context and documenting what they're trying to do, to the broader goal of what they're trying to achieve and what's getting in their way.
Understanding these things and documenting them clearly makes it easier to validate potential solutions against the original well-defined problem statement.
Even with a clear format, there are some common traps that are easy to fall into when writing good problem statements. These mistakes often stem from jumping to solutions too quickly or being too vague about what the actual problem is.
Let's look at some typical pitfalls, and how to avoid them:
❌ Weak: "We need to add a search feature"
When we jump straight to proposing a solution without first understanding and articulating the underlying user need, we risk building the wrong thing or making the wrong change. It's like proposing new features before truly understanding what the user's pain points are.
✅ Better: "When users are looking for specific content in the app, they want to quickly find relevant items, so they can continue their workflow without interruption, but they can't because they have to manually scroll through long lists of content."
💡 Takeaway: By jumping straight to 'search feature' we hijack the conversation, overlooking the user's actual problem (workflow interruption and loss of context) in favor of what feels like the obvious solution. This might seem like we're going in the right direction, but we risk misunderstanding our users' needs and wasting precious time and energy building the wrong things.
❌ Weak: "The onboarding flow is confusing"
When we use subjective or general terms (e.g. 'confusing') without providing specific context or measurable impact, we risk falling into this trap. It's impossible to prioritize and solve a problem when we don't know exactly what's wrong or when it occurs, and at the very least it's hard to know if we've improved things if we lack quantitative data about the problem, or only described it in very woolly terms.
✅ Better: "When new users first open the app, they want to understand its core features, so they can start using them all broadly and effectively, but they can't because the current onboarding process doesn't explain key functionality and assumes too much prior knowledge."
💡 Takeaway: Be precise in your description of the problem, and don't be afraid to add data or measurable takeaways to your problem definitions. In the example above, you might include some analysis of the number of core features used by a user in their first seven days, so you can compare performance before and after.
❌ Weak: "The app is slow"
This mistake occurs when we fail to include all the essential elements of a problem statement: the user context, the desired outcome, and the specific obstacle. Without these components, we can't fully understand the problem's scope, the impact on the user experience, or whether we've actually improved things after making changes.
✅ Better: "When users are trying to complete time-sensitive tasks, they want the app to respond quickly to their actions, so they can maintain their workflow momentum, but they can't because our current architecture doesn't optimize for real-time data updates."
💡 Takeaway: Practice including all four parts of a well-rounded problem definition in a template when defining problems (or use a free Voyce account to help). Remember: When / They want / So they can / But they can't because.
Let's double-down on the earlier examples to show a few more examples of getting from weak problem definitions to some that are much stronger.
The weak statement focuses on the solution without explaining the need, while the better version clearly explains the user's context, specific need, and current limitation preventing them from achieving their goal.
Contrasting the two statements, you can immediately see in the second statement who the change will benefit ('product managers'), what they're trying to achieve ('understand how features are being used'), why ('so they can make decisions about feature development'), and the impediment ('...don't track feature-level usage patterns.'). For this specific problem, 'more analytics' may or may not be the right feature to spend time on.
The weak version is subjective and lacks specific details, while the better version provides clear context about the user's goal, impact of the current process, and exact technical limitations causing the problem. It also hints at some metrics you could include in the problem definition to help with prioritization (which tasks, how many taps, etc.).
The weak statement suggests a solution without explaining the underlying need, while the better version clearly articulates the specific user context, desired outcome, and the current limitations that prevent effective collaboration. Again, see how much richer your problem definitions become just by completing those four parts: When / They want / So they can / But they can't because.
Here's a quick summary of tips to keep in mind when processing feedback and writing well-formed problem statements:
Writing good problem statements isn't just about documentation - it's about ensuring clarity, alignment, and better product decisions. The "When / They want / So they can / But they can't because" format provides a simple yet effective way to capture and communicate user problems to product teams.
If you're interested in trying this style of defining problem statements, set up an account on Voyce and give it a try (it's free). This is the style we use when writing up customer feedback and user problems ourselves, and you might be surprised at how quickly it changes the conversation from 'What features should we build?' to 'What user problems are we really trying to solve?'
Stay in touch for updates and ideas.
No spam. No advertising. No rubbish. Just us.
