Who you need on an AI project, and why the domain owner matters most.
A small team with a domain owner, engineers who can evaluate as well as build, and a designer for the review step beats a large team of specialists. The scarcest resource is the domain owner’s time, so plan it first.
veridive5 min read
The project plan lists eleven people: an architect, a data scientist, a prompt engineer, a machine learning engineer, two developers, a tester, a project manager and three steering committee members. The one person it doesn’t list is the head of the team whose work is about to change. Six weeks in, nobody can say what a correct answer looks like.
AI projects rarely fail for lack of specialists. They fail when nobody who owns the work has time to define good, check the answers and make the calls. A small team with a domain owner, engineers who can evaluate as well as build, and a designer for the review step does better than a large team of specialists. The scarcest resource is the owner’s time, so plan it first.
Which roles does every AI project need?
Four, on a first workflow:
| Role | Responsibilities | Relative time |
|---|---|---|
| Domain owner (your side) | Defines good, supplies cases, decides edge cases, signs off | Steady every week; heaviest at the start and during the pilot |
| Engagement lead | Owns outcomes, scope, risks and decisions with the owner | Throughout |
| Applied AI engineers | Build, integrate and evaluate | Most of the time, from build through pilot |
| Product designer | Designs the workflow and the review step with its users | Heaviest early and during the build |
Behind the owner stand a few experts from the team who write reference answers and review disagreements, in bursts. This is the shape of the pod we work in: three to five people from us, plus your domain owner.
Why is the domain owner essential?
Because an AI system is only as good as its definition of good, and only the owner can supply it. The owner decides what a correct outcome is, which errors are unacceptable and how unclear policy should be read. They will also run the workflow after launch.
That is why reference answers are written by the people who own the work, not by the builders. Builders who write the answers grade their own homework: their assumptions become the standard the system is tested against, and nobody notices until live cases disagree.
The scarcest resource on an AI project is the domain owner’s time.
Take the illustrative returns engagement on our work page: ten weeks, with a team of four. A typical pod of four is, for example, an engagement lead, two applied AI engineers and a product designer. The returns team’s side of the plan mattered just as much. Its lead walked the builders through the process in stores and the contact center in the first two weeks, while senior colleagues wrote the reference answers for the evaluation set. Through the build, the lead joined a weekly demo and answered questions in between. During the pilot, the lead reviewed disagreements with the engineers every day, and at the end took over the runbook and the monthly review. That is the pattern to plan for: heavy at the start and in the pilot, steady in between, and booked in the calendar before the project starts. Name a deputy as well: owners travel, fall ill and get promoted.
What does an applied AI engineer do differently?
They evaluate as well as build. Beyond integrations and code, they turn the owner’s cases into an evaluation set, compare models on it, design retrieval, validate structured output, instrument monitoring and explain failures by case type. Engineers who only build ship prompts nobody can defend. For the same reason, keep building and evaluating in one small team on a first workflow rather than handing prompts or tests to a separate group: the loop from a prompt change to its evaluation result should take minutes, not a ticket. The note on AI skills for software engineers covers what that takes, and our careers page describes example roles along the same lines.
Why does a product designer matter on an AI project?
Because the review step decides whether the system saves time. The designer works out what the reviewer sees first, which evidence sits next to the recommendation, how approve, edit and escalate work, and how the reason for an override gets captured. Without one, review screens get built by whoever has time, people dislike them, and they either work around the system or approve without looking.
Which roles do you need only sometimes?
- Security reviewer: at design and before go-live, including prompt-injection and data-leak tests.
- Data protection officer: at the start, when the data flow is mapped, and before live data flows.
- Integration owner in IT: from the first week whenever the system reads from or writes to a core system, because access takes longer than code.
- Legal: for contracts and ownership terms, customer-facing wording and regulated decisions.
Book them at checkpoints. Reviews that start in the final week are where good pilots stall. Two gaps show up again and again: no designer, which gives you review screens nobody likes, and no owner time, which gives you an evaluation set that never gets finished.
Who should your side staff after handover?
The domain owner stays, owning results and the regular review. A technical owner, ideally two people, can change a prompt, re-run the evaluation set and roll back, as the handover checklist describes. Champions in the team keep the routine alive. Once several workflows are live, a small central team can own the shared parts, as the note on an AI center of excellence explains.
The owner before the supplier
Before choosing a supplier or a model, name the domain owner and book their time for the whole project. If that can’t be done, the project isn’t ready. A Pilot to Production engagement runs with exactly this kind of small team around your owner.
Ask an assistant about this note