The Product Triad Is Becoming the Product Team

AI is collapsing the distance between strategy and execution, and forcing product organizations to rethink how work gets done.

The product triad was built as a decision-making unit. A product manager brought the business lens. A designer represented the user. An engineer grounded the work in technical reality. Together, they decided what was worth building and why. Execution was somebody else’s problem.

That was the operating assumption behind a generation of product organizations: a small cross-functional core set direction, and a larger team handled delivery. The triad decided. The squad executed. As products grew more complex, so did the handoffs, from research to design, from design to engineering, from strategy to implementation, from intent to what actually shipped.

AI is starting to break that model. Not because it makes cross-functional teams obsolete. And not because one “full-stack genius” can now do everyone’s job.

It matters because AI is reducing the translation cost between intent and implementation. That changes the practical size of the team required to turn an idea into working software.

The product triad was once the unit of decision-making. Increasingly, it is becoming a viable unit of execution too.

The triad was never about the number three

The “product trio” or “triad” was always more principle than prescription.

One person brought the user perspective. One brought the business perspective. One brought the technical perspective. In some contexts, that expands naturally: a researcher, data scientist, ML engineer, content strategist, or other specialist belongs in the room. Teresa Torres and others have rightly pointed out that the real point is not a sacred headcount. It is ensuring that the right mix of skills and perspectives are embedded on the team, not just to decide what to build, but to ensure it gets built well. And the boundaries between those roles matter less than many org charts suggest. A designer can think in business models. An engineer can develop a sharp eye for usability. A PM can reason about technical architecture. What matters is that the team has the right capabilities in the room and clear agreements about how decisions get made, not that each person stays neatly inside a job description.

But even when the core team was three people or five, one thing remained true: deciding what to build and actually building it were separate activities.

In most product organizations, the core team spent a significant amount of energy coordinating work across a larger delivery structure. Specs were written for people who had not participated in discovery. Designs were translated into code by people who had not been in critique. Intent was expressed, interpreted, reinterpreted, and diluted as work moved across roles and rituals.

That system has always carried a tax: meetings, backlog grooming, handoff documentation, review cycles, and the subtle degradation that happens whenever one group must infer what another group meant.

Peter Merholz and Kristin Skinner, whose book Org Design for Design Orgs shaped how companies structured design teams for a decade, have been exploring what comes next. Merholz’s 2025 research on UX and design organizational health puts a sharp point on this problem: many designers still feel good about their craft while feeling much less good about the quality of what actually makes it into production. Skinner’s ongoing work on design leadership at scale continues to address the operational infrastructure these teams need. And Merholz’s podcast with Jesse James Garrett, Finding Our Way, has become one of the more honest ongoing conversations about design leadership in this liminal moment. The issue they keep surfacing is not always talent. Often, it is translation.

That is where AI matters most. The real opportunity is not replacement. It is reach.

What changes when each role can reach further

Henrik Kniberg has described AI agents as “extremely knowledgeable interns.” That framing is useful because it avoids both hype and complacency. AI can handle a surprising amount of context-dependent, repetitive, and mechanically demanding work. It still needs direction, judgment, and correction.

That is exactly the terrain where much of product-team coordination lives.

Defining the problem is strategic. Turning that into a first-pass flow, component structure, or implementation scaffold is often mechanical. Reviewing whether the result actually serves the user and supports the business is strategic again. Writing the test cases may be mechanical. Deciding what quality means in context is not.

Once you see the workflow that way, the organizational implication becomes hard to ignore.

When a designer can move from intent to coded prototype without waiting on a full front-end queue, they cover more ground. When an engineer can explore multiple interaction patterns with AI assistance instead of building each one manually, they cover more ground. When a product manager can turn assumptions into a functional prototype or structured experiment instead of a slide deck, they cover more ground.

The roles do not collapse into sameness. Their range expands into adjacent territory.

I have seen both sides of this.

I spent seven years at Zoro building and leading a UX organization that grew to 24 people across design, research, content, and design systems in support of a marketplace with more than 14 million SKUs. I know what it takes to coordinate a large specialized organization around coherent customer experience. I also know the cost: alignment rituals, handoff documents, review layers, translation losses, and the constant work of preserving intent as it passes through many hands.

More recently, I built the brand identity, content strategy, information architecture, website, and a complex analytical application for my own consultancy as a solo practitioner using AI-augmented workflows.

I am not claiming one person replaces 24. That would be nonsense. What changed is the kind of work I could execute directly.

Tasks that once required coordination across several specialists became tasks I could carry much further myself: translating a system into coded components, expressing an information architecture in a working prototype, building visualizations that adhered to a defined style system, and iterating rapidly without losing the throughline between concept and artifact.

The bottleneck moved. It moved away from pure execution capacity and toward decision quality. And decision quality is what the triad was always meant to optimize.

The specification is becoming the primary design artifact

This is the shift I think many design and product leaders still underestimate. As AI compresses the distance between design intent and working software, the most important artifact a designer produces is no longer the mockup. It is the specification.

Not a bloated PRD. Not a vague handoff document. And not necessarily a single document at all. In practice, a specification is often a collection of artifacts — a feature brief, a design system reference, an API contract, accessibility requirements, interaction logic, decision rationale — that together provide enough context and guidance for both humans and AI systems to act on. What makes it a specification rather than a pile of documentation is that the parts are structured, explicit, and connected: human-readable and machine-optimized at the same time.

To make this concrete: a traditional design spec for a data table component might include a mockup, some redlines, and a sentence like “sortable columns with hover states.” A specification that can drive AI-assisted implementation looks very different. It names the exact component from the design system. It specifies sort behavior — multi-column? default order? null handling? It defines the loading state, the empty state, and the error state. It identifies the data contract with the API. It articulates responsive behavior at each breakpoint. And it explains why certain columns are fixed-width while others flex: because the rationale, not just the rule, is what allows AI to make reasonable decisions when the spec doesn’t cover an edge case.

That kind of artifact works in two directions at once. It aligns humans, and it instructs AI.

This is a meaningful reorientation of design craft. The traditional flow moved from research through wireframes, mockups, and prototypes to a spec that was handed off to someone else for implementation. The emerging flow starts with research, moves directly to specification, then to AI-assisted implementation, evaluation, and refined specification. The designer stays in the loop through execution, not by writing every line of code, but because the specification is a living document that evolves through contact with the working system.

That does not make visual craft irrelevant. It changes where leverage sits. The designer’s value increasingly lies in defining intent with enough clarity that the resulting system can be built, tested, and refined with less ambiguity and less translation loss.

That is one reason Erika Flowers’ Zero Vector framing resonates with me. Her argument — developed further in her NN/g podcast appearance — is that design is moving toward a more direct relationship between intent and artifact, with less intermediary friction. Figma’s recent thinking on design systems points in the same direction. Design systems are no longer just libraries of reusable parts. They are governance infrastructure: the explicit constraints that make AI-generated output coherent instead of chaotic.

The real skill gap is not prompting. It is not even coding. It is the ability to produce structured, implementable specifications and then evaluate the resulting output against the original intent.

That is a different kind of seniority than many orgs are currently screening for.

The emerging shape of the product team

I am not arguing for a lone “superhuman” product leader who does PM, design, and engineering in one body. Marty Cagan is right to push back on that fantasy. Cross-functional tension still matters. The reason product teams work is that good decisions emerge from different lenses in conversation: desirability, viability, feasibility, and, in many contexts, data, research, content, or operations.

That part does not go away.

What changes is how much of the path from decision to working output the core team can now cover before needing additional support.

In the current model, a core team sets direction and a larger squad of eight to twelve executes. Coordination cost scales with team size. Intent degrades at the boundaries. In the emerging model, a small cross-functional team sets direction and executes a meaningful portion of the work directly. AI handles more of the translation between intent and implementation. Additional specialists are pulled in where the domain truly demands them, not by default. The team stays smaller for longer without becoming one-dimensional.

That does not mean every product team should be three people. Some products will still require broader embedded expertise. A machine learning product needs different depth than a marketing site. A data platform needs different depth than a mobile commerce flow.

The point is not that there is a new magic number. The point is that the minimum coherent execution unit is getting smaller. And when that happens, organizational design has to follow.

What leaders should do now

If this shift is real, and I believe it is, then leaders should stop treating it as a tooling story and start treating it as an operating model story.

First, hiring profiles need to change. The most valuable senior people in this environment are not just deep specialists. They are people with strong judgment who can work across a wider portion of the development lifecycle. They can define intent precisely, assess generated output critically, think in systems, and preserve quality as work moves quickly.

Second, reskilling needs to become much more concrete. Teams need practice with specification-driven workflows, structured evaluation of AI output, Git-based collaboration, design-system logic, and quality review in partially generated environments. A generic workshop on prompting will not get you there.

Third, design systems need to be treated like infrastructure. If AI is going to help generate interfaces and code, then your system needs to be explicit enough to guide that output. Tokens, patterns, interaction rules, states, accessibility standards, content guidance, and implementation conventions all matter more, not less.

Fourth, leaders need to pay closer attention to new forms of risk. Smaller AI-augmented teams are not automatically better teams. They can also create overconfident generalists, elegant but untested product bets, weaker mentorship for junior talent, and hidden quality debt that does not show up until later. The coordination tax may fall, but the judgment tax rises.

That means fewer review rituals cannot mean fewer standards. It means the standards have to move upstream.

The real story is organizational design

There is a live debate here, and smart people disagree on where the equilibrium will land.

Melissa Perri, whose Escaping the Build Trap and work on product operations have shaped how companies think about scaling product organizations, has suggested that teams of around eight people working deeply together with agentic AI may outperform a team of two or three. McKinsey’s writing on the “agentic organization” points toward small human teams supervising broader networks of AI agents. Gartner predicts that by 2030, 80% of organizations will evolve large software engineering teams into smaller, AI-augmented units. Merholz keeps returning to a broader truth that I think still holds: many companies are trying to run modern product work inside operating models that were never designed for it.

That is the part I find most important. Most of the conversation about AI in product development is still framed as a productivity conversation: faster code, faster prototypes, faster content, faster tickets closed.

That framing is too narrow. The more consequential question is this: what becomes the right unit of work when intent can survive much further into execution?

My answer is that the product triad, however you adapt it for context, is no longer just the unit that decides. It is increasingly the unit that builds.

Not alone. Not always. Not universally. But much more often than our current org charts assume.

The interesting work ahead is not about adopting more AI. It is about rethinking how responsibility is distributed when smaller cross-functional teams can carry intent much farther, with fewer handoffs and less loss.

That is not primarily a technology story.

It is an organizational design story. And it is one worth exploring carefully, not because the sky is falling, but because better ways of working together may now be possible.