Problem Statements
Definitions
Goals
Questions to Ask
You need to be clear what you are trying to do. Identify a right, meaningful problem.
You need to focus on who the customer really is whom you're trying to value add, and target the key issues they're facing.
Focus on the gap, not the solution, and what the user wants achieved. Choosing the correct problem to solve increases the odds you succeed.
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 when the problem occurs (frequency, specific situations, time of day) helps prioritize solutions and identify trigger events for your product to intervene effectively.
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.
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.
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.
This question challenges assumptions and forces you to justify features or projects. It encourages critical thinking about necessity and impact.
First step to unblocking is to understand the nature of the blocker. Each type of blocker deserves its own treatment.
You want to target key issues users have with whatever you're trying to get them to do.
Choosing the correct problem to solve increases the odds you succeed in your initiative.
Challenge assumptions and justify features or projects.
Voss suggests this is useful way of asking to avoid triggering a defensive stakeholder.
Alarm Bells
Context is important, there's very little point in trying to copy solutions if it worked to solve their problems, not ours.
You probably missed out on technologies, solutions and products that came up.
Problems don't always need to be solved in the same way, but "no worse off" generally assumes solutions are static.
Track 5+ teams for several weeks before deployment to measure time savings and efficiency gains. After-the-fact measurement is pointless.
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.
Problem keeps changing every meeting.
Requirements keep growing.
Boss-driven, not user-driven.
Solving a rare problem (wasteful).
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.
You probably haven't reviewed if they're still appropriate and if it measures your ability to solve user problems
Dealbreakers
No clear problem.
Nobody wants it.
No user knowledge.