problem-framing

To turn vague feature requests into clear problem statements, you separate the proposed solution from the underlying user struggle. This process generates three testable variations differing by scope, persona, and root cause.

In product discovery, a problem is the actual user struggle or unmet need, while a solution is the proposed implementation to fix it. Separating them prevents premature solutioning and ensures teams build the right features.

To write a one-page problem brief for user research, you summarize the affected user profile, current behavior, evidence, and open questions. This brief grounds the validation process and clarifies what evidence matters for the specified user segment.

Yes, you can use problem framing for stakeholder requests like adding an export feature by redirecting the request to explain what users are trying to achieve, how often they fail, and what evidence matters to validate the actual need.

After drafting a problem statement, you should ask validation questions that check the evidence, frequency of user failure, and scope of the struggle. A checklist of these validation questions is generated to test the statement's assumptions.

You should avoid jumping straight to solutioning during product ideation when you receive vague ideas or metric signals. Articulating these ambiguous inputs into testable problem statements first clarifies costs and open questions before development begins.