Problem Statement

Outcome: Use Problem Statement to make a focused product decision backed by evidence. User context: Freelancers miss unpaid invoices because updates are split between email and chat. Product concept to apply: Problem Statement. Why it fits: Write it before planning features, especially when the team argues about a solution too soon. Do not use it when: Never name the screen or control you want inside the problem. That would choose a solution too early. Product framing: Name the target user and wanted result. Record the current baseline and evidence. Set what is in and out of scope, the limits, the owner, and the time frame. Decision quality: Keep facts, guesses, and unknowns separate. Record the options you did not choose and what evidence would change the decision. Acceptance criteria: The document names an owner, target user, measurable result, scope limit, evidence source, open risks, and next test. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Target group, baseline, success level, owner, time frame, dependencies, and review schedule.