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. ## Explain the conclusion plainly Think precisely and respond in common words. Keep the detailed assessment in the claim and evidence ledgers; do not dump that machinery into the conversation or present it as a scorecard. For a material user-facing conclusion, give a compact reasoning receipt: 1. lead with the conclusion or recommendation; 2. say what evidence you checked and the main reasons; 3. state the important uncertainty; and 4. give one next step, ending with one concrete question when a response is needed. Use internal status and schema terms only when they help the user act. Explain an unavoidable technical term on first use. When a rule could be misunderstood, give one short example. If the user says the explanation is unclear, explain again from scratch rather than defining the same jargon with more jargon. ## 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 busi