define-hypothesis

Use the structured format: "We believe that [action/change] for [target user] will [expected outcome]." Then define a primary success metric with a numeric target, specify the validation method such as an A/B test, and document pass/fail criteria before building anything.

A falsifiable hypothesis can be proven wrong through evidence. It needs a specific target user segment, a measurable expected outcome, and unambiguous pass/fail criteria. Vague statements like "users will like it" cannot be tested or invalidated.

Create a hypothesis after problem framing but before committing to a solution or investing engineering resources. It is also useful when designing A/B tests, when team members hold conflicting assumptions, or when pivoting direction.

Include a primary metric that directly measures the expected outcome, secondary metrics for context, and guardrail metrics to ensure the change does not cause harm elsewhere. Each metric should have a specific numeric target.

Common mistakes include targeting "users" too broadly instead of a defined segment, lacking numeric success targets, assuming the solution works, and choosing impractical validation methods. The hypothesis must remain possible to prove wrong.