And What That Means for Wave 1 Selection

Ambitious first AI use cases make excellent programme launch presentations. They make terrible Wave 1 delivery choices. The best first AI use case is one your team builds in eight weeks, deploys cleanly, and never has to apologise for at a steering committee.

There is a conversation that happens in almost every enterprise AI programme at some point in the first few months. The programme lead is in front of the steering committee. The first quarterly review. The committee members — who approved the budget, who sold the programme to the board, who have been managing stakeholder expectations — want to know what is in production.

The answer, in too many cases, is nothing. There are models in development. There are sprints in progress. There is genuine activity. But nothing has been deployed, nothing is generating inferences, and nothing is producing the business outcomes the programme was funded to deliver.

The committee is polite about it. But the credibility damage starts here. And it compounds at every subsequent review until either something reaches production or the programme's mandate is revisited.

The cause, in the majority of these cases, is not poor execution or inadequate engineering capability. It is the wrong Wave 1 use case selection. Specifically: the programme selected impressive use cases instead of deployable ones.

This article makes the case for boring. Not as a permanent strategy, and not as a lack of ambition. As the single most important structural decision a Wave 1 programme team can make — and the decision that is most consistently subverted by the political dynamics of AI programme launches.

EXECUTIVE SUMMARY

Four reasons the boring use case outperforms the impressive one in Wave 1:

1. It reaches production. The impressive use case frequently does not.
2. It proves the MLOps stack works — on a forgiving model, before the complex builds stress-test it.
3. It gives the steering committee something real at the first quarterly review — shifting the conversation from 'when will we see something?' to 'what is next?'
4. It protects the programme's credibility for Wave 2, when the genuinely ambitious use cases arrive.

What 'Boring' Actually Means in AI Use Case Prioritisation

The word boring is doing specific work here. It does not mean low value, it does not mean technically uninteresting, and it does not mean unworthy of the programme's mandate.

In the context of AI use case selection, boring means: well-understood problem, clean available data, standard model architecture, small manageable change management footprint, and a path to production that can be traversed in eight to twelve weeks.

That is not a low ambition. That is an executable plan. And an executable plan in Month 3 is worth significantly more to a programme than an ambitious plan in Month 9 that has not yet reached production.

The Scoring Profile of a Boring Use Case

A boring use case has a characteristic scoring profile across the five dimensions of a structured AI use case prioritisation framework. It is not distinguished by any single exceptional score. It is distinguished by being strong across all five — including the dimensions that impressive use cases typically fail on.

The Boring Use Case — Target Scoring Profile Across Five Dimensions

The composite score produced by this profile — typically 3.9 to 4.5 — places the boring use case at or near the top of any structured ranking. Not because it is the most valuable use case in the portfolio. Because it is the most deliverable one. And deliverability, in Wave 1, is the primary criterion.

The contrast between a boring Wave 1 use case and an impressive one plays out consistently across every dimension that matters for programme delivery. The table below maps that contrast explicitly.

Wave 1 Use Case Profile Comparison: Boring vs. Impressive

The pattern across the table is clear. The impressive use case outscores the boring one only on Business Value — and frequently not by as much as stakeholders expect, because impressive value cases are often harder to quantify concretely. Across every other dimension, the boring use case scores more strongly: better data, simpler build, lower change demand, faster value realisation.

This is why a structured scoring framework almost always ranks the boring use case above the impressive one for Wave 1 assignment. The composite score reflects the full delivery picture, not just the business case narrative.

THE COMPOSITE VERDICT

The impressive use case makes the better slide. The boring use case makes the better Wave 1. These are not the same thing — and confusing them is one of the most reliable ways to produce a programme that has nothing in production at its first steering committee review.

What the Boring Use Case Actually Delivers: The Three Production Proofs

The value of a boring first use case is not just its direct business output — the FTE saving, the error rate reduction, the throughput improvement. Its deeper value is the three production proofs it generates within the first quarter.

The Three Production Proofs — What a Boring First Use Case Delivers Beyond Its Direct Business Value

These three proofs are not incidental. They are the foundational investments that make Wave 2 and Wave 3 significantly less risky. A programme that has proven its MLOps stack on a simple model can attempt a complex model with confidence. A programme that has successfully managed adoption on a low-demand use case has change management muscle for the high-demand ones. A programme that has a steering committee saying 'what is next?' has the political capital to absorb the complexity and delays that ambitious use cases inevitably bring.

The boring use case earns its position in Wave 1 not just on its own merits — but on the value of what it makes possible in Wave 2.

The Selection Pressures That Push Programmes Toward Impressive

If boring use cases consistently score better and deliver more reliably in Wave 1, why do so many programmes select impressive ones instead? The answer is selection pressure — a set of organisational and political forces that systematically bias the shortlist toward ambitious, visible, narrative-friendly use cases.

Each of these pressures has a counter-argument. The counter-argument needs to be available to the programme team in the room when the pressure is applied.

Selection Pressures and Evidence-Based Counter-Arguments

The common thread across all four selection pressures is that they privilege the programme's internal narrative over its external delivery. They are arguments about what the programme wants to be seen doing — not about what it is most likely to actually achieve in Wave 1.

The structured scoring framework is the programme team's most effective tool for holding the line against these pressures. When the composite score places the boring use case above the impressive one, the argument shifts from preference to evidence. Seniority can override a preference. It is harder to override a documented scoring methodology that governance leadership agreed to before the session started.

Impressive use cases win the programme launch. Boring use cases win the first steering committee review. The programme that gets both right plans them in sequence — not in competition.

What 'Boring' Looks Like in Practice: Three Archetypes

The term boring is abstract until it is grounded in specific use case characteristics. The three archetypes below represent the most common Wave 1 boring use case profiles across enterprise AI programmes.

Archetype 1 — The Back-Office Process Classifier

A model that classifies, routes, or triages documents, requests, or transactions that currently require manual review. Examples include: insurance claims triage, invoice exception detection, IT support ticket routing, contract clause classification, and regulatory filing categorisation.

What makes it boring: the problem is well-defined, the data is structured and usually from a mature operational system, the model type is standard (classification on tabular or text data), and the affected user population is small and typically already motivated to reduce manual workload. What makes it valuable: even a 15–20% reduction in manual processing time in a high-volume back-office function represents significant FTE-equivalent savings — and the business case is entirely auditable.

Archetype 2 — The Anomaly Detector on Operational Data

A model that identifies anomalies, outliers, or exceptions in structured operational data streams — financial transactions, production quality metrics, network activity, or supply chain events.

What makes it boring: anomaly detection on structured tabular data is one of the most mature AI problem types, with well-documented approaches, established benchmarks, and standard tooling. The data is typically already being collected and stored for reporting. What makes it valuable: false positive rates in existing rule-based systems are typically high, generating substantial manual review workload. An ML model that reduces false positives by 30–40% while maintaining detection sensitivity produces quantifiable operational savings with a clean cost-per-case calculation.

Archetype 3 — The Predictive Maintenance Signal

A model that predicts equipment failure, maintenance requirements, or service degradation from structured sensor or operational data, in manufacturing, facilities management, or infrastructure contexts.

What makes it boring: the data is almost always already being collected for operational reporting, the model type is regression or classification on time-series structured data, and the affected user population is maintenance engineers who are actively motivated to reduce unplanned downtime. What makes it valuable: even a modest improvement in maintenance scheduling — 10–15% reduction in unplanned downtime — produces quantifiable operational savings that are straightforward to calculate from existing maintenance cost records.

WHAT THESE HAVE IN COMMON

All three archetypes share the same five characteristics: structured data from mature operational systems, standard model type with existing benchmarks, small and motivated user population, quantifiable business value, and a path to production in under twelve weeks. That is the boring use case profile. That is the Wave 1 profile.

Sequencing Boring and Impressive Correctly

The argument for boring is not a permanent argument. It is a sequencing argument. The ambitious, transformative use cases that belong in every enterprise AI programme are not wrong choices. They are choices for Wave 2 and Wave 3 — once the foundation has been laid.

The correct sequence is: Wave 1 proves the delivery capability. Wave 2 applies that capability to harder problems. Wave 3 attempts the genuinely transformative use cases with a team that has operational experience, an MLOps stack that has been battle-tested, and a steering committee that has seen the programme deliver.

What Changes Between Wave 1 and Wave 2

• The MLOps stack has been tested in production. Architecture decisions that were theoretical are now validated. Infrastructure gaps that would have been discovered mid-build on a complex use case were discovered and fixed on a simple one.
• The change management process has been rehearsed. The adoption approach that worked on a low-demand use case has produced a template — lessons on communication, training, and resistance management that improve the Wave 2 approach.
• The team has production experience. The data scientists, ML engineers, and product managers who delivered Wave 1 understand how this organisation's data, systems, and stakeholders behave in a live delivery. That knowledge is not available at programme start.
• The steering committee has seen evidence. The political capital accumulated by a successful Wave 1 production deployment is the most valuable resource a programme team can bring into Wave 2 planning. It is not available without Wave 1 delivery.

The impressive use case in Wave 2 is a different proposition than the same use case in Wave 1. The team is more capable. The infrastructure is proven. The organisation is more confident. The risk that made it a Strategic Bet in Wave 1 has been partially absorbed by the preparation work that Wave 1 funded.

SEQUENCING RULE

Boring in Wave 1. Ambitious in Wave 2. Transformative in Wave 3. Not as a rigid formula — but as a default sequencing principle that should require an explicit, evidence-based justification to override. The burden of proof is on anyone proposing an impressive Wave 1 use case, not on the programme team proposing a boring one.

How to Defend the Boring Choice in a Selection Session

The structural arguments above are most effective when they can be expressed simply in the room where Wave 1 selection decisions are made. Three questions can anchor the defence of a boring use case when selection pressure pushes in the other direction.

Question 1: What is this programme's production output by the first steering committee review?

This is the most powerful question because it shifts the frame from ambition to accountability. The steering committee will ask this question at Month 3. The only satisfactory answer is 'a model in production, delivering measurable business value, with monitoring live.' A boring use case makes that answer possible. An impressive one frequently does not.

Question 2: Which of these use cases proves our MLOps stack before we stress-test it?

Every Wave 1 programme is also a platform build. The first deployment to production is always partially an infrastructure validation exercise. A boring use case on standard infrastructure finds integration issues, monitoring gaps, and retraining pipeline problems at a point when they are cheap to fix. An impressive use case on novel infrastructure finds them at a point when they are programme-threatening.

Question 3: What does this use case's composite score tell us about Wave 1 readiness?

This question works best when a structured scoring framework has been used to produce the composite ranking before the selection session. The boring use case's score should be visible, explained, and defended on the evidence of its five dimension scores. The impressive use case's score — typically pulled down by low D3, D4, and D5 scores — should be equally visible. The programme team is not arguing preference. It is reading from a scoring output that governance leadership agreed to before scores were entered.

The Boring Use Case Is the Strategic Choice

The framing of 'boring' is deliberately provocative. The use case it describes is not actually boring — it is a structured investment in programme credibility, MLOps capability, and organisational AI literacy that makes every subsequent use case cheaper, faster, and less risky to build.

The programme that selects its first AI use case on the basis of what it can deliver — rather than what it can claim — is not playing small. It is playing strategically. The ambition is not absent from the programme. It is present in Wave 2 and Wave 3, arriving on a foundation that Wave 1 built.

The impressive use case that fails to reach production in Wave 1 does not demonstrate the programme's ambition. It demonstrates that the programme selected the wrong use case for the wrong reason at the wrong time.

Boring in Wave 1 is not a concession. It is the strategic play — the investment in delivery credibility that makes ambitious use cases possible later. The programmes that understand this sequence consistently outperform the ones that do not.

AI Use Case Prioritisation Framework — viksya.com

The scoring profile for a 'boring' use case described in this article — high D2, high D3, high D4, fast D5 — is exactly the profile that produces a strong composite score and an automatic Wave 1 assignment in the AI Use Case Prioritisation Framework. The framework scores up to 12 candidate use cases across five dimensions, ranks them by composite score, and flags portfolio balance risks including complexity concentration. The boring use case earns its position. The framework makes that visible.

Built for Programme Managers, CIOs, Strategy Leads, and Management Consultants. Excel-based. No code. Instant download.

→ Download the AI Use Case Prioritisation Framework 

Frequently Asked Questions

What makes a good first AI use case?

A good first AI use case combines moderate to strong business value with low technical complexity, clean available data, a small and motivated user population, and a path to production in eight to twelve weeks. It does not need to be the most strategically transformative use case in the programme. It needs to be the most reliably deliverable one — producing a model in production, with measurable business outcomes, by the first steering committee review. In a structured AI use case scoring framework, this profile produces a high composite score by scoring strongly across all five dimensions: Business Value, Data Feasibility, Technical Complexity (inverted), Change Management Demand (inverted), and Time to Value.

Why should AI Wave 1 include a quick win use case?

A quick win use case in AI Wave 1 serves three purposes beyond its direct business value: it proves the delivery team can build and deploy AI; it validates the MLOps infrastructure on a forgiving model before complex builds stress-test it; and it provides the steering committee with a tangible production output at the first quarterly review. Programmes that include only high-complexity use cases in Wave 1 frequently have no production output at their first review, which creates credibility risk that compounds at every subsequent review until something is delivered.

What is the risk of selecting ambitious AI use cases for Wave 1?

The primary risk of selecting ambitious, high-complexity AI use cases for Wave 1 is delayed production output. Ambitious use cases typically score low on Technical Complexity (D3), Change Management Demand (D4), and Time to Value (D5) in a structured scoring framework — all three of which depict factors that extend the time from project start to first production deployment. A programme with no production output at its first steering committee review faces credibility risk, stakeholder confidence erosion, and increased scrutiny on subsequent investment decisions.

How does a boring use case score in an AI use case prioritisation framework?

A boring AI use case — characterised by moderate business value, strong data readiness, low technical complexity, low change management demand, and fast time to value — typically produces a composite score of 3.9 to 4.5 in a five-dimension scoring framework. This places it at or near the top of the Wave 1 ranking, not because it has the highest Business Value score but because it scores strongly across all five dimensions. In the AI Use Case Prioritisation Framework from Viksya, this profile results in automatic Wave 1 assignment, passes the Data Feasibility hard gate, and does not trigger the complexity penalty.

When should an AI programme attempt ambitious or complex use cases?

Ambitious and high-complexity AI use cases are best sequenced for Wave 2 or Wave 3, after Wave 1 has produced at least one model in production. By that point, the MLOps stack has been tested, the change management approach has been practised, the delivery team has operational experience, and the steering committee has evidence of programme capability. An ambitious use case that arrives in Wave 2 on this foundation is materially lower-risk than the same use case in Wave 1 on an untested platform. The sequencing principle is: boring in Wave 1, ambitious in Wave 2, transformative in Wave 3.

Continue Reading — Viksya Insights

→ The gut-feel problem: why most AI use case selection processes produce the wrong shortlist 

→ Data feasibility as a hard gate: why AI Wave 1 fails when data readiness is assumed

→ Business value vs. technical complexity — the 2×2 every AI programme team should be using

→ Change management demand as an AI scoring dimension

→ AI Production Governance Toolkit— structured go/no-go before every model deployment

Viksya Editorial

Viksya publishes structured governance tools and practitioner content for enterprise AI and digital transformation programmes. All tools are available at viksya.com.

AI Wave 1 · Use Case Selection · Enterprise AI · Quick Wins · Programme Delivery · AI Strategy · Steering Committee · Production AI · MLOps