validating-problemslisted

# Validating problems ## Overview Determine what can defensibly be said about a customer or business problem before a team pitches a direction, prioritises work, or writes a PRD. Produce a scoped, solution-free problem definition whose claims remain traceable to evidence. Keep problem validation separate from prioritisation and solution validation. Remain useful when evidence is incomplete without lowering the standard for calling a claim supported. ## Bound the decision Establish or infer these boundaries before evaluating the problem: - `decision_to_inform`: Name the decision this work will support. - `desired_outcome`: Name the customer or business condition that should improve. - `scope`: Bound the exact users, workflow, context, and time period covered. - `out_of_scope`: Exclude prioritisation, solution selection, and any other adjacent decision not being tested. Do not force the user to restate a boundary already present in the conversation or available evidence. Narrow the claim when the evidence covers less than the proposed scope. ## Inspect before asking Inspect relevant conversation context, linked workspace files, research, analytics summaries, support material, and previous problem briefs before asking a question. Cite each inspected source or path in the evidence ledger. Never ask the user to transcribe evidence that can be accessed safely. When no evidence is available, mark the claims unsupported and identify the smallest useful evidence assignment.