Problem Statements
Definitions
User
A person who is trying to solve a problem and is looking for a product or service to help them solve it.
User experience
The journey that the user takes with that product or service.
Problem statement
A concise description of the problem that needs to be solved, and it summarizes who the user is, what they need from a design, and why.
Pain points
Any UX issue or friction that frustrates the user and blocks them from getting what they need. Minimizing pain points keeps users happy and encourages them to keep interacting with the product.
Value proposition
Why your user would or should use the product or service that you’re designing.
Goals
- Problem we are solving must be clear
- Problem needs to be worth solving
- User's goals must be clear and therein lies the need to define what constitutes success for the user
Questions
Is there a problem statement? What is the problem statement?
You need to be clear what you are trying to do. Identify a right, meaningful problem.
What is the need and desired outcome?
Focus on the gap, not the solution, and what the user/customer wants achieved.
Why is the problem important?
Choosing the correct problem to solve increases the odds you succeed in your initiative.
Who is experiencing the problem?
You need to focus on who the customer really is whom you're trying to value add.
What are the pain points you’re trying to solve?
You want to target key issues users have with whatever you're trying to get them to do.
Where is the user when they’re using the product?
Context matters. Knowing the user's environment (physical location, device, surrounding distractions) informs design and functionality. A product used on a noisy factory floor will have different UI/UX needs than one used in a quiet office. Understanding the user's context improves usability and relevance.
When does the problem occur?
Understanding when the problem occurs (frequency, specific situations, time of day) helps prioritize solutions and identify trigger events for your product to intervene effectively.
How are users reaching their goals by using the product?
This focuses on user journeys and product effectiveness. Mapping user goals and how your product facilitates them reveals areas for improvement in usability and value proposition. It ensures your product is actually helping users achieve what they set out to do, and highlights potential friction points.
What is the hypothesis?
Product development should be driven by testable assumptions, not just gut feelings. Formulating a clear hypothesis ('If we build X, then Y will happen') allows you to validate your ideas through data and iteration.
Who gets value, at what velocity, at what volume?
Understanding value delivery is key to sustainability and growth. Knowing who benefits, how quickly they see value, and how much value they receive informs your business model, marketing strategy, and product roadmap. It helps you quantify impact and understand the scale of your potential success.
Why do we need X? What happens if we got rid of this by end of this year, or if we refused to build this? Who would come to us to complain and why would they do so?
This question challenges assumptions and forces you to justify features or projects. It encourages critical thinking about necessity and impact.
What are the blockers to doing X? Let's split them by policy, user research, resources.
First step to unblocking is to understand the nature of the blocker. Each type of blocker deserves its own treatment.
Alarm Bells
They say...
Why I'd be scared
You should be doing xxx, yyy, zzz because Company X is doing it as well.
Context is important, there's very little point in trying to copy solutions if it worked to solve their problems, not ours.
I already have a plan and it incorporates input and requirements from X departments.
It most likely is an aggregation of desired solutions that do not solve real problems. It also is likely overly complex because it tries to be everyone's solution.
I have KPIs that xxx/IDSC/committee already approved X years ago
You probably haven't reviewed if they're still appropriate and if it measures your ability to solve user problems
I already have a strategy approved X years ago
You probably missed out on technologies, solutions and products that came up.
We need to be no worse off / Ensure we're no worse off.
Problems don't always need to be solved in the same way, but "no worse off" generally assumes solutions are static.
It's impossible to track whether our tool improves productivity, saves manual labor and how much it improves the business.
You can't track the productivity increase for every person, but you can follow >5 teams for several weeks and record how much they benefit in time savings, efficiency, errors they encounter, or even entire work flows they no longer do. But this has to be done before you deploy and is pointless to lament you didn't after the fact.
Anything is technically possible. GPT 4, 5, 6, 7 are all the same. What matter are the business requirements and the use case.
I've heard this a lot. Tech advancements can meaningfully change the game for business. Like, models are literally getting much smarter with every release. This just betrays a lack of understanding by "technical consultants" and is a lazy excuse to not think deeper.
Dealbreakers
Symptom
Why I'd be scared
No one knows what problem is it we're solving.
No clear problem.
Problem being tackled seems to be changing after every meeting.
Problem keeps changing.
We're constantly adding new requirements to our total list of requirements.
Requirements keep growing.
No one's asking for this.
Nobody wants it.
Meetings are dominated by people who say "I think..." but no one actually knows someone who's a user.
No user knowledge.
You're doing things because bosses asked.
Boss-driven, not user-driven.
Problem is an edge case, but we have money, so who cares.
Solving a rare problem (wasteful).
Business owner says they need all the requirements, so let's keep every one.
Unfocused and wasteful.