PM, data scientist, ML engineer: who does what in the AI product team?

Why hand-offs kill AI features

The anti-pattern looks the same everywhere: product writes a requirement, data science builds a model for months, engineering is meant to “just integrate it” – and context dies at every hand-off. The model optimises a metric that measures no user problem. Integration fails on latency and cost that never showed in the notebook. And the PM learns last that “done” had three different meanings.

Marty Cagan's answer to hand-off organisations applies with extra force: empowered teams that own a problem instead of exchanging work packages. For AI products that means bringing the data perspective into the team from the start – as a fourth voice in the trio, not a downstream specialist function. Whoever sits in the discovery interview doesn't later build a metric that misses the problem.

The role boundaries that work

Product manager. Owns the problem, the error tolerance and the quality threshold from the user's view – and decides the launch based on the others' evidence. The PM doesn't define the model architecture, but does define what good enough means and what an error costs.

Data scientist. Owns the feasibility evidence: eval design, experiments, model or prompt choice. Delivers no gut feelings but scores on agreed test sets – and says honestly where the quality ceiling sits.

ML / software engineer. Owns production readiness: latency, cost per request, scaling, guardrails, fallbacks, rollback. Turns a working experiment into an operable feature – and holds a veto when operating costs eat the business case.

Structurally, a hybrid has proven itself across European organisations: a central platform for shared infrastructure, evaluation tooling and compliance standards, combined with data roles embedded in product teams. The platform prevents five teams building the same logging five times; the embedding prevents the queue outside the “AI team's” door.

Domain knowledge is team infrastructure

The invisible fourth role in every AI team is domain knowledge: which business rules apply, which exceptions exist, why a decision fell the way it did in 2023. Eval sets, guardrails and prompts are only as good as this knowledge – and in most brownfield organisations it lives scattered across heads, Confluence ruins and the code itself.

That is why knowledge infrastructure is a team decision, not a documentation chore: when code, tickets and decisions are semantically searchable, each of the three roles can answer its own questions – the data scientist finds the business rule, the engineer the integration history, the PM the original rationale. The team gets faster because it waits on itself less.

Recommendations

• Answer the two launch questions in writing. Who sets the quality threshold, who decides the launch? One line per feature in the spec ends the most expensive endless loops.
• Bring data into discovery. Data scientists sit in customer interviews and problem framing – not just at model building. Feasibility is a discovery risk, not an implementation detail.
• Separate platform from product. Shared eval tooling, logging and compliance centrally; problem ownership embedded in the product team. That scales quality without the queue.
• Invest in searchable knowledge. Code, decisions and tickets as one shared semantic index – the infrastructure that speeds up all three roles at once.

Scope & caveats

• Role boundaries scale with organisation size: in a ten-person start-up one person wears two hats – what matters is that responsibilities are explicit, not that there are three positions.
• The platform-plus-embedding pattern is a practice observation from European tech organisations, not a controlled study. Test it against your team size and compliance requirements rather than copying it blindly.

Matching use cases from the library

From the article straight into practice: these use cases put the concepts to work with Teklens.