A field guide for whoever just got handed the job of building an AI and data capability from scratch — what to settle before the first workshop, how to pick the work, and how to hand the whole thing over.
Somebody upstairs decided the company needs an AI program, and now it's your job. There's a budget, a rough mandate, and a board that expects something to show inside a year. This is the path we walk with clients in that position, and the places where it usually goes wrong.
The path holds up across industries. A plant, a logistics network, a utility, a bank — what changes is where the money sits, which data fights hardest, and what the culture pushes back on. The order of the work stays the same.
The program is the work that makes money: the demand forecast, the maintenance predictor, the document copilot, the fraud model. The office is the team, the platform, and the rules that deliver that work and keep it running.
Most failed efforts picked one. All use cases and no office gets you a drawer of demos with nobody to run them in production. All office and no use cases gets you a large team, a platform bill, and nothing in the P&L when the CFO comes asking. You need the program because it pays for everything, and you need the office because someone has to still be there in year three.
Two questions go to the CEO first, and you need the answers said out loud, because everyone in the room is currently assuming a different one.
What kind of bet is this? Cutting cost, growing revenue, and catching a competitor who moved first are three different programs — different use cases, different pace, different appetite for risk. Pick one on purpose.
And where does the office report? It reads like an org-chart detail. It decides whether you're still around in eighteen months. The value sits in the business, so the office has to sit near the business. Park it inside IT and it will ship clever work that nobody asked for and nobody adopts.
Spend the first six to eight weeks finding out where the company actually makes and loses money, what data exists and what shape it's in, and who is already quietly good at this — most companies have a few analysts who've been building models nobody upstairs knows about. Find them before you hire around them.
Then take the idea list. There's always an idea list; some workshop produced forty of them. Score each one on value and feasibility, and feasibility includes the question everyone skips: will the person whose job this touches actually open the thing. Scored honestly, most of the list falls away.
What survives, you sequence. A few quick wins first, because you'll be asked what you've done long before the big bets pay off. One or two lighthouse projects that are the reason the program exists. The regulated, hairy ones wait until the foundations can carry them.
Every use case walks the same four steps: map the process and the data underneath it, frame the problem and pick the technique, build to a business KPI, and run it in production.
The step that decides success isn't on the diagram, though. It's adoption. A churn model the retention team ignores is worth nothing, and they will ignore it if it shows up as a new portal with its own login. Put the output inside the tools people already open every morning. Sit with them while they use it. Expect the workflow around it to change, and budget more effort for that than for the model.
Then measure. Baseline before you ship, measure after, and get finance to sign the number. A number finance signed gets wave two funded. A number the data team calculated for itself convinces nobody but the data team.
The first deployment is always hand-made. The mistake is hand-making the next twelve. Shared pipelines, templates, a platform sized to what's actually shipping — the tenth rollout should take a few weeks, not another quarter, and it shouldn't depend on your best engineer being free that month.
The other half of scaling is change management across dozens of teams at once. It's the half that decides whether scaling works, so budget for it like it's the main event.
From day one, the office is being built to run without whoever built it. The sequence is deliberate: we run the first use case while your people watch. We run the second one together. You run the third and we review. Somewhere around there, the program stops being an engagement and starts being a department.
The test at the end is what happens when you stop watching. If value keeps landing, you built a capability. If it stalls, you built a dependency.
Bring us where you're stuck — a mandate, a stalled pilot, or the whole build. We'll tell you where we'd start.