Choosing first use cases with FOCUS 🔎

The first use case does not have to prove that AI is magic. It has to prove that you can decide. Pilot purgatory is merciless: most GenAI pilots never reach a measurable return — not because AI doesn’t work, but because the pilot was never chosen to answer a question. FOCUS avoids showcase pilots with five questions every proposal must pass.

From constraint to pilot 🚦

Start from the value stream and the Theory of Constraints: first find the bottleneck, then choose where to apply AI. If the constraint is review, an assistant that generates more code can make the queue worse. A good pilot might instead prepare review context or classify low-risk diffs. Introducing AI into a chaotic process accelerates the chaos: the framework exists precisely to avoid that.

Use a Wardley lens: automate work that has become commodity, protect the choices that differentiate the product. To tell the two apart, run the “what if it disappeared?” test — if nobody would notice within six months, it is infrastructure and should be automated; if it is the reason customers choose you, it is strategic leverage and deserves human oversight. Then design an experiment lasting a few weeks with an owner, a comparison group, and a final decision: expand, correct, or stop.

1
2
3
4

Hypothesis: automatic ticket summaries reduce triage time.
Baseline: median triage time and monthly ticket volume.
Guardrail: no increase in reopened tickets.
Decision: extend only if time drops clearly without degrading quality.

Three horizons, not a single pilot 🎯

A single use case, however perfect, does not build a direction. Think of a portfolio with three horizons:

Quick wins pay the bills and build trust; bets build the future; the middle band — workflow redesign — is the most neglected and, according to McKinsey, the one that brings the most value. Don’t pick only bets, but don’t stop at the first quick win either: both are portfolio mistakes.

Prioritizing candidates with WSJF ⚖️

Once candidates pass FOCUS, you need a way to rank them. WSJF (Weighted Shortest Job First) divides the cost of delay by the job duration: the higher the result, the sooner it should be tackled. Cost of delay breaks down into user value, time urgency, risk reduction and lost opportunity.

The exercise has a valuable side effect: it forces the team to state what doing nothing costs. Beware of one trap though: WSJF numbers are estimates, not measurements. If two candidates tie, pick the one with the baseline that is easiest to measure — because the project you can’t evaluate is the project you won’t be able to defend at the quarterly review.

A practical summary: FOCUS filters candidates, Wardley aligns the choice with strategy, WSJF orders what remains. Three light tools, none requiring a program management department. A retrospective and a shared spreadsheet are enough.

Five questions before approving 🧐

Every proposal, before becoming a project, must answer:

1. Who suffers today from this problem in daily work, not on a slide?
2. Where is the constraint: is value really released here, or does it stay stuck downstream?
3. Which data are needed, and is it legal to use them (GDPR, production data, residency regions)?
4. Who decides at the end of the experiment, and with which criteria written in advance?
5. What gets dismantled if the experiment fails — is the exit path explicit?

If an answer is vague, the use case is vague. Starting an ambiguous project takes no courage; rejecting or bounding it does.

Anti-patterns in selection 🚫

• Big-bang: automating everything in one initiative. The first cause of failed transformations.
• Demo-driven: choosing the case that impresses in the demo, not the problem that really costs.
• Tool noise: starting from the most talked-about tool of the week instead of the observed constraint.
• Pilot without a decision: the experiment that drags on because nobody wrote the stop criteria.
• No comparison group: measuring “before/after” without controlling for other variables (seasonality, other ongoing initiatives).

Minimal checklist ✅

• The constraint was observed in the flow, not imagined in a demo.
• An operating team sponsors the test.
• Baseline and quality guardrails exist.
• The perimeter includes permitted data and an exit path.
• Decision criteria written before seeing results.
• The case has a place in the three-horizon portfolio.

The next step is measuring without illusions: a FOCUS choice without metrics is just a nicely formatted preference. If the experiment passes the test, lightweight governance decides how to scale it without blowing up.