"The old model was PM writes spec, designer designs screen, engineer builds feature. The new model is all three explore the AI solution space together, learning what is possible and what is valuable."
Product Lead at a Series B SaaS Company
New Collaboration Patterns for AI
AI products break the traditional handoff model. In deterministic software, PMs can fully specify requirements before design begins, and designers can fully design before engineering implements. AI products require tighter collaboration because the capability space is not fully specifiable in advance.
Discovery Phase Collaboration
Chapter 10 introduced collaborative discovery for AI features. This is not a luxury for AI products; it is a necessity. The AI capability space is too uncertain to specify upfront. Teams must explore together.
AI products break the traditional handoff model. In deterministic software, PMs can fully specify requirements before design begins, and designers can fully design before engineering implements. AI products require tighter collaboration because the capability space is not fully specifiable in advance. Chapter 10 introduced collaborative discovery for AI features, and this is not a luxury for AI products; it is a necessity since the AI capability space is too uncertain to specify upfront and teams must explore together. During discovery, PM contributes user needs, success metrics, constraints, and prioritization framework. Designer contributes user mental models, interaction patterns, UX principles, and feedback mechanisms. Engineer contributes technical possibilities, model capabilities, performance constraints, and integration requirements.
Eval-Driven Development
Chapter 21 established evaluation as the core discipline for AI development. This creates a new shared language for PM, Design, and Engineering conversations.
When eval is central, the collaboration dynamic changes. Instead of PM specifying requirements and judging implementation success, all three disciplines contribute to defining what "good" looks like and measuring whether the AI achieves it.
Eval as Collaboration Infrastructure
Eval frameworks serve as collaboration infrastructure because they create shared, objective reference points. When a team shares eval scores and example outputs, debates shift from subjective opinions to shared evidence. This reduces friction and accelerates alignment.
Shared Metrics for AI Quality
Traditional products have clear success metrics that each discipline can contribute to: conversion rates, engagement, revenue, NPS. AI products add a layer of metrics that require all three disciplines to understand and own.
Eval Metric Ownership
Who owns AI quality metrics depends on the metric type. Understanding ownership clarifies accountability and collaboration patterns.
AI Metric Ownership Matrix
Who owns AI quality metrics depends on the metric type, and understanding ownership clarifies accountability and collaboration patterns. Task completion rate is primarily owned by PM with Design and Engineering as contributors. AI accuracy/precision is primarily owned by Engineering with PM contributing on thresholds and Design contributing on error categorization. User satisfaction for AI is primarily owned by Design with PM and Engineering as contributors. Response latency is primarily owned by Engineering with PM contributing on thresholds and Design contributing on loading UX. False positive rate is primarily owned by PM with Engineering contributing on measurement and Design contributing on user override patterns.
Collaboration Ceremonies for AI Teams
Traditional teams have established ceremonies: sprint planning, design reviews, engineering standups. AI teams need additional ceremonies that bridge disciplines.
Eval Review
A regular meeting where the team reviews AI performance data, examines low-scoring examples, and identifies improvement opportunities. All three disciplines participate with different lenses. PM asks whether low-performing cases are high-impact user scenarios and what thresholds should be cared about. Design asks whether failures are explainable to users and whether better error messaging or override mechanisms are needed. Engineering asks whether root causes can be identified and whether there are quick improvements or if this requires model work.
AI Spec Review
Before building AI features, all three disciplines review the AI specification: what the AI should do, how it should behave, what the evaluation criteria are, and how the UX will present AI outputs and failures.
Example Exploration Session
A structured session where the team reviews real examples of AI inputs and outputs. The goal is shared understanding of AI behavior, not task completion. These sessions often reveal surprising AI behaviors and surface assumptions different disciplines held.
Cross-Functional Retrospectives
After AI feature launches, retrospectives that include all three disciplines surface insights that discipline-specific retrospectives miss.
After AI feature launches, retrospectives that include all three disciplines surface insights that discipline-specific retrospectives miss. PM insights include whether the eval criteria matched user needs and whether success metrics were appropriate. Design insights include whether users understood AI behavior and whether error states were handled well. Engineering insights include what deployment taught and what they would change about the eval approach.
AI Team Org Chart Templates
Different organizational contexts call for different structures. These templates provide starting points for common scenarios.
Early Stage: Single AI Feature Team
Early Stage AI Team Structure
AI Feature Team
├── Product Manager (AI-familiar)
├── Designer (UX for AI)
├── ML Engineer (embedded in team)
└── Engineer (full-stack, AI-aware)
Shared Services (from platform if available):
- Model deployment
- Eval framework
- Data infrastructure
Growing: Multiple AI Features
Growing AI Team Structure
Product Area Teams (2-3 AI features each)
├── AI PM
├── AI Designer
├── ML Engineer
└── 2-3 Engineers
AI Platform Team (shared infrastructure)
├── ML Engineers (2-3)
└── MLOps Engineer
AI Center of Excellence (optional)
├── AI Leaders (1-2)
└── Training/Enablement
Enterprise: Full AI Organization
Enterprise AI Organization
Chief AI Officer
├── AI Platform Division
│ ├── Infrastructure Team
│ ├── Evaluation Team
│ └── Data Platform Team
├── AI Product Division
│ ├── AI Product Team A
│ ├── AI Product Team B
│ └── AI Product Team C
├── AI Research Division (optional)
└── AI Governance & CoE
├── Responsible AI
├── AI Training
└── AI Strategy
Connecting to Chapter 29
This section focused on team collaboration within a single AI product team. Chapter 29, "Building the AI Product Organization," expands to the organizational level: how to structure the broader organization, how to think about AI career paths, and how to hire AI talent.
The team topologies described here scale up to organizational topologies. Stream-aligned teams become business unit AI teams. Platform teams become shared services divisions. CoE functions become enterprise-wide capability centers.