Problem Framingwhy the brief you receive is almost always wrong

Before you write the hypothesis sentence, diagnose the brief. The brief you were handed is almost certainly a solution in disguise, and running the hypothesis against a solution just gives you a confident answer to the wrong problem.

• “We need to redesign the onboarding flow” is a presumed solution, not a problem statement.
• “Users are dropping off before completing account creation” is closer, but still assumes the onboarding flow is the lever.
• “We are losing 40% of trial users at the account creation step and we do not know whether the cause is the cognitive load of the step, its position in the journey, or the expectation mismatch that precedes it” is a problem statement: it states what is known, what is not known, and where the diagnosis needs to go.

The first is a solution disguised as a mandate. The third is a diagnosis with an open question.

The diagnostic form of a problem statement has a consistent structure: [User] is failing to [accomplish goal] because [condition], not because [surface symptom]. That closing clause does the real work: stating the underlying condition keeps the solution from chasing the symptom. If you cannot write the brief in this form, you have not diagnosed it yet.

When the brief is more exploratory, where the input is observation rather than data, a second format works alongside it: the Stanford d.school Point of View statement, [user] needs [need] because [insight]. The diagnostic form states the condition. The POV statement carries the insight from observation. Both are in the Learn section.