Problem Statement Framing: Define the 'Why' Before the 'What'

WHY IT EXISTS: To prevent teams from wasting time and resources building elegant solutions to the wrong problems. Without proper framing, teams can misinterpret user needs, chase symptoms instead of causes, and build features that ultimately fail to deliver value.

THE MENTAL MODEL: Think of it like a doctor diagnosing an illness before prescribing medicine. A patient might say 'I have a headache,' but the doctor's job is to find the underlying cause—stress, dehydration, or something more serious—before suggesting a treatment. Jumping to a solution (aspirin) without a diagnosis (the problem frame) is malpractice in medicine and product development.

HOW IT WORKS: Problem framing is an iterative process of inquiry. You start with a fuzzy observation, like 'users are dropping off at checkout.' You then gather context through user research, asking questions to reframe the issue from different perspectives. For example: 'Users find the checkout process too long,' 'Users don't trust us with their credit card,' or 'Users are surprised by shipping costs.' A good problem statement is human-centered, broad enough for creativity, but narrow enough to be manageable. A common format is: '[A user] needs [a way to do something] because [of this insight].'

WHEN TO USE IT: Use it at the very beginning of any new project, feature, or initiative. It's the cornerstone of design thinking and product discovery. It is essential for aligning stakeholders and creating a clear brief for design and engineering teams, ensuring everyone is solving for the same, well-understood user need.

WHEN NOT TO USE IT: It's less critical for well-defined, technical tasks with clear, non-negotiable requirements, like 'upgrade the database to the latest version' or 'patch this specific security vulnerability.' In these cases, the problem is already narrowly and correctly defined, and the goal is execution, not exploration.

ONE CANONICAL EXAMPLE: A team observes low engagement with a new feature. A poorly framed problem is 'How can we get more users to click the new feature button?' A well-framed problem, after research, might be: 'Busy professionals need a way to see the immediate value of a new feature within 10 seconds, because they don't have time to read documentation or watch tutorials.' The first leads to superficial solutions (make the button bigger), while the second leads to fundamental improvements (better onboarding, clearer UI copy).