The plant manager calls you into her office on a Monday and slides a whiteboard photo across the desk. On it are four boxes she scrawled after a leadership offsite, each one a thing a VP told her the plant should do with AI this year. Box one: machine-vision quality inspection on the bracket line, because the cracked-bracket escape last quarter cost real money. Box two: predictive maintenance on the big stamping press, because it failed twice on hot afternoons and stopped the whole plant. Box three: AI scheduling to lift throughput, because OEE will not move off 62%. Box four: capture Dave's twenty years before he retires in November, because nobody else can hear a bearing go bad. She has budget for one, maybe two, this year. She has one engineer who can actually run an AI project, namely you. And she has a board meeting in six weeks where she has to say which one the plant is doing and why. Then she asks the question that this entire lesson exists to answer: which one do we do first, which one do we do second, and which one do we deliberately not do yet. Picking wrong does not just waste a year of budget. It can poison the plant's appetite for AI for years, because the first project everyone watches, and a first project that fails loudly makes the next one impossible to fund. This is the prioritization problem, and the answer is not a gut call. It is a matrix.

The Four Big Use Cases Are a Portfolio, Not a Wish List

The four boxes on that whiteboard are the four load-bearing AI use cases for almost every plant: quality, maintenance, throughput, and knowledge capture. They are the spine of this whole program and they map directly onto the biggest bars on your loss chart. Before you can rank them, you have to be honest about what each one actually is, because a VP's one-line version hides the part that decides whether it succeeds.

Quality, usually machine vision. A camera and a model grade parts at line speed and flag cosmetic or dimensional defects. The promise is catching the escape before it becomes a containment. The hidden hard part is the false-reject rate (FRR, the share of good parts the system wrongly rejects) and drift, the slow degradation as lighting, camera angle, and material change between shifts. Quality is where adoption already broke through: 47% of manufacturers now use AI in quality, up from 33% the prior year, so the path is well worn and the evidence is real.

Maintenance, usually predictive. Sensor and historian data feed a model that flags a bearing, motor, or pump trending toward failure, so you fix it on a planned window instead of at 2 p.m. on a hot Friday. The promise is killing unplanned downtime, the tallest bar on most plants' loss charts. The hidden hard part is that a prediction is worthless unless it becomes a verified, prioritized work order, and that alert fatigue, a model that cries wolf, will get the whole thing ignored within a month.

Throughput, usually scheduling and changeover optimization. A model sequences jobs, optimizes changeovers, or balances the line to lift OEE (overall equipment effectiveness, the product of availability, performance, and quality, the single number plant managers stare at). The promise is moving that stuck OEE number. The hidden hard part is that throughput AI depends on clean, integrated data from the MES (manufacturing execution system, the software that tracks what is being made and when) and the scheduling system, and most plants do not have that data clean, so the model optimizes a fantasy.

Knowledge capture. Structured interviews and historical-record mining turn a retiring expert's tribal knowledge into a knowledge base the next shift and the AI can both use. The promise is keeping twenty years of know-how from walking out the door in November. The hidden hard part is that it feels soft, it is hard to put a single-quarter dollar figure on, and it competes for attention against three use cases that each point at a specific bleeding wound.

The reason to see these four as a portfolio rather than a wish list is that they have different risk profiles, different data requirements, different time-to-value, and different blast radius if they fail. Treating them as interchangeable line items a VP can pick by enthusiasm is how plants end up doing the flashiest one instead of the right one. The matrix forces the comparison onto axes that actually predict success.

Pick your first AI use case by impact times feasibility, not by which demo was shiniest at the conference.

The Two Axes: Impact and Feasibility

Every prioritization framework eventually collapses to two questions: how much is this worth, and how likely are we to actually pull it off here. The first axis is impact. The second axis is feasibility, which in a brownfield plant is really a risk axis wearing a friendlier name. Score each use case on both, plot the four boxes, and the sequence almost draws itself.

Scoring impact in dollars off the loss chart

Impact is not a feeling, it is a number you read off your own loss chart. Pull the last twelve months and put a dollar figure on each use case's target loss. For quality, it is the cost of escapes and the scrap and rework you would prevent: take the bracket escape that became a containment, add up the sort labor, the expedited freight, the charge-back, and the scrap, and you may find a single event cleared six figures. For maintenance, it is the cost of unplanned downtime on the constraint equipment: if the stamping press going down stops the whole plant and you lose, say, several thousand dollars per hour of contribution margin, and it went down for eleven hours across two events last year, that is the prize. For throughput, it is the value of the OEE points you could realistically recover, which is genuine but usually the hardest to attribute cleanly to AI. For knowledge capture, it is the cost of losing the expert, which is real but deferred and diffuse, the escapes and the extra downtime that happen after Dave leaves because nobody can hear the bearing anymore.

Be honest that impact has a timing dimension. Quality and maintenance pay back inside the year if they land. Throughput pays back over a year or two as the schedule tightens. Knowledge capture pays back mostly after the expert leaves, which makes it the easiest to defer and the one that hurts most if you defer it past November and Dave is gone.

Scoring feasibility honestly in a brownfield plant

Feasibility is where most prioritization goes wrong, because plants score it optimistically. Be brutal. Feasibility is the product of several brownfield-honest factors, and a single hard zero on any of them can sink an otherwise high-impact use case.

Do you have the data, labeled and accessible? Machine vision needs labeled images of good and defective parts, ideally hundreds of real defect examples, and many plants discover they throw their defects in a scrap bin instead of photographing them. Predictive maintenance needs historian data with enough run-to-failure history to learn a pattern, and if the historian was only logging for three months, the model has nothing to learn from. Throughput needs clean MES and scheduling data. Knowledge capture, notably, needs almost no pre-existing data because you are creating it from the expert, which is a feasibility advantage people overlook.

Can you see and safely touch the system? This is the OT/IT boundary (OT is operational technology, the controls-and-sensors network; IT is the office network). Remember that 78% of OT networks lack centralized monitoring, so getting sensor data off a 1990s PLC (programmable logic controller, the industrial computer that runs the machine) may be a project in itself. A use case that needs deep integration into a control system you can barely see is less feasible than one that reads data passively.

What is the blast radius if it fails? A vision system that false-rejects too much scraps good parts and annoys operators, which is bad but recoverable. A predictive model that misses a failure costs you a downtime event you would have had anyway. But any use case that touches direct control of something that moves, or anything safety-critical, carries a blast radius that should push it down the list or off it entirely, because AI belongs advisory and out of direct control until it is properly governed.

Will the operators accept it? An operator who has been burned by a false alarm will disable the green light, and a use case the floor will not use has zero impact regardless of its model accuracy. Feasibility includes the social dimension: the use case with a clear, trusted human handoff is more feasible than the one that asks operators to trust a black box.

Reading the Matrix: First, Second, and Not Yet

Plot the four use cases with impact on the vertical axis and feasibility on the horizontal, and you get four quadrants that tell you exactly what to do. This is the deliverable your plant manager takes to the board, and it turns a gut argument into a defensible sequence.

High impact, high feasibility: do this first. This is your anchor project, the one that proves AI works at your plant and earns the budget for the next one. The classic winner here is the use case where you have a bleeding wound and you also have the data and the access to address it. For a plant with a recent quality escape, photographed defects, and a stable inspection point, machine-vision quality is often the first project. For a plant with a well-instrumented constraint machine and years of historian data, predictive maintenance on that one machine is the first project. The discipline is to pick the one box that scores high on both axes, not the highest-impact box regardless of feasibility.

High impact, low feasibility: do this second, after you fix the feasibility gap. This is the dangerous quadrant, because it is where the highest-impact projects often sit and where enthusiasm pushes plants to start. The stamping-press predictive-maintenance project might be worth the most money and also be infeasible today because the press has no usable sensors and only three months of historian data. The right move is not to skip it, it is to sequence the feasibility fix first: instrument the press and start logging now, so that by the time the anchor project proves out, the data exists to make this the second project. Naming the gap is what turns a low-feasibility box into a planned second move instead of a failed first one.

Low impact, high feasibility: easy but not first. A use case that is easy to do but does not move a big bar is a fine confidence-builder or a fast win to keep momentum, but it should not consume the year's main budget. Beware the trap of doing the easy thing because it is easy: a slick AI dashboard that is simple to stand up but changes no decision is a vanity project, not a priority.

Low impact, low feasibility: not yet, and say so out loud. The most underrated output of the matrix is the explicit not-yet list. Naming what you are deliberately not doing, and why, is how you protect the plant from the VP who saw a lights-out factory at a trade show. AI scheduling for throughput often lands here for a brownfield plant: the OEE prize is real but the MES data is not clean enough to feed a scheduler, so the honest answer is "not yet, and here is the data work that would move it onto the list." Saying not-yet with a reason is leadership. Saying yes to everything is how the one engineer you have gets spread across four half-projects that all stall.

Knowledge capture deserves a special note because the matrix tends to misrank it. Its impact looks diffuse and deferred, which pushes it down the impact axis, while its feasibility is unusually high because it needs almost no pre-existing data. That combination puts it in the easy-but-not-urgent corner, where it gets perpetually deferred. The correction is the calendar: if Dave retires in November, the impact is not diffuse, it is a hard deadline, and once he walks out the door the feasibility drops to near zero because the source of the knowledge is gone. A retirement date converts knowledge capture from a someday project into a now-or-never one, and the matrix should be overridden by that clock.

Sequencing: Why the First Win Decides the Next Three

The matrix tells you the order, but there is a strategic reason the first project matters more than its dollar value suggests, and it changes how you weight the axes for project number one specifically. The first AI project at a plant is not really about its own ROI. It is about building the organizational muscle and the credibility to do the next three.

Think of it like the first preventive-maintenance program at a plant that has only ever done reactive repairs. The first PM you schedule is not chosen because it is the most important machine. It is chosen because it will succeed visibly and teach the crew that the program works. The same logic governs the first AI project. For project number one, weight feasibility higher than impact, because a moderate-impact project that lands cleanly, with a measured false-reject rate or a logged downtime save the plant manager can show the board, is worth far more than a high-impact project that stalls and becomes the cautionary tale everyone cites for why "AI does not work here."

A failed first project does measurable damage beyond its sunk cost. It teaches operators that the green light cannot be trusted, it teaches the plant manager that AI is hype, and it teaches the board that the budget was wasted, which means the second project, the genuinely high-impact one, never gets funded. The talent cliff makes this worse: you have one engineer who can run these projects, and if their first one fails, you have also burned your scarcest resource on a loss. With roughly 2 million manufacturing workers needing reskilling against about 500,000 unfilled roles, the people who can run plant AI are the bottleneck, and you cannot afford to spend that person on a project picked for flash over feasibility.

So the sequencing rule has two parts. First, pick a first project that is high feasibility and at least moderate impact, and resource it to actually finish, with a measured result you can put in front of the board. Second, in parallel, start the cheap feasibility work, like instrumenting the press or photographing defects, that turns a high-impact, low-feasibility box into a feasible second project. By the time the anchor proves out, the next project is ready to start instead of starting from a data desert. That parallel move is what separates a plant that does one AI project from a plant that builds an AI program.

There is one more sequencing input that overrides the matrix: a hard deadline. If a retirement, a customer mandate, a new product launch, or a reshoring ramp puts a clock on one use case, that clock can promote it ahead of a higher-scoring box. Knowledge capture before November is the canonical example. A customer requiring AI-assisted inspection documentation by a contract date is another. Deadlines are not a reason to abandon the matrix, they are a documented override you apply on top of it, and you write down why, so the board sees a reasoned exception rather than a whim.

The Deliverable and When to Revisit It

The output of this whole exercise is one page, not a slide deck, and it is the artifact your plant manager carries into the board meeting. It states, for each of the four use cases: the dollar impact off the loss chart, the feasibility score with the specific gaps named, the quadrant it lands in, and the verdict, first, second, later, or not-yet, with the reason. It also lists the parallel feasibility work that promotes the second project, and any deadline overrides. That one page replaces six weeks of hallway debate with a defensible decision, and it gives the board a reason to fund project one and a roadmap for what comes after.

Two failure modes show up when plants build this, and both are worth naming. The first is the analysis trap: spending three months scoring the matrix to four decimal places instead of running the first project. The matrix is a decision tool, not a research project, and a rough, honest scoring you can finish in a week beats a precise one that delays the anchor by a quarter. The second is treating the matrix as permanent. It is a snapshot of impact and feasibility today, and both axes move. When the anchor project lands and the team has skills, feasibility rises across the board. When you instrument the press, a low-feasibility box becomes feasible. When a new escape happens, an impact score jumps. Revisit the matrix at least annually and after every major project closes, because last year's not-yet is often this year's first.

The worked payback ties it together. Suppose the plant scores quality highest on impact (a six-figure escape last year) and high on feasibility (photographed defects, a stable inspection point), so quality is project one. The stamping-press predictive-maintenance project scores highest on impact overall but low on feasibility (no sensors, three months of data), so it is project two, with the parallel move being to instrument the press now. Throughput scores real impact but lands in not-yet because the MES data is dirty, with a named data-cleanup task that could promote it next year. Knowledge capture scores diffuse impact but gets promoted to run alongside project one because Dave retires in November and the matrix is overridden by the calendar. The plant manager walks into the board meeting with a sequence, a reason for each call, and a number behind each one. She is not guessing anymore, and neither are you.

Key Takeaways

• The four big AI use cases, quality, maintenance, throughput, and knowledge capture, are a portfolio with different risk, data needs, time-to-value, and blast radius, not interchangeable line items a VP picks by enthusiasm. Prioritize them on a matrix, not a gut call.
• Score impact in dollars off your own loss chart over the last twelve months, and respect timing: quality and maintenance pay back inside the year, throughput over one to two years, knowledge capture mostly after the expert leaves.
• Score feasibility brutally on brownfield-honest factors: labeled and accessible data, the OT/IT boundary and a 1990s PLC you can barely see (78% of OT networks lack centralized monitoring), the blast radius if it fails, and whether operators will actually accept it. One hard zero can sink a high-impact use case.
• Read the quadrants: high-impact high-feasibility is project one; high-impact low-feasibility is project two after you fix the gap; low-impact high-feasibility is a confidence-builder, not the main budget; low-impact low-feasibility goes on an explicit not-yet list with a reason.
• For project number one specifically, weight feasibility over impact. A moderate-impact project that lands cleanly with a measured result builds the muscle and credibility to fund the next three; a high-impact project that stalls becomes the cautionary tale that kills the program and burns your one scarce engineer.
• In parallel with the anchor, start the cheap feasibility work (instrument the press, photograph defects) that turns a high-impact low-feasibility box into a ready second project. That parallel move is what separates a plant doing one project from a plant building a program.
• A hard deadline overrides the matrix: a retirement date converts knowledge capture from a deferred someday into a now-or-never project, because once the expert walks out the feasibility drops to near zero. Document every override so the board sees a reason, not a whim.
• The deliverable is one page: impact, feasibility, quadrant, and verdict per use case, plus parallel work and overrides. Avoid the analysis trap of perfecting the matrix instead of running the project, and revisit it at least annually because last year's not-yet is often this year's first.