What "empowered teams" actually means when AI does half the work
Marty Cagan's concept of empowered product teams has been the north star for product organizations for years now. Give a team a problem to solve, not a feature to build. Trust them with the outcome. Let them figure out the solution.
I still believe in this model. But I think we need to have an honest conversation about what happens to it when AI starts doing a significant portion of the actual work.
The tension nobody is naming
Here's the thing that's been nagging at me. Empowered teams are built on the idea that the people closest to the problem are best positioned to solve it. The product trio (PM, designer, engineer) brings together complementary perspectives, and the magic happens when they collaborate directly with customers and with each other.
AI changes the shape of that collaboration. When an engineer can generate boilerplate code in minutes, when a designer can produce mockups from a text description, when a PM can synthesize hundreds of customer conversations overnight, the nature of each role shifts. The question isn't whether AI replaces these roles. It doesn't. The question is what these roles become when the execution floor drops out from under them.
I've been talking to PMs at companies that have aggressively adopted AI tooling, and a pattern keeps emerging. The teams that were already empowered are getting more empowered. The teams that were feature factories are becoming faster feature factories. AI is an amplifier, not a transformation.
This is worth sitting with for a moment. If your team was already good at discovery, strategy, and customer understanding, AI gives you more time for those things by handling the grunt work. But if your team was already stuck in a delivery-focused culture, AI just makes the delivery faster without fixing the underlying problem. The gap between good product teams and bad ones is widening, and AI is the wedge.
What changes about the product trio
PMs shift toward more strategic work, not less. When AI can synthesize data faster, the PM's value moves toward asking better questions and making harder judgment calls. You spend less time processing information and more time deciding what to do with it. This sounds like an upgrade, and in some ways it is. But it also means PMs who relied on information gathering as their primary contribution are exposed. If your main value was knowing what customers are saying because you read all the tickets, AI just made that table stakes.
Designers move up the abstraction ladder. When AI can generate UI variations quickly, the designer's job shifts toward systems thinking. What's the right interaction pattern? What principles should guide the design system? How should the experience feel at a conceptual level? The craft of pixel-pushing matters less. Understanding human behavior matters more.
Engineers focus on architecture and judgment. When AI handles routine coding, engineers spend more time on hard problems: system design, performance, reliability, and deciding which AI-generated code is actually good. The engineer's judgment becomes more important, not less. There's more code to evaluate and more risk of subtle errors in production.
The shift for all three roles is the same direction: away from production and toward judgment. The roles aren't shrinking. The definition of "the hard part" is changing.
The new collaboration dynamics
Something interesting happens when everyone on the team can prototype faster. The feedback loops tighten. A PM can describe a concept, a designer can mock it up in an hour, an engineer can have a working prototype by end of day, and the team can test it with users the next morning.
That sounds great, and it can be. But it also creates new problems.
Speed can kill discovery. When you can build things fast, the temptation to skip the "should we build this?" question gets stronger. I've seen teams ship three experiments in a week and learn nothing because they didn't set up proper success criteria before they started. Velocity without direction is just expensive wandering.
There's also the "just try it" trap. AI makes it cheap to build things, which makes it tempting to build instead of think. Sometimes "let's just try it and see" is the right call, but when it becomes the default, you stop doing the hard work of understanding the problem space. You end up with inconclusive experiments and no clear product direction.
Another risk is decision fatigue. When the team can generate more options faster, someone still needs to decide which option to pursue. Without clear strategy and success criteria, more options just means more arguments.
And there's a subtler issue I've noticed: the erosion of shared understanding. When an engineer spends two weeks building a feature, they develop a deep understanding of the problem through the act of building. When AI builds it in an afternoon, the engineer might ship something that works without fully understanding why it works or what edge cases matter. The same applies to designers who use AI-generated mockups without going through the thinking process that would have surfaced usability issues.
The accelerated product cycle with AI looks like this:
What empowerment looks like now
The definition of an empowered team needs updating for the AI era. The original concept still holds: give teams problems, not solutions. But the operating model needs to evolve.
Empowered teams need stronger product strategy. When teams can move faster, the cost of moving in the wrong direction goes up. A clear product strategy that everyone understands and can reference when making decisions becomes critical. This is Melissa Perri's point about the product operating model, and it's become even more relevant as execution speed increases.
They also need better success metrics. If your team can ship three experiments a week, you need clear metrics to evaluate them. Otherwise you're just generating activity. Outcome orientation isn't optional anymore -- it's the only way to keep pace with the speed AI enables.
Empowered teams need higher-quality people. This is the uncomfortable truth: when AI handles routine execution, the bar for human contribution goes up. You need PMs who can think strategically, not just organize backlogs. Designers who understand behavior, not just tools. Engineers who can evaluate code quality, not just write it. The "empowered team" model always assumed you had strong people. Now it demands it.
Finally, empowered teams need new working agreements. When an AI tool generates something that's 80% right, who reviews it? Who's accountable for the quality? These questions don't have standard answers yet, and each team needs to figure out their own. The best teams have explicit agreements about when AI output gets used directly and when it needs human review.
A practical framework
If you're leading a team trying to figure this out, here's a starting framework.
First, audit where your team spends time today. Categorize activities into "judgment work" (decisions, strategy, customer understanding) and "execution work" (building, documenting, analyzing). AI will accelerate the execution work. Your job is to make sure the time saved gets redirected toward judgment work, not just toward shipping more features. I've seen teams do this audit and discover they spend 70% of their time on execution. The question then becomes: if AI cuts that to 40%, does the other 30% go to judgment work or to more execution? The answer determines whether you become a better team or just a faster one.
Second, strengthen your strategy and success criteria before you accelerate your execution. It doesn't help to build faster if you're building the wrong things. Spend the first few weeks getting clear on outcomes before you optimize for speed. This is counterintuitive because AI tooling makes you want to move immediately. Resist that urge. Two weeks of strategic clarity will save you a quarter of wasted velocity.
Third, invest in your team's judgment skills. Run more design reviews, more customer interviews, more strategy discussions. These are the skills that matter most in an AI-augmented team, and they atrophy if you don't exercise them. I'd specifically recommend increasing the frequency of customer contact. The teams I've seen navigate AI adoption best are the ones that doubled their customer interview cadence because they suddenly had more time for it.
Fourth, set up explicit quality gates for AI-generated work. Not because AI output is bad, but because unchecked output of any kind leads to accumulated technical and design debt. Someone needs to own quality, and "the AI did it" isn't an acceptable answer when something breaks. I recommend treating AI output the same way you'd treat a contribution from a prolific but junior contractor: it might be good, it might be subtly wrong, and it always needs review.
Fifth, redefine what "done" means. In a pre-AI world, "done" often meant "shipped." In an AI-augmented world, shipping is cheap. "Done" should mean "we shipped, measured, learned, and either validated our hypothesis or updated our approach." This is the difference between a team that's fast and a team that's effective.
Team rituals that maintain empowerment
AI tooling has a way of quietly eroding the rituals that make empowered teams work. When things move faster, teams tend to drop the "slow" practices -- design reviews, customer debriefs, strategy discussions -- in favor of more building. This is a mistake. Here are the rituals I've seen maintain empowerment as teams adopt AI.
Weekly problem framing, not just sprint planning. Dedicate the first thirty minutes of your weekly planning to the question "Are we solving the right problem?" Before you plan what to build, confirm why you're building it. In a pre-AI world, this felt like a luxury because building was expensive. Now that building is cheap, this is the most valuable thirty minutes of your week.
Fortnightly "show the thinking" sessions. Every two weeks, one person on the team presents not what they built, but how they thought about a problem. Walk through the decision process: what options did you consider, what trade-offs did you make, why did you choose this approach? This keeps judgment skills sharp and creates a shared understanding of how the team makes decisions.
Monthly customer immersion. Once a month, the entire team (not just the PM) spends a half-day with customers. Watch them use the product. Listen to their frustrations. Ask them about their workflow. This is the practice that keeps "empowered" from becoming "detached." AI can synthesize customer data, but it can't give your engineer the visceral experience of watching a user struggle with something they built.
Quarterly strategy reset. At the start of each quarter, step back from execution entirely. Review your outcome metrics, revisit your strategy, and ask whether the team's direction still makes sense. This is especially important in an AI-augmented environment because the speed of execution can create an illusion of progress. You might be shipping more than ever and still going nowhere.
Daily "why are we doing this?" check. This one sounds small, but it's the most important. Before the team starts work each day, take five minutes to connect today's work back to the outcome you're pursuing. "Today we're building X because we believe it will move Y metric because of Z assumption." If nobody can complete that sentence, you've drifted into execution mode.
The leadership question
Ultimately, whether AI helps or hurts your empowered team depends on leadership. Leaders who see AI as a way to get more features shipped faster will create faster feature factories. Leaders who see AI as a way to give teams more time for discovery, strategy, and judgment will create genuinely empowered teams.
The technology is neutral. The organizational choices around it are not.
I keep coming back to something Cagan has said in different ways over the years: the difference between good product companies and bad ones isn't the tools they use. It's whether they've actually embraced a product operating model or just bolted product titles onto a project management culture.
AI doesn't change that diagnosis. It just makes the consequences of getting it wrong more visible, and more expensive, faster.
This article is part of a series on product management in an AI-transformed landscape.