That growing backlog looks like a problem. It's the opposite: it's the sign the system is working. The real question is who works the backlog down, and the answer is more surprising than the backlog itself.
Why does the backlog grow after the first AI project?
Because the first win teaches people what's possible, and they apply it to problems you didn't know about. Before the first project, nobody asks "could this be automated?" about their daily friction: the manual report, the data trapped in the old system, the process held together by one person's spreadsheet. The friction is just how things are.
The first visible win changes the question everyone is asking. Suddenly the purchasing manager wants a live view the legacy ERP could never produce. The service lead wants tech notes captured and searchable. Sales wants warranty expirations surfaced before the customer goes elsewhere for the contract. None of that was on the original project list, because leadership couldn't see friction that the people inside each process see daily.
Who builds all of this: do you need to hire a team?
No, and that's the part that surprises everyone: your own domain experts do the building, often faster than developers. At one manufacturer, the head of manufacturing (engineering background, not a software one) took to the tools and started building working applications himself, including a scheduling system. The CTO's honest observation: he'd watched non-developers at his company build apps more quickly than the developers, some of whom were still hesitant about the technology.
The barrier was never coding ability. It was access to the data, and to a foundation that handles the hard parts. Given both, the person who actually understands the product, the process, and the customer turns out to be the right person to shape the tool. The expensive alternative, a dedicated AI specialist at well over $200,000 a year, buys you someone who knows models but not your machines.
What makes domain experts effective builders?
They skip the most expensive step in software: explaining the problem to someone who doesn't live it. A developer building a scheduling tool needs weeks of requirements conversations to learn what the head of manufacturing already knows: which constraints are real, which exceptions matter, what the floor will actually use. The domain expert building on a governed foundation goes straight from problem to tool.
"Governed foundation" is doing real work in that sentence. This isn't everyone freelancing scripts against production data. The platform handles access control, data connections, and guardrails; the expert composes on top. The capability spreads, the chaos doesn't.
How do you run the backlog without it running you?
Sequence by provability, and keep score in public. The backlog will always exceed capacity; that's its nature now. Pick next projects the way you picked the first: countable before-state, measurable after, owner who wants it. Publish the wins as they land. Each one recruits the next department's ideas and the next reluctant builder.
And resist the urge to declare the program "done." The manufacturers getting compounding value treat the growing backlog as the operating rhythm, not a phase. One fix becomes a pipeline; the pipeline becomes how the company improves itself, with the expertise staying inside your own walls instead of renting it.