/validating-problems

name: validating-problems
description: Use when a user wants to test, sharpen, frame, or gather evidence for a customer or business problem before pitching a direction, prioritising work, or writing a PRD.

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.

When no evidence is available, mark the claims unsupported and identify the smallest useful evidence assignment. Do not manufacture a verdict.

When a current problem brief exists, preserve its settled boundaries, evidence, claim statuses, and original `as_of` values. Before relying on a settled claim, check for materially new evidence, changed scope, expired relevance, or contradiction. Reopen only an affected claim and date its new assessment to the relevant new evidence. Do not advance an unaffected claim's `as_of` merely because the freshness check happened later. Otherwise resume only the unresolved or newly disputed claim, and do not restart the whole brief unless the user explicitly reopens it.

Evaluate four claims

Evaluate these claims independently:

| Claim | Evaluate | |---|---| | Existence | Determine whether the problem demonstrably happens. | | Audience | Determine for whom, where, and when it happens. | | Materiality | Determine what customer or business consequence it creates. | | Mechanism / context | Determine what conditions, behaviours, or constraints appear to produce or sustain it. |

Use `mechanism / context`, not `cause`. Keep causal explanations as hypotheses unless the evidence supports them. Do not require causal proof to socialise a well-supported problem.

Assign one status to every claim:

• `supported`: Use only when the scoped claim has relevant evidence strong enough for the current decision.
• `partially-supported`: Use when some parts are supported but important scope, coverage, or mechanism gaps remain.
• `unsupported`: Use when available material does not substantiate the claim.
• `contradicted`: Use when relevant evidence materially conflicts with the claim.

Make every status scope- and time-bound. Record `as_of`. Never generalise beyond the users, workflow, context, or period represented by the evidence.

Assess evidence

Classify evidence as a starting point, not as a mechanical score:

• **Anchor evidence:** Prefer observed workflow behaviour, product telemetry, transactions, churn or funnel data, support cases, direct interviews about recent past behaviour, workarounds and artefacts, and workflow observation.
• **Corroborating evidence:** Use stakeholder input, prior internal documents and research, sales or operations reports, customer-success patterns, and relevant external benchmarks to reinforce or qualify anchor evidence.
• **Hypothesis-only inputs:** Treat PM or executive judgement, isolated feature requests, AI reasoning, trend narratives, survey intent, and proposed solutions as hypotheses rather than proof.

Assess each evidence item across six dimensions:

• **Directness:** Distinguish observed, reported, and inferred evidence.
• **Relevance:** Check whether it covers the exact workflow or only an adjacent context.
• **Recency:** Record when the evidence was observed or collected.
• **Coverage:** Check representation across relevant users and situations.
• **Reliability and provenance:** Record the source, collection method, and material limitations.
• **Direction:** State whether the item supports, weakens, or is ambiguous about the claim.

Separate raw observation from interpretation. Do not treat direct evidence as automatically decisive. Weigh relevance, recency, coverage, reliability, provenance, and conflicting evidence together.

Route by product stage

Select evidence appropriate to the product stage without weakening the meaning of `supported`:

• **Pre-product:** Seek direct accounts of recent pain, observed current workf