Designing an AI-Native Product Team

Introducing a new person or role into a team can be a bit like a transplant: the organ only takes if the body around it adapts to accept it. Drop something into a system that isn’t ready for it, and it gets rejected.

We’re creating the same tension with the rise of AI in our teams. The question for leaders now is: how do we deliberately design and rebuild product teams to accept, adapt to, and leverage the new capabilities AI is offering?

We want to be upfront that this is new territory. Nobody has the settled playbook for designing an AI-native product team yet, including our team. What follows is a way I’ve found to reason about it so far, and what I think it changes about how a team runs day to day, because that’s the bit too many of these pieces (mine included, in an earlier draft) leave conceptual.

It’s also worth being honest about where most of us are right now. For all the talk of agents, what most teams have deployed in mid-2026 is still copilots and drafting assistants. They’re tools that wait for us. This piece is about designing for where that’s heading: agents that act within bounds we set. That future is here, and the teams that design for it deliberately will adapt faster than the ones that are swept up in the changes it brings.

The line we never crossed

Every tech shift before AI changed how we work. The spreadsheet automated the calculation, but we still decided what to model. The IDE sped up the build, but we still had to decide what to build. The tool waited for us at every fork in the road.

The AI era is the first where the tool stops waiting at the fork and steps onto the road.

According to Andrew Ng,

Agentic AI is a focus on building systems with varying degrees of agency and autonomous workflows. It’s a shift from single-response prompts to software that uses large language models to plan multi-step processes, execute them iteratively, and improve outputs through reflection and tool use.

Given the go-ahead, an agent takes some of the turns itself, goal-directed, within the bounds we set. We can set it free and enable the agent to take over the decision-making. Or the turns it takes are ones we’ve handed it, on a road we’ve mapped, with the consequential calls still ours. It’s acting where only we used to act, and that’s the line earlier shifts never crossed. The spreadsheet never entered the decision space; it waited for our number. The agent moves around inside that space, which means that, for the first time, we have to draw a line we never had to draw before: which calls we hand over, and which stay ours.

AI agents as team members?

So, should we think of these AI agents as team members or as tools?

Anthropic’s Alex Albert has described working with AI

as less like using a tool and more like managing a team, a persistent collaborator you direct and delegate to, rather than a chatbot you open and close.

Not everyone buys it.

When I put this to Kendra Vant, whose view I rate, she pushed back on the team-member framing. You care for team members, she argued; you take an interest in their lives. AI, for her, is a genuinely useful tool, but not something she cares for the way she cares for a person.

Both can be right, because they’re answering different questions. Whether you regard an agent as a colleague or a tool is partly a matter of temperament. But whichever camp you sit in, the agent is now acting where only people used to act. That’s why the capability question can’t be answered the old way. We have to understand the new and enhanced product capabilities AI brings, no matter what we choose to call it.

Why “just add AI” keeps underperforming

It isn’t just intuition that says bolting AI onto the existing team doesn’t work. Deloitte’s 2026 Global Human Capital Trends research, released in March, backs it up.

Most organisations (59% of them) are still taking a tech-focused approach: layering AI onto legacy roles and workflows rather than redesigning how humans and AI make decisions together. And it shows up in the return on investment. Deloitte found organisations are roughly twice as likely to exceed their AI ROI expectations when they deliberately redesign the human-AI interaction rather than just deploy the tool. One European telco example makes the point starkly: adding an AI agent to customer service without changing roles or workflow produced a modest 5% productivity lift. Redirecting most of the rollout budget into redesigning the human-AI interaction — new workflows, trust thresholds, escalation paths, training — took that to a 30% lift.

The gap between intention and capability is just as stark. 66% of leaders in the same study say designing human-AI interaction deliberately matters to their organisation’s success. Only 6% say they’re leading in it. The ones who are, led by a wide margin, are more likely to report better financial results, and twice as likely to say the work stays meaningful for their people.

That gap is exactly the gap this piece is trying to close for product teams specifically. Deloitte’s frame splits the work into:

1. Hardwiring — the formal stuff such as redesigned roles, decision rights, escalation protocols.
2. Softwiring — the trust, culture, and leadership behaviour that let people use those protocols with confidence.

What follows is my attempt at the hardwiring for a product team: the frameworks, the interface, and the role redesign that give a team something concrete to softwire around.

AI-native product team design

When designing an AI-native product team, you need to consider the product operating model across several layers:

1. The capability layer — what skills and behaviours do team members need to do their job, and at what level?
2. The governance layer — what are the internal and external guardrails we need to adhere to?
3. Ways of working — how do we practically work individually and as a team, day to day?
4. Team structure — how do different capabilities and experiences overlap and support each other, so the sum is greater than the individual parts?

These four layers aren’t independent. They stack, and they lean on each other: the structure you build depends on the capabilities you have, the way you work depends on the guardrails you’ve set, and all of it rests on the capability layer underneath. That’s why I start there (AI or no AI). This piece stays close to that foundation and the interface that sits on top of it, but keeps the other layers in view, because a capability you can’t govern isn’t really a capability you have.

A fair thing to highlight here: most product organisations don’t yet run a laddered capability framework even for their humans. They have job titles and a rough sense of seniority. If that’s you, the human half isn’t a step you skip on the way to the AI part. I think it’s the prerequisite, and a deliberate place to start.

At the heart sits the capability layer. Think of it as the body’s core system: everything else depends on it functioning well. Getting it right builds a solid foundation for identifying the human capabilities we need to execute our product strategy and realise our product vision. Without that foundation, the whole thing becomes a house of cards, toppling the moment we try to add or remove a capability.

A capability framework is how we make that foundation concrete. It defines the capabilities the team needs to do their job and quantifies the level at which each person can perform them, or guide others to perform them. Rather than describing roles abstractly, it anchors the conversation in demonstrable behaviour, not what someone knows, but what they can be seen to do, and how well.

The new challenge is that we now must account for a different kind of collaborator in our workflow. How do we describe the capabilities of an AI agent? How do we manage its governance and accountability?

A dual capability model

If the capability layer is the foundation, it now has to carry two frameworks rather than one: a capability framework for humans, and one for the machines.

These aren’t quite the same thing, and the difference is in what we measure.

1. Human capability is about behaviours: what someone can demonstrably do.
2. Machine functionality is about autonomy: how much we let an agent decide for itself, and within what limits.

A dual capability model holds the two in parallel and lets us update each independently, which gives us more flexibility when something needs to change on either side.

The two also move at different speeds. A person’s capabilities grow steadily, on a timescale we can plan around. An agent can shift the moment the model underneath it changes, in either direction, which means the machine framework doesn’t last as long. It must be revisited more often than the human framework ever demanded.

Which raises a fair question: if it churns every time the model underneath it shifts, is it a framework at all, or operational configuration wearing a framework’s clothes? Closer to the latter, and that’s fine. The point of holding it in the same structure as the human framework isn’t that the two are the same kind of thing. They share one job: making a capability explicit enough that you can govern it. The human side stays still long enough to plan around. The machine side is a living config you maintain. Treating maintenance as the cost of entry, rather than a surprise, is part of designing the thing more concretely.

So how do you build one? The answer is the same for both frameworks: start with strategy, not structure.

Building the two frameworks

For the human capability framework, start broadly with the portfolio strategy and the team’s objectives. That clarifies the activities needed to deliver the strategy. From there, define the capabilities the work requires, using laddered proficiency levels rather than tying them directly to specific roles. Make sure each proficiency descriptor reflects a demonstrable action, not just knowledge, because knowledge alone can’t be verified. We measure people by what they can be seen to do.

Here, for example, is the Human Capability framework for Vision & Strategy. Different skills, each measured at four proficiency levels.

For the machine capability, or functionality, start the same way: with your product and people strategy and what AI needs to accomplish across the product management and development lifecycle. From there, define the capabilities you want agents to cover. But where the human framework ladders by proficiency, the machine framework ladders by autonomy. We should articulate and document how far an agent is permitted to act on its own, the thresholds at which it must hand back to a human, and the error tolerances we’ll accept before it does. We don’t measure an agent by what it knows. We measure it by how much we trust it to decide, and where that trust runs out.

That trust must be earned the way we’d earn it for anything we rely on: by evidence. Where we measure people by demonstrable action, we measure agents by demonstrable reliability, through evaluation, observability, and a track record under real conditions. Where teams have the means to evaluate this rigorously, that’s the bar; most are still building toward it. But none of that monitoring is even possible without the framework. You can’t catch an agent drifting past a boundary you never defined, or know it’s overstepped its autonomy if you never set the level. The machine capability framework is what makes the agent observable in the first place. It turns “the agent did something we didn’t expect” into “the agent crossed a line we can name.” Setting the bound is the start. Holding the agent to it is the ongoing discipline, and the framework is what makes that discipline possible at all.

Here is the Machine Functionality framework for the same domain. Notice that Option & Scenario Generation carries a ceiling at Level 3.

A hybrid operating interface

Each framework feeds into what I call a hybrid operating interface. It’s the layer where human and AI work meet.

This is where the capability frameworks turn into something real. On the human side, capabilities become the role profiles that define the work people own. On the machine side, they become the processes and autonomy rules the agents operate within.

But the work of the interface is neither of those. It’s the orchestration layer: who drafts and who decides, what an agent does on its own and where it hands back, the point at which a recommendation stops being the machine’s work and becomes a human’s call. The frameworks describe the two parties separately. The interface is where we choreograph them into one working team.

Here’s the problem, though: the two frameworks measure different things. What a person can do, and what an agent is permitted to do. Because of that, they don’t snap together cleanly. The seams between them are where the hard problems lie: a handoff that fires too late, an agent that acts at the edge of its bounds while the human assumes it hasn’t, a decision that falls in the gap because each side thought the other owned it. The interface isn’t where the two frameworks meet neatly. It’s where we do the work of making two different kinds of things operate as one, and most of that work is in the joints.

Say we’ve capped an agent’s Option and Scenario Generation capability (see the framework above) at a mid-tier autonomy level. In the interface, that cap stops being a line in a table and becomes choreography. The agent generates the options and risk-weights them, because that’s its job and it does it well and at speed. Then it hands the choice to a named human role, because choosing between strategic options is an accountability call, and we’ve decided accountability stays human. That’s a choice, not a law of nature. Organisations may let it leak into “the system” or “the model,” and under enough cost pressure, accountability erodes quietly. But we must hold it deliberately, because someone must own the consequence of a decision, and ownership isn’t a thing you can hand to something that can’t be held to account. The agent does the work that scales. The person makes the decision and owns its consequences. That single handoff, designed deliberately, is the interface doing its job.

This is the accountability and governance layer doing its work, even though we rarely call it that. Every line we draw in the machine framework is a governance decision. The interface is just where those decisions stop being abstract and start binding real workflows. Governance in an AI-native team isn’t a committee that meets quarterly. It’s the running set of answers to one question, asked capability by capability: what is this agent allowed to do without us, and how would we know if it did more? Those answers are ours to choose.

What changes in practice

An early reader of this paper flagged, fairly, that this can all read as conceptual. It’s an interesting architecture, but what changes on a Tuesday? So let me be concrete. Four things shift, and they shift in this order.

Decision velocity changes shape, not just speed.

The instinct is to assume AI makes everything faster. It doesn’t, uniformly. It makes the drafting and option-generation stages faster and leaves the decision stage exactly as slow as the judgement behind it deserves to be. A team that hasn’t drawn its autonomy lines tends to feel this as false urgency: options arrive so quickly that the pressure to decide fast arrives with them, even though the decision itself hasn’t gotten any easier. Naming the capability this situation generates is what stops speed at the drafting stage from bleeding into pressure at the decision stage.

Role boundaries move from implicit to written down.

Before any of this, most product people carry an unwritten sense of “this is mine to decide, that’s not.” That sense was tacit and mostly fine, because nothing was fast enough or persistent enough to test it. An agent is both. So the boundary must be written down: which capabilities this role owns outright, which it directs an agent within, and where the named handback sits. This is uncomfortable the first time you do it, because it forces you to admit how much of your seniority lived in judgement calls you’d never had to defend out loud. That discomfort is the point. This is the same discomfort Deloitte’s research points to when it talks about roles needing explicit redesign rather than a tool bolted onto an unchanged job description.

Discovery loops compress on the research side and stay the same length on the sense-making side.

Agents are good at pulling together comparable products, summarising interview transcripts, and drafting the first cut of a problem statement. They are not good at deciding which problem is worth solving, or noticing the thing three customers said in passing that matters more than the thing twenty said directly. Teams that don’t distinguish the two stages end up either over-trusting the agent’s synthesis or under-using its speed. The practical implication is a discovery cadence with an explicit seam in it: agent-assisted research feeding a human sense-making session that takes the same amount of calendar time it always did.

Ownership consolidates around fewer, clearer names.

When work was slower, ownership could be a little diffuse. A few people “across” a decision was fine, because there was time to sort out who called it if it mattered. At agent speed, diffuse ownership is where the seam problems Deloitte describes as hidden costs surface: the decision nobody remembers agreeing to, the escalation that fires to the wrong desk. The fix isn’t more process. It’s naming the human role that the handback goes to. Committees don’t hold an autonomy boundary. Named people do.

None of these four are new to us. They’re the same four things good product leadership was already trying to get right: pace, accountability, insight over activity, clear ownership. What’s new is that a slow drift in any of them used to be recoverable. At agent speed, it isn’t; the gap shows up as an agent doing something nobody signed off on, weeks before anyone would have caught it the old way.

How roles are changing

There’s a worry that sits underneath all of this. If agents take goal-directed action and make some of the calls, what’s left for the product person to do?

The opposite of what you’d expect. The role doesn’t and can’t shrink. It sharpens, and gives us the opportunity to do what we are truly meant to do as product people.

Here’s why. To set an agent’s bounds, you must know exactly where judgement lives in your own work. You can’t cap a capability until you understand what makes the next level up a decision rather than a task. You can’t tell an agent to generate options but hand back the choice until you can say, precisely, why choosing is different from generating. Writing the rubric forces you to articulate the judgement you’ve always exercised, but mostly exercised tacitly, in the moment, without ever having to name it.

I believe that’s the real shift. The strategic work was always there, often crowded out by delivery, but there. What’s new is that it now must be made explicit and deliberate, because a vague sense of good judgement can’t be encoded as a boundary. The machine demands you get specific about the thing that was always your edge.

So the product role in an AI-native team isn’t a diminished version of the one we had. It’s a more concentrated one. We spend less time operating the tools and more time deciding where judgement belongs, which is, when you strip it back, what product management was always supposed to be.

A fair objection here: sharper work for whoever remains says nothing about how many remain, and I’m not going to pretend otherwise. The work that survives is the work that was always the point, and it’s more concentrated than before. Whether a team needs the same number of people to do it is a separate question, and it depends on the team. What I will say is that the people who can name where judgement lives in their work are the ones this shift makes more valuable, not less.

Designing for it

You can see the shape of all this most clearly when it’s absent. A team adopts the agents, skips the partition, and lets each person decide, case by case, what to hand over. For a while, it looks faster. Then an agent makes a call nobody realises was a call until it goes wrong, and there’s no line to point to, because nobody drew one. The work was never to stop the agent from acting. It was to decide, in advance and formally, where its acting ends. Teams that skip that step don’t avoid the boundary. They just find out where it was after they’ve crossed it.

So this was never about adding AI to the team we already had. A new kind of collaborator, one we can permit to act within a space that used to be ours alone, doesn’t and can’t slot into the old structure any more than a transplanted organ slots into a body that hasn’t been prepared for it. The team itself has to be designed differently: two capability frameworks instead of one, an interface that choreographs how they work together, a set of practical changes to how decisions, roles, discovery, and ownership actually run, and a product role concentrated around the judgement that can’t be delegated.

That’s what an AI-native product team is. Not our team with agents bolted on, but a new organism, built deliberately, from the capability layer up.

Want to put this into practice? Checklist: Designing an AI-Native Product Team walks through the same framework step by step.

Sources: Deloitte, “Getting human and machine relationships right,” 2026 Global Human Capital Trends, March 2026.