Build an AI Use Case Portfolio, Not a Wishlist

Most companies do not suffer from a lack of AI ideas. They suffer from having too many of them without a clear way to choose.

Once people start looking, every process becomes a candidate. Sales wants proposal support. Support wants case summaries. Finance wants document comparison. Engineering wants code assistance. HR wants better knowledge access. Operations wants ticket routing. Legal wants contract review. Leadership wants reporting.

Someone always has a spreadsheet of “AI opportunities.”

That list can feel like momentum. It is not yet strategy.

A wishlist collects possibilities. A portfolio makes choices.

That distinction matters because AI capacity is limited: technical capacity, leadership attention, trust, data readiness, security review, change energy, and the patience of teams asked to adopt one more thing.

If everything is a priority, the organization does not move faster. It creates more half-owned experiments.

The wishlist problem

AI wishlists usually grow from enthusiasm, not discipline.

That is understandable. The technology is broad, people see real friction in their work, and the first prototypes can be surprisingly convincing. It feels responsible to collect ideas.

The problem starts when all ideas are treated as comparable.

A personal productivity assistant, a team-level summarization workflow, and an agent that updates customer records may sit in the same backlog. One saves annoyance. One teaches a reusable pattern. One carries serious operational risk. They need different standards, but the wishlist format hides that.

The list answers “what could we do?”

It does not answer:

• what should we learn first?
• which workflows are worth owning?
• which patterns can be reused?
• where is the risk acceptable?
• which ideas are blocked by weak data or unclear process?
• what should be stopped?

Without those questions, prioritization becomes politics, volume, or executive excitement.

That is not a portfolio. That is queue management with better branding.

Different bets, different standards

The most useful thing you can do with an AI idea early is decide what kind of bet it is.

Not because the label is interesting, but because the label decides three things that are otherwise argued about forever: what evidence would show it worked, who should own it, and what should end it.

The bet type is not a category. It is the standard the idea will be judged by.

This is where most portfolios quietly fail. They sort ideas into neat groups and then evaluate all of them the same way, usually by time saved. Time saved is the easiest AI value story and often the shallowest one. It flatters productivity work, undersells capability work, and says almost nothing useful about a learning experiment.

Five kinds of bet cover most of what an organization will consider. The point of the list is not taxonomy. It is that each one comes with a different question.

1. Learning bets

A learning bet exists to close a question, not to produce value.

Can our contract data actually support extraction? Do case handlers trust a generated summary enough to act on it? What does review cost when the source document is incomplete? These are answerable, and answering them changes what the organization does next.

The deliverable is a finding, written down. A learning bet that produced a working prototype and no changed decision has failed, even though something got built. That is the failure mode worth watching, because it looks like success from the outside.

Evidence: a question that was open is now closed, with enough detail that someone can act on the answer.

Owner: whoever will make the next decision. Not the team running the experiment. If the person who would act on the finding is not involved, the finding will sit in a slide.

Stopping rule: a date, set at the start. Learning bets should be time-boxed by default, because their natural failure mode is turning into permanent pilots that nobody can close.

Escape the AI PoC TrapStop building AI prototypes that never make it to production. Discover how shifting from isolated tech demos to real product ownership turns impressive showcases into reliable workflows that actually drive business value.sebastianstoehr.de

“Strategic learning” cannot become an excuse for endless experimentation. Learning is valuable when it is captured and used.

2. Productivity bets

Productivity bets remove repeated friction for a lot of people. Summaries, drafts, translations, research support, routine analysis.

Individually small. Meaningful when many people do them every week, and close to worthless when they do not.

That is the distinctive property: the value of a productivity bet is almost entirely a function of adoption breadth. A capable tool that thirty people use out of a possible eight hundred has not produced a small benefit. It has produced a rounding error and a licence bill.

Low voluntary adoption is usually information rather than a communication problem. It often means the friction the tool removes was not the friction people actually felt.

Evidence: sustained voluntary use after the novelty period. Not seats provisioned, not pilot enthusiasm, not a satisfaction survey.

Owner: usually an enablement or platform function, since no single business team owns the benefit.

Stopping rule: adoption plateaus low. Resist the campaign. A productivity bet that needs to be pushed is answering a question nobody asked.

3. Workflow bets

A workflow bet changes how work moves. It has defined inputs, outputs, users, exceptions, and ownership.

This is usually where AI starts to produce measurable operational value, because the process around the model changes too. It is also the first bet where the model is the easy part. The hard part is whether the surrounding process can absorb a change: who checks the output, what happens to exceptions, and what the fallback is when the workflow cannot run.

A theoretical but realistic example: a support team moves from drafting case summaries by hand to reviewing generated ones. The model works. Then the questions arrive. What happens when the source ticket is incomplete? Who is accountable if the summary drives the wrong next step? Is reviewing the summary faster than writing it? Those are workflow questions, and none of them are answered by improving the prompt.

Start With Boring WorkflowsThe agent demos browse the web, write the code, and seemingly do your job. The agents that actually survive inside an enterprise are far less impressive – and that's exactly why they work. A case for starting boring.sebastianstoehr.de

Evidence: operational movement against a known before-state. Cycle time, handoffs, rework, exception rate. Workflow bets are the easiest kind to measure honestly, because the process existed before.

Owner: the process owner. This is the bet type where vague ownership does the most damage, because the output reaches real work.

Stopping rule: review effort does not fall, or the exception path stays undefined after a fair attempt. If checking the output costs nearly as much as producing it, the workflow has changed shape without getting cheaper.

4. Capability bets

Capability bets build something later work depends on: shared knowledge access, evaluation sets, approval flows, integration components, cleaner source data, reusable patterns.

They have no user on day one. That makes them the hardest to justify against immediate ROI and the easiest thing to cut when a quarter gets tight. Their absence shows up a year later, when the fourth team rebuilds the same retrieval layer slightly differently.

The discipline that keeps a capability bet honest is a committed first consumer. Infrastructure built for a hypothetical future user tends to be wrong in ways nobody discovers until it is expensive. Infrastructure built alongside one real workflow tends to be right enough to reuse.

From AI Tool Chaos to an Enterprise AI ToolboxMost enterprises start their AI journey as scattered, unmanaged experiments. That's not a failure – it's the raw material. The hard part is building a bridge from local chaos to shared capability without killing the learning in the process.sebastianstoehr.de

Evidence: the second and third use. One consumer means you built a component of that consumer’s workflow, which is fine, but it is not yet a capability.

Owner: a platform or shared function, paired with a named first consumer who has agreed to use it.

Stopping rule: no second adopter inside an agreed window. That result is worth knowing early, and it is cheaper to accept than to keep maintaining a shared asset with one user.

5. Strategic bets

A few bets touch core processes or competitive capability. They are slower, more expensive, harder to operate, and more exposed.

The distinctive risk is not technical. It is that a strategic bet accumulates visibility and sunk cost at the same time, and both of them work against stopping. By the time the evidence is discouraging, several people are publicly attached to the outcome.

That is why the checkpoints have to be agreed before the work starts, in writing, with the conditions that would end it. Deciding what would change your mind is much easier before anyone’s reputation is attached to the answer.

Evidence: the core process or the competitive position actually moved. Technology that works while the process around it stays the same is a loss, not a partial win. Judge it in stages, because that movement takes time, but each stage still needs a result that justifies the next one.

Owner: an executive who will still be accountable in eighteen months. Sponsorship that evaporates at the first bad quarter is worse than no sponsorship, because the work continues without air cover.

Stopping rule: a pre-committed checkpoint that goes unmet. This is the bet type where the stopping rule has to be written down first, because it is the one nobody will want to invoke.

Limit these to one or two at a time. An organization can survive several failed learning bets. It cannot easily survive three simultaneous strategic ones.

Mixing the portfolio

Once the bets are named, the mix becomes a visible decision rather than an accident.

Two failure patterns are common enough to watch for.

A portfolio that is almost entirely productivity bets looks efficient and builds nothing. Every quarter delivers modest, real improvements. Nothing accumulates, every team solves its own version of the same problem, and after two years the organization has more tools and no more capability.

The opposite is a portfolio weighted toward strategic and capability bets, where little lands in a form anyone uses. Progress is real but invisible, and the credibility needed to keep funding it erodes faster than the work completes.

Most organizations coming out of the experiment phase need a small number of learning bets with expiry dates, a few productivity bets that are genuinely adopted, one or two workflow bets treated seriously, and exactly enough capability work to stop teams rebuilding the same foundation.

That mix is a choice. Making it explicitly is most of what separates a portfolio from a list.

What to track

A practical AI portfolio does not need a scoring machine. It needs enough structure to support a better conversation.

For each idea, four fields carry most of the weight:

• which of the five bets this is
• what evidence would show it worked, stated in the terms of that bet
• who owns it, by name
• when the next decision happens

The last two are the ones that get skipped, and they are the ones that make the difference. An initiative with no named owner and no scheduled decision will not be stopped, because stopping requires somebody whose job it is to say so.

Every initiative should have a next decision: continue, reshape, scale, pause, or stop.

A portfolio without stopping rules becomes a graveyard of polite maybes.

Ideas should disappear

One of the healthiest signs of an AI portfolio is that ideas leave it.

Not because the organization lost ambition, but because it learned something. The data was not good enough. The review effort erased the benefit. The workflow was too rare. The risk was too high for the value. The team did not need automation; it needed a clearer process. The same need was already solved elsewhere.

Each bet type fails differently, which is the practical reason a single stopping rule never works. A learning bet fails by running past its expiry without producing a decision. A productivity bet fails by being available and unused. A workflow bet fails when review effort refuses to come down. A capability bet fails at its second adopter. A strategic bet fails slowly, in public, and long after the evidence arrived.

Killing those ideas is not failure. It is what creates space for the better ones.

The more dangerous pattern is a portfolio where every prototype stays “promising” forever because nobody wants to be the one who closes it.

That is how experimentation turns into clutter.

From activity to capability

The point of an AI portfolio is not to make innovation look tidy.

It is to turn scattered activity into organizational capability.

That means choosing a mix that creates value now, teaches the organization something it can use, builds foundations the next teams inherit, and avoids risks it cannot operate.

A wishlist asks: what could we do with AI?
A portfolio asks: what should we learn, build, reuse, scale, or stop next?

That is the more mature question after the first wave of experiments has proven that AI can be useful.

The next advantage will not come from having the longest list of ideas. It will come from making better choices about which ideas deserve to become real.