A good AI use case is not simply the one with the most impressive demonstration.
A prototype can hide weak data, a difficult integration, uncertain ownership or a workflow that users have no reason to change. A quieter use case can create more value because it solves a frequent problem, fits the operating environment and leaves reusable capabilities behind.
Use-case selection is therefore a product portfolio decision. I look at impact, user value, strategic alignment, data readiness, technical feasibility, delivery effort, risk, reusability, adoption potential and time to value together.
Begin with the work, not the model
The most useful starting question is: where is important work currently slow, inconsistent or difficult to coordinate?
That might be preparing a complex case, consolidating evidence for a decision, routing an exception, monitoring a multi-country programme, drafting a controlled communication or helping a technical team diagnose an incident. Each is a workflow with users, inputs, decisions, hand-offs and consequences.
Only then should the team decide whether the best pattern is predictive, generative, agentic—or not AI at all.
A clear use-case statement answers five questions:
- Who is the primary user?
- What job are they trying to complete?
- What makes the current workflow difficult?
- What outcome would improve?
- Which decisions must remain with a person?
If those answers are vague, a score will create false precision.
Score value and readiness separately
I prefer to separate value from readiness because they answer different questions.
Value includes business impact, user value, strategic alignment, adoption potential and reusability. Readiness includes data, technical feasibility, delivery effort, risk and time to value.
This produces four useful conversations.
High value and high readiness suggests a priority. High value and low readiness suggests a selective bet: invest in evidence, data or controls before committing to scale. Lower value and high readiness may identify a quick foundation that creates reusable components. Low value and low readiness is a candidate to stop or reshape.
The numbers are not the decision. They make assumptions visible so that leaders can challenge them.
Reusability changes the economics
Suppose two teams propose assistants.
The first produces a polished summary for a small group, but depends on a specialist data source and a one-off interface. The second structures incoming documents for a larger operation. It looks less impressive, but it requires identity, document extraction, source traceability, human review, workflow routing and monitoring.
If those components can support later use cases, the second product may be strategically more valuable. It delivers a result and strengthens the platform.
Reusability should still be tested, not assumed. A “shared” component can become a bottleneck if it tries to satisfy every workflow. I look for repeatable capabilities with stable contracts: identity, retrieval, document intelligence, orchestration, evaluation, approval and observability.
Risk is part of product design
Risk should not be represented by one red, amber or green label added at the end.
The team needs to understand the possible harm, its severity, its likelihood and whether the product can detect and recover from failure. The answer changes the design.
A low-consequence drafting tool may use sampling and user feedback. A workflow handling sensitive evidence may require controlled retrieval, source display, representative test sets, explicit approval and detailed audit events. A tool that can change a production system needs narrow permissions, isolation, reversibility and existing release controls.
NIST’s Generative AI Profile (26 July 2024; updated April 2026) provides a cross-sector lifecycle for governing, mapping, measuring and managing risk. The useful product lesson is that context and intended use determine the control design.
Data readiness needs evidence
“The data exists” is not the same as “the product can use it.”
Readiness includes access, quality, provenance, coverage, timeliness, permissions and the ability to create an evaluation set. It also includes operational ownership. Someone must keep a knowledge source current and respond when a connector fails.
Before approving a use case, I would ask for a small representative sample. Can the team retrieve the right evidence? Are important exceptions present? Can knowledgeable reviewers agree on what a good output looks like? If not, the next investment may be in data or process design rather than a model.
Adoption potential is observable
Teams often treat adoption as a soft estimate. It can be investigated.
Observe the current workflow. Count hand-offs. Identify the moment when the user needs help. Test whether the proposed product removes work or adds another destination. Find the people who will support it locally. Ask what would cause them not to trust it.
McKinsey’s 2026 global AI survey distinguishes organisations that redesign workflows and back deployment with operational discipline. That matters because access to AI can increase without changing an outcome.
Adoption also needs a realistic owner. A central team can build a platform and initial workflow, but domain leaders must help define quality, train users and integrate the product into day-to-day operations.
Choose the first experiment deliberately
A first experiment should reduce the most important uncertainty.
If model quality is unknown, test on a representative offline set. If users may reject the workflow, build a thin interface and observe real tasks. If an integration is the constraint, prove read-only access before designing an agent. If risk is material, test failure modes and approval behaviour before measuring speed.
The experiment should have a decision attached: what result would justify the next step, and what result would stop it?
BCG’s 2025 AI Radar argues for focusing investment on a small set of meaningful initiatives and measuring operational and financial outcomes. I agree with the direction, but the practical discipline begins earlier: define evidence before building.
Keep the portfolio alive
Prioritisation is not an annual ceremony. Data improves, regulations change, models evolve, adoption surprises and dependencies become clearer.
I would review the portfolio at a regular cadence. Each use case should show its hypothesis, owner, next evidence, current risks, reusable capabilities and decision date. Some should be accelerated. Some should be narrowed. Some should be stopped without embarrassment.
The goal is not to predict perfectly. It is to allocate attention transparently and learn faster than the opportunity set changes.
Three takeaways
- Select workflows around users and outcomes before choosing an AI pattern.
- Score value and readiness separately, and give reusability, risk and adoption real weight.
- Design each experiment to resolve a specific uncertainty and end with a stop, improve or scale decision.
*The views expressed here are personal and do not represent those of my current or previous employers.*