Most manufacturing AI pilots that stall do not fail on the technology. They stall because the people who have to use them were not in the room when the thing was designed.
Surveys disagree on how many pilots never reach production. Depending on who is counting, the number runs from well over half to more than 80%. Whatever the exact figure, the pattern is familiar: a proof of concept works in isolation, then sits there. The dashboards go unread. The automation needs four workarounds to fit the existing workflow. The system solves a problem nobody on the floor had.
Software teams rarely see this coming because they do not talk to operators until the system is already built.
Why Operators Decide Whether Your Software Ships
Executives want transparency. They want dashboards and AI agents that flag problems early. That is sensible, and it does not matter if the people running the shop do not use the result.
Picture a production manager who needs to know whether she will miss a delivery date next Tuesday. She needs that answer in the next two hours so she can call the customer. She does not need a historical trend chart or a model that explains last month. She needs “on track” or “off track” on her phone, in plain language.
If the system answers the executive’s question and not hers, she will go back to the spreadsheet, the email chain, or the Post-it note on the wall.
The Shadow Run Method: How Software Actually Gets Adopted
Before anything goes to production, run it alongside the existing system for a full operational cycle. This is a shadow run. The new system processes the same transactions and produces the same reports, but nobody acts on its output yet. You watch.
Operators see the system inside their real workflow and tell you where it breaks. Not in a demo. On a Tuesday morning with three urgent orders, a machine down, and someone out sick. That is when you find out what the system has to do.
They also get to check its answers against what they already know. Trust comes from catching the system being right a few times before they depend on it. And you learn who picks it up fast and who is bracing for it to break their day. Both reactions are useful. The skeptics tell you what the training and support need to cover.
Shadow runs often last two to four weeks, depending on how long a full cycle takes in your plant. The existing system stays the source of truth, so the risk is low. The cost is real, though: operators are now doing the work twice, and they are doing it on top of a full day. If you do not plan for that, the shadow run gets quietly dropped in week two.
Co-Creation: The Difference Between Adoption and Resentment
Shadow runs test whether the system holds up. Co-creation decides what gets built in the first place.
The usual project goes like this: developers or consultants work out what the business “needs,” disappear for three months, come back with a system, and train people on it. Then adoption stalls because it does not match how people work.
In co-creation, operators are in the room during discovery and design, not in a focus group afterward. You ask the production lead what would make her day easier, then build that.
People tend to defend software they helped shape. A feature an operator argued for is a feature she will use, even if the interface is plainer than something a vendor would demo.
It takes discipline. The temptation is to solve the problem alone and show operators the finished product. Co-creation means shipping something rough and iterating on real feedback. It means turning down requests that sound good but miss the constraint you are solving for. It also has a limit: your best operators are usually the busiest people in the plant, and pulling them into design sessions has a cost you will feel in that week’s output. I do not have a clean answer for how much time is the right amount.
Why Most Projects Skip This
The most common version is bringing operators in at the very end: “We have spent six months building this, please give us feedback.” That is theater, and operators can tell.
Projects skip operator involvement because it feels slower. You sit with the problem longer and ask harder questions before writing code. That delays the first deployment. Whether it saves time overall depends on how often you would otherwise build the wrong thing, which is a bet, not a guarantee.
Shadow runs push go-live back too. You could deploy tomorrow. Without operator validation, though, the deployment is code running in production while people keep using the old system.
Start With One Operator Constraint
Systems built for executive reporting tend to make sense in a slide deck and miss the friction on the floor. The alternative is to find one operator’s real constraint and solve that.
Maybe quality checks take an hour and she needs a decision in five minutes. Maybe the run order lives in email. Maybe she spends 30 minutes every morning reading data to work out what went wrong yesterday.
If you have a pilot running now, ask one operator what she would stop doing if it worked. If she cannot answer, or the answer has nothing to do with what the pilot does, start there.