Anchor a model-or-vendor decision on a clearly defined user problem in its intended business context—not on a preferred model, vendor, or solution. The GOV.UK Service Manual directs discovery toward the user’s problem rather than possible solutions, while NIST’s AI Risk Management Framework asks teams to define or reevaluate the business value or context of an AI use.
Taken together, these sources support a practical sequence: establish the problem and context first, document the intended benefits, and only then determine what a suitable solution must do.
Write the problem before proposing a solution
A useful problem statement does not need to name a model or vendor. It can follow this structure:
In [specific context], [defined user] has difficulty [completing a task or reaching an outcome] because [evidence-supported barrier]. This matters because [user or business value]. Improvement would be evidenced by [observable condition], while [relevant constraint] remains acceptable.
Each part serves a different purpose:
- User: Identify the person whose task or outcome is affected rather than describing an abstract audience.
- Context: State where and under what conditions the problem occurs.
- Barrier: Describe the observed obstacle without assuming that AI is the answer.
- Value: Explain what the user or business gains if the situation improves.
- Observable condition: Identify what would indicate improvement without turning an expected benefit into a guaranteed result.
- Constraint: Record what an acceptable solution must not undermine.
If removing the proposed technology makes the statement incomplete, the statement may describe a solution preference rather than the underlying user problem.
Check the problem before comparing options
Before evaluating models or vendors, test the statement against the evidence and context available to your team.
Can you substantiate the problem? Distinguish observed user difficulties from assumptions about what users want. The statement should reflect the intended use context, not a generalized complaint that may not apply there.
Is the value explicit? NIST asks teams to define or reevaluate the business value or context of an AI use. A statement such as “we want AI” does not explain that value; it only names a possible means.
Are potential benefits documented separately from expected outcomes? NIST also calls for examining and documenting the potential benefits of the intended AI system’s functionality and performance. Record those benefits as expectations to test, not as evidence that a particular system will deliver them.
Do comparison criteria follow from the problem? Derive criteria from the task, desired outcome, and relevant constraints. A feature list should not determine the problem in reverse.
Would another solution still address the statement? If the problem remains meaningful when the preferred model or vendor is removed, it is more likely to provide a stable basis for comparison.
What you still need to confirm yourself
The cited guidance does not identify your organization’s priority problem, affected users, success measures, risk tolerances, operating conditions, or vendor requirements. You still need to confirm:
- which problem is most important in the intended context;
- what evidence shows that the problem exists;
- which benefits and outcomes matter to the accountable stakeholders;
- what constraints any solution must satisfy;
- whether AI is appropriate at all; and
- which technical, operational, commercial, and risk details apply to the options being considered.
The decision anchor is therefore not a model name, vendor category, or impressive feature. It is a bounded user problem whose context, value, evidence, and improvement conditions are clear enough to guide—but not predetermine—the solution search.