An AI use case deserves product discovery when important assumptions remain about the user problem, likely users, intended tasks, or the business value and context of the use. Discovery is also warranted when existing assumptions have changed and need to be reevaluated—not when the team is merely searching for a model or vendor to attach to an already formed solution.
Start with the problem, not the proposed AI system
The GOV.UK Service Manual says discovery should focus on the user’s problem rather than possible solutions. A useful first check is therefore simple:
Can the team describe the problem without relying on language about AI, a specific model, or a preferred vendor?
If not, the solution may be leading the discovery. The immediate task is to establish what problem matters and for whom before comparing possible responses.
A practical decision rule can combine three questions:
| Discovery question | What to examine | Signal that discovery is needed |
|---|---|---|
| What is the user’s problem? | Whether the need is clear independently of a proposed solution | The team is solution-led but cannot explain the underlying problem |
| Who are the likely users, and what are they trying to do? | Whether user groups and intended tasks are evidence-based rather than assumed | Important audiences or tasks remain internal guesses |
| What business value or context justifies the use? | Whether the intended value and operating context are clearly defined | The business case is vague, disputed, or based on unexamined assumptions |
These checks synthesize the cited guidance; they are not a universal scoring threshold prescribed by either source.
Check users and tasks, not just demand for AI
The GOV.UK guidance also says discovery research should identify who the likely users are and what they are trying to do. That distinction prevents a broad statement such as “users need AI” from standing in for product understanding.
A team is closer to a clear use case when it can specify:
- which users face the problem;
- what those users are trying to accomplish;
- how the problem manifests in their context; and
- which assumptions still require validation.
The exact research method is less important at this framing stage than making the assumptions visible. A polished solution concept cannot compensate for uncertainty about the user or task.
Define the business value or context
The NIST AI Risk Management Framework includes clarity about the business value or context of an AI use as a core consideration. NIST also calls for that value or context to be defined or reevaluated.
This provides a second stopping point: if the team cannot explain the value of the proposed use or the context in which it would operate, that uncertainty belongs in discovery. If those conditions have changed since the original proposal, reevaluation is warranted before selecting a solution.
A concise use-case statement can capture the test:
This use addresses a defined problem for identified users trying to accomplish a specific task, within a clearly understood business context.
Any unsupported assumptions should remain explicitly marked as questions rather than being converted into confident requirements.
What the team must still confirm
The three checks establish whether a use case is ready for deeper evaluation; they do not prove that AI is the appropriate solution. The team must still validate its descriptions of users and tasks, examine alternative ways to address the problem, and assess technical and operational feasibility in its own context.
Neither cited source supplies a universal threshold based on budget, team size, technology, or industry. Use the framework as a decision gate: if the problem, users and tasks, or business context remains unclear, begin or return to product discovery. If they are clear, the team can move to evaluating possible solutions without treating the initial AI concept as self-validating.