On an AI product team, the domain expert is not a stakeholder

The usual team for a new AI product looks like a software team with a model added: a product manager, a designer, a few engineers, perhaps someone with machine-learning experience. The people who actually do the work being automated appear as stakeholders. They are interviewed at the start, invited to the demo and asked for feedback when something looks off.

That arrangement works when a specification can describe correct behaviour. In an AI product it can only do so partly, and the working definition of a good answer lives in the heads of those stakeholders. They are not a source of requirements to be gathered once. They are the measuring instrument, and the product is calibrated against them every week.

Where their judgement is needed, every week

Choosing the cases. Which real inputs belong in the evaluation set, including the awkward ones that only someone who has done the job would think to include.

Grading. Reading outputs and calling them good, fixable or wrong — and, more usefully, saying why. An engineer can check the format. Only the expert catches the answer that is fluent, plausible and wrong.

Setting the bar. Which errors are tolerable and which are never acceptable. That is a business decision that depends on domain knowledge, and when the expert is absent it gets made by default.

Triage. When something goes wrong in use, deciding whether it is a one-off, a pattern, or a sign that the bar was set in the wrong place.

The shape that works

Infographic

Who does what on an AI product team

1. 01Outcome ownerOwns the bar and the trade-offs between quality, cost and speed.
2. 02Domain expertsDefine good, grade results, triage failures. Time set aside, not borrowed.
3. 03Evaluation ownerKeeps the cases, the scoring and the reports current and honest.
4. 04EngineeringMoves the measured level within the cost and latency targets.
5. 05OperationsWatches quality in use and turns incidents into new cases.

Five roles, not necessarily five people. In a small team one person may hold two of them; what matters is that each is held by someone who knows it is theirs.

An outcome owner, not only a backlog owner. The product manager’s job shifts from writing feature descriptions to setting the bar and arbitrating trade-offs: quality against cost, breadth against reliability. That needs authority, not just a ticket queue.

Domain experts with time set aside. Named people — often two, because one person’s judgement drifts and nobody notices — with a fixed share of their week on the product, agreed with their line manager and backfilled in their day job. Borrowed time is the first thing to disappear when their own work gets busy.

Someone who owns the evaluation. Not necessarily a new hire. Often an engineer or analyst who treats the case set, the scoring and the reporting as their product, and who is allowed to publish a number the team does not like.

Engineering measured on movement. The engineering question becomes what moved the score and at what cost, which is a more useful conversation than whether the feature is finished.

Operations in the loop. Once the product is live, the people running it turn incidents into new cases, so the evaluation keeps up with how the product is actually being used. Without that loop the evaluation set describes the product as it was on launch day.

Three failure modes to watch for

The expert becomes a bottleneck. Every grading decision waits for one person. The fix is to turn their judgement into written criteria that others can apply — or a model-based grader checked against the expert’s own grades — and to keep the expert for disagreements and new kinds of case. Written criteria have a second benefit: they can be read, challenged and corrected, which cannot be said of somebody’s instinct.

The expert becomes a rubber stamp. Shown polished examples at a weekly demo, they approve. Grading has to happen on real outputs, including the bad ones, without knowing which version produced them, or it measures politeness rather than quality.

The expert is the wrong expert. The most senior person is the easiest to name and usually the least available. They know the policy; the people who do the work every day know the exceptions, and the exceptions are where an AI product fails.

Put the hours in the plan

Expert time that is not in the plan is not in the product. A simple test is to ask the expert’s line manager what will not get done while the expert works on the product. If the answer is “nothing”, the time has not really been allocated.

In an AI transformation engagement the operating model is worked through role by role — what changes, where the new handoffs are — and the domain experts’ hours are treated the way adoption is: as budgeted work with an owner, not a favour asked of a busy department. Without them the product is measured against the team’s impression of the work rather than against the work itself.