The Product Trio Is Dissolving. Here's What's Replacing It
AI isn't just changing how teams work, it's changing who needs to be on the team at all.
I used to spend a lot of time thinking about how to get product managers, designers, and engineers to work better together. How to eliminate handoffs. How to get engineers into customer interviews earlier. How to make PMs think more technically. I wrote articles about it, coached teams on it, and watched organizations spend enormous energy on it.
I’m spending a lot less time on those questions now - not because I solved them, but because I’m increasingly convinced we’ve been optimizing for a model that’s being quickly replaced underneath us.
The product trio - PM, designer, engineer - was one of the defining organizational ideas of the last decade. And it was excellent. It pushed product development away from sequential, siloed handoffs and toward something that actually looked like collaboration. Teams that adopted it shipped better products faster. Most of the successful tech companies adopted it or have already been using it.
But the trio was built on a specific assumption: that the expertise required to build a great product was distributed across different people, and the core problem of product development was a coordination problem. Get the right people in the room. Get them talking. Get them working in parallel instead of sequence. That was the job.
AI is collapsing that assumption. And if you’re leading a product team today without fully reckoning with what that means, you’re probably already behind.
The Assumption That’s Breaking
Think about what each person in the trio historically owned.
The PM owned the what and why- user research, market context, prioritization, the product narrative. The designer owned the experience - visual hierarchy, interaction patterns, the translation of user needs into something tangible. The engineer owned the how - architecture, implementation, the technical judgment that turned designs into working systems.
These were real, distinct skills. And for a long time, there was no practical way to collapse them. A PM who wanted to test an idea had to sketch it, hand it to a designer, wait for mockups, hand those to an engineer, and wait again. That chain existed because each step required expertise the others genuinely didn’t have.
Now a PM with access to the right AI tools can have a working prototype in an afternoon. An engineer can generate a product spec that rivals what a PM would have spent a week writing. A designer can run a first-pass usability analysis before the team has even aligned on the problem. The walls between “what you know” and “what you can do” are coming down fast.
This doesn’t mean expertise doesn’t matter anymore - it does, deeply. But the *minimum viable expertise* required to move from idea to implementation, to complete each step in the chain, is dropping dramatically. And that changes everything about how you should be thinking about team structure.
Smaller Teams, Bigger Scope
The clearest signal isn’t coming from large companies adjusting their org charts. It’s coming from small ones moving fast.
Linear shipped a product that made Jira feel like legacy software with a team that would have been considered recklessly small five years ago. Midjourney built one of the most widely-used AI products in the world with fewer than 15 people. Perplexity was handling hundreds of millions of queries a month before it hit 50 employees. These aren’t outliers - they’re early signals of a structural shift in what a product team actually needs to look like.
What’s interesting about these companies isn’t just the headcount. It’s that traditional role boundaries inside them are blurry in a way that would have been functionally impossible before AI tooling matured. Engineers make product calls. PMs prototype directly. Everyone is closer to the customer than the old model allowed. Not because they’ve cracked some culture secret, but because AI has lowered the barrier to cross-disciplinary contribution enough that enforcing strict role separation would just be friction.
The larger companies are catching up more slowly, but it’s happening. When I talk to product leaders at growth-stage companies now, a consistent theme comes up: they’re getting more output from smaller, tighter teams than they were getting from larger, more structured ones two or three years ago. The fastest-moving teams are the ones where the PM is close enough to the product to prototype with AI tools, and the engineers feel empowered to challenge the direction — not just implement it.
The most significant signal for large companies, though, isn’t coming from startups at all. It’s coming from Jack Dorsey.
In a piece he co-wrote with Sequoia’s Roelof Botha earlier this year, Dorsey laid out what Block is actually doing - not adding AI tools to an existing structure, not retooling the product trio, but replacing the fundamental logic of how the organization coordinates. His argument is direct: corporate hierarchy was invented as an information routing protocol, a way to move context up and decisions down when humans were the only mechanism capable of doing that job. AI can now carry that context. So the layers that existed to route it can go.
At Block, that means collapsing to three roles - individual contributors who build, Directly Responsible Individuals who own outcomes, and player-coaches who develop people while staying close to the work - with no permanent management layer in between. The coordination that used to require managers flows instead through what they call a “company world model”: an AI system that maintains continuous context across the organization so that everyone at the edge can act without waiting for information to travel up and down a chain.
This is a different category of change than anything most product leaders are contemplating. It’s not about improving the trio or making teams more integrated. It’s about questioning whether the hierarchy itself - the thing the trio lives inside - is the right structure at all.
What makes it more than a thought experiment is that Dorsey is running it, not consulting on it. That distinction matters. The structural changes that AI makes possible at this scale generate real friction - roles being redefined, processes rebuilt, leadership instincts that were calibrated for a different world. Companies that mandate this kind of change from the top without leaders personally absorbing its consequences will stall. The reason Block has a genuine shot at making it work is that the person making the case is also the one living with the disruption.
If you’re leading a large organization and thinking about AI primarily as a productivity layer on top of your existing structure, that’s a reasonable starting point. But it’s worth being honest about whether it’s also a way of deferring the harder question - which is whether the structure itself is what needs to change.
What This Actually Means for Each Role
Let’s be direct about what’s changing for each person in the trio, because the impact isn’t the same across the board.
For product managers, the coordination and translation work — which has historically consumed a significant portion of the job — is increasingly being absorbed. Writing requirements documents, managing handoffs, synthesizing research into summaries, preparing roadmap decks: AI handles a meaningful chunk of this today, and it’ll handle more of it next year. What’s left is the work that genuinely requires judgment: knowing which problems are worth solving, making calls under real uncertainty, understanding users in ways that data alone can’t capture. PMs who’ve built their value around process and documentation are going to feel the pressure first. PMs who’ve always been closer to the product itself, who have strong opinions and make decisions - are going to have more leverage than ever.
For designers, the shift is more nuanced. Generative tools are fast, but the output is generic in ways that experienced designers recognize immediately. What AI is genuinely good at - generating variants, handling production assets, first-pass accessibility checks, rapid iteration on low-fidelity concepts — frees up designers to work on the harder problems: the interaction logic, the emotional coherence of an experience, the consistency of a design system at scale. The risk for designers isn’t replacement. It’s becoming irrelevant by staying in the territory AI can already cover, rather than pushing into the territory it can’t.
For engineers, the leverage is extraordinary and the pressure is real at the same time. An engineer with solid AI tooling can write, test, and ship code dramatically faster than three years ago. But that acceleration is available to everyone, which means the bar for what a small team can accomplish has risen significantly. Engineers who are also genuinely product-minded, who can evaluate their own output against user needs, not just technical specs, are becoming meaningfully more valuable than those who implement faithfully but wait to be told what to build.
The New Team Topology
So what does the team actually look like now?
I’d stop thinking about the trio and start thinking about what I call the core + leverage model. The core is smaller than you think you need — often one or two people who own the full problem space, have enough technical fluency to work directly with AI tools, and care enough about the outcome to make judgment calls without a committee. Around that core, you have access to specialist leverage: a great designer’s instincts when the experience needs to be right, a senior engineer’s architectural judgment on decisions that will compound for years, a researcher’s framework for talking to users in a way that surfaces real insight rather than surface feedback.
The key shift is that you don’t need those specialists involved in every step of every feature anymore. You need them at the leverage points — the decisions that actually matter and can’t be approximated by a good prompt. What you’re designing for is a small, high-judgment core that moves fast, with deliberate access to deep expertise when the stakes are high enough to warrant it.
If you’re staffing product teams today the same way you would have in 2021, you’re probably over-indexed on coordination roles and under-indexed on the high-judgment work that AI genuinely cannot do.
What To Do If You’re Running a Traditional Team Right Now
Most people reading this aren’t building a team from scratch. They’re managing an existing one, with people whose job descriptions were written for a world that’s changing faster than the org chart is. Here’s what I’d actually focus on.
Start by auditing where the time goes. Before you change anything structural, spend two weeks honestly tracking where your team’s hours are going. My guess is you’ll find a significant portion in work that AI could handle today — meeting documentation, requirements translation, variant creation, stakeholder communication prep. That’s not a criticism of anyone; it’s just what the job used to require. Once you see it clearly, you can make deliberate choices about where to redeploy that time toward higher-judgment work.
Give your team proper AI tooling and get out of the way. This sounds obvious but most teams aren’t actually doing it in any structured way. Give your PM access to tools that let them prototype and synthesize research directly. Give your engineers access to AI-assisted development environments. Give your designer access to generative tools for the work that doesn’t need human craft. Then watch what happens to both velocity and the shape of what people are working on. Let the learning drive the conversation about structure, rather than mandating structure before anyone has the context to make good decisions.
Identify your highest-judgment people and protect their time. In every team, there are two or three people whose product instincts or technical judgment are genuinely hard to replicate and impossible to prompt your way to. In the old model, those people were often spending a disproportionate amount of their time on coordination work — meetings, alignment, documentation, because that’s what the model required. As AI absorbs more of that overhead, the opportunity is to redirect those people toward the decisions that actually compound. That’s the highest-leverage structural move you can make right now, before you touch anything else on the org chart.
Be honest about what your collaboration rituals are covering for. In some teams, the product trio model, the three-amigos sessions, the extensive design reviews, the multi-stakeholder sign-offs - is doing real work. In others, it’s covering for the fact that no single person understands the problem well enough to make a confident decision, so you spread the uncertainty across a committee and call it alignment. AI doesn’t fix that problem. If anything, it exposes it faster, because you can now move from idea to prototype in hours and the bottleneck becomes immediately obvious. The teams that benefit most from AI-augmented work are the ones where someone actually owns the problem deeply enough to evaluate output with genuine judgment.
The Part That’s Uncomfortable to Say
The product trio model was a genuine improvement over what came before it. The push toward integration and collaboration was right, and a lot of the principles behind it - shared ownership, outcome focus, blurring role boundaries, still hold. I’m not arguing against any of that.
What I am arguing is that the *structure* designed to achieve those principles is becoming less necessary. You don’t need three specialists in the room to cover the expertise gap when one person with good tools and good judgment can traverse most of it themselves. The goal was always speed, coherence, and user value. The trio was the vehicle for achieving that in a world where expertise was hard to share. AI is changing what the vehicle needs to look like.
The organizations that recognize this early, not by panicking and cutting headcount, but by deliberately redesigning how teams are structured around the new reality, are going to move at a pace that makes the traditional trio model look slow. Which, compared to what’s possible now, it kind of is.
---
What does your team topology look like right now, and where are you feeling the most pressure to change it? I’d love to hear what’s actually working, and what isn’t.