AI Talent Strategy: How Product Leaders Should Hire and Organize for AI Initiatives

A PM who can reason about probabilistic systems, set evaluation criteria, make build versus buy versus fine tune decisions, and translate model behavior into product copy. The traditional PM job (write specs, prioritize, work with engineering) does not cover any of these. AI PMs at Salesforce and Atlassian come from two backgrounds: traditional PMs who have spent six to twelve months retraining on ML fundamentals, or applied scientists who have moved into product. Both work; engineers transitioning into the role usually do not, because they default to model centric thinking rather than user centric thinking.

Tradeoff: AI PMs are hard to hire because the supply is small relative to demand. The fix is to grow them internally: identify your strongest traditional PMs, give them ownership of an AI initiative, pair them with an applied scientist mentor for six months. This is slower than hiring but produces PMs who already understand your product, customers, and data.

An engineer who can read papers, evaluate models, design fine tuning runs, and reason about training and inference tradeoffs. This is not the same as a strong backend engineer who has used the OpenAI API. The applied scientist owns model selection, prompt engineering at depth, fine tuning, and evaluation methodology. Most product teams confuse a backend engineer who can call an LLM API with an applied scientist; the difference shows up six months in when the model starts misbehaving and the team has no one who can diagnose why.

Tradeoff: Applied scientists are expensive (often higher comp than senior engineers) and scarce. The supply concentration in big labs (OpenAI, Anthropic, Google DeepMind) plus high frontier startups means most product teams cannot hire one. The fallback is to grow one from your strongest backend engineers by giving them six to twelve months of dedicated learning time and a clear charter to own model decisions.

An engineer who builds the evaluation harness, writes the eval datasets, and operates the offline and online evaluation loops. Without this role, every model change becomes a vibe check. Evaluation engineering is its own discipline; the work is closer to QA automation and data engineering than to ML modeling. Anthropic, OpenAI, and Scale AI all have dedicated evaluation engineering tracks. Most product teams treat evaluation as something the applied scientist does in their spare time, which means it does not get done.

Tradeoff: Evaluation work is unglamorous compared to model work, and engineers often do not want to specialize in it. The retention fix is to make evaluation engineering a clear career path with promotions, recognition, and dedicated leadership rather than a tax on the applied scientist role. Teams that do this end up with shipping velocity that the teams without dedicated evaluation cannot match.

Someone who owns the data pipelines that feed training, retrieval, and evaluation, plus the human annotation pipeline if you do supervised fine tuning or human feedback. The data work is often the highest leverage investment in the AI product but the least visible. Scale AI, Snorkel, and Surge built businesses on the assumption that most teams underinvest in this role. If your retrieval is bad, your model cannot recover; if your evaluation set is unrepresentative, your offline numbers lie.

Tradeoff: Data engineering and annotation management cross organizational boundaries (engineering, ops, sometimes legal). The role often does not have a clean home and gets distributed across teams, which means no one owns it end to end. Fix this by giving the data role explicit accountability for data quality metrics that the rest of the team can see, even if the role reports through engineering or operations rather than directly to the AI PM.

A designer who can design for probabilistic and conversational interfaces, including failure states, confidence indicators, undo flows, and escalation paths. Traditional product designers are trained for deterministic UI; AI designers need to handle the case where the same input produces different outputs, where the model is wrong 5 to 20 percent of the time, and where the user needs to repair model errors quickly. Linear, Notion, and Arc all hired or grew specialized AI designers and the difference shows in their AI feature quality.

Tradeoff: AI design is a young discipline and there are few designers with strong portfolios. The grow path is to take your strongest interaction designers and give them an AI feature to own end to end, including error states. Specifically resist the temptation to ship AI features without thinking through failure UX; that is where 60 percent of user trust is won or lost.

Each product team has at least one applied scientist and an AI specialized PM embedded inside it. The team owns its model decisions, evaluation, and fine tuning end to end. This works for companies where AI is core to multiple distinct products with different model needs (Anthropic Claude product teams, OpenAI ChatGPT and API teams). Embedding maximizes velocity per team and avoids the bottleneck of a central platform team.

Tradeoff: Embedded shapes duplicate work: every team builds its own evaluation harness, its own retrieval stack, its own monitoring. With ten teams the duplication wastes 30 to 40 percent of AI engineering capacity. Mitigate by mandating shared infrastructure once you have more than three embedded teams, even at the cost of some autonomy.

A central AI platform team owns the models, evaluation, retrieval, and tooling. Product teams consume the platform via APIs and do not staff their own AI talent. This works for companies in early AI adoption where the talent supply is thin and consolidation is necessary (most enterprise SaaS in 2023 to 2024 used this shape). Salesforce Einstein and Atlassian Intelligence both started this way.

Tradeoff: Central shapes create a bottleneck: every product team is queued behind the central team. Shipping velocity per surface drops. The central team also drifts away from product context because they are not embedded in any product. Solve by limiting the central team scope to truly shared infrastructure (model gateway, evaluation framework, monitoring) and pushing product specific work back to embedded talent inside the product team.

A small central platform team owns shared infrastructure (model gateway, evaluation tooling, foundation model contracts). Each product team also has at least one AI PM and one applied scientist embedded who builds on the central platform. This is the shape that most large AI native companies converge to after 18 to 24 months. Salesforce, Atlassian, and Notion all run versions of federated. It captures most of the leverage of central with most of the velocity of embedded.

Tradeoff: Federated shapes require strong interface design between central and embedded. If the central team builds the wrong abstractions, embedded teams route around the platform and you end up with the duplication of pure embedded plus the overhead of central. Mitigate by treating embedded teams as the customers of the central team and running quarterly customer satisfaction reviews.