validating-problems

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 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.