There is a talk circulating right now that does the best job I've seen of describing how organizations should reorganize themselves around AI agents. It comes from an AWS executive named Stephen Brozovich, and its structure is clean: four questions every leader now has to answer, in order — economics, talent, structure, governance — built on roughly a hundred executive conversations and a stack of recent research. If you lead engineering or run a CIO's organization, watch it. The diagnosis is sharp and the prescriptions are concrete.
It also never once says the word "product." Across the entire framework — every pillar, every slide, every Monday-morning action item — product management does not appear. And for a PM, that absence is worth sitting with, because product is load-bearing in all four pillars. It's just never named.
I want to be careful here, because the easy version of this argument is a strawman. AWS, as an organization, has plainly not forgotten product. Its own published playbook for operationalizing agentic AI names "product owners" as first-class members of the cross-functional pods it calls AgentOps teams, lists "product managers" among the roles that need dedicated enablement, and builds its success metrics around decision quality rather than task completion — a decision-first mindset that is, in everything but name, a product mandate. And Amazon's entire cultural operating system starts with Working Backwards: writing the customer press release before a line of code. Product isn't a blind spot for AWS. It's protected doctrine.
Which makes the talk's silence more interesting, not less. A framework distilled from a hundred executive conversations, delivered by the same company whose written guidance treats product as a protected role, still managed to compress product out of the picture when it got to the whiteboard. That's the pattern worth examining: not that anyone believes product doesn't matter, but that product is the thing that keeps getting absorbed into "engineering" and "domain expertise" the moment someone draws the org chart. What follows is the same four questions, read from the one seat the talk doesn't draw — even though AWS's own documents insist the seat exists.
Economics Is a Product Decision Wearing an Infrastructure Costume
The economics pillar is the strongest part of the framework, and it's framed entirely as a build-versus-buy question. Every workflow lives in one of three worlds: use a managed solution, compose frontier APIs into your context, or build and fine-tune your own models. The advice is to let economics and real differentiation decide which world each workflow belongs to, and to evolve as you learn. The cautionary tale is the leader who declares "we're a build shop" on day one and burns the company training models before understanding its own workflows.
Read that again with a product hat on. "Let real differentiation decide" is not an infrastructure instruction. It's a product strategy. Someone has to know which workflows actually differentiate the business from its competitors — which ones customers will pay for, which ones are table stakes, which ones are pure cost. That someone is not the platform team, and it is not the model. It's whoever owns the answer to "what are we actually for." The use/compose/build decision is a portfolio decision dressed up as a procurement decision, and the failure mode the talk warns about — building before you understand your workflows — is precisely what happens when nobody with product authority is in the room when the economics get decided.
The talk says the durable moats aren't the things that are hard to do — workflow embeddedness, software scale, integration lock-in — but the things that are hard to get: proprietary data, network effects, regulatory permission, capital, physical infrastructure. True. But notice that knowing which of your moats is which, and steering investment toward the durable ones, is the most product-strategic judgment a company makes. The economics pillar is a product question with the product manager edited out of the diagram.
"Domain Expertise Plus AI" Is the Job Description for a PM
The talent pillar is where the omission gets almost funny. The argument is that the valuable person is no longer the fastest builder but the fastest orchestrator — someone who can point an agent at a problem, evaluate the output, steer the next iteration, and know when to overrule. The talk leans on Martin Fowler's "expert generalist" and Werner Vogels' "Renaissance Developer," and lands on a thesis it states outright: domain expertise plus AI beats coding skill alone.
The proof offered is a hackathon. The top three finishers in Anthropic's flagship developer competition were not professional developers. First place was a lawyer who built a permitting tool. Third was a cardiologist who built a patient-care platform between rounds. They beat thirteen thousand people, many of whom had been coding for years, because they understood a problem domain deeply and AI closed the gap to implementation.
Here is the sentence the talk doesn't finish: deep domain expertise about a customer and their problem, paired with the judgment to decide what's worth building, is what a product manager is supposed to be. The cardiologist and the lawyer didn't win on engineering. They won on product sense — they knew which problem mattered, what "good" looked like for a real user, and where to stop. The talk celebrates this and then, in the very next breath, defines the new team as "two or three expert generalists plus agents" without ever asking whether one of those generalists is doing product work. It describes the most valuable person in the building as someone "who understands your customer, your regulation, your product nuance — the things AI can't compress," and files them under "senior engineer."
That's not wrong so much as incomplete. The orchestrator who decides what to build, evaluates whether the output is right, and knows when to overrule is making product decisions continuously. Calling that role "engineering" because it touches code is the same category error that has always made product invisible inside engineering-led orgs. AI didn't fix that error. It raised the stakes on it.
When Handoffs Disappear, the PM Doesn't
The structure pillar is the one that should make every PM sit up. The old team is a line of specialists, each owning a lane, with handoffs between them and coordination overhead everywhere. The new team is a pod — three to five senior people who each own a workflow end to end, with agents filling the execution gaps. And the explicit promise of the pod is that the coordination overhead collapses and the handoffs disappear.
For two decades, the default product manager was a handoff node. Requirements came in, got translated into specs, and went over the wall to engineering. If the new structure is built specifically to eliminate handoffs and the framework is openly hostile to coordination overhead, then the version of product management that consists of writing tickets and shuttling them between functions doesn't survive contact with this model. That role isn't threatened by AI. It's threatened by an org design that was built to delete exactly that kind of work.
But there are two ways product can land inside a pod, and the difference is everything. In the first, product collapses into a residual coordination layer — the person who schedules the meeting, maintains the backlog, and chases status — which is precisely the overhead the pod exists to remove. In the second, product becomes the embedded judgment about what the pod points its agents at and why, fused into one of those senior generalists or sitting beside them as the customer-and-outcome owner. The first version gets optimized away. The second becomes the most leveraged seat in the room. The talk's own logic forces the choice and then walks right past it.
And then it hands product the bottleneck without noticing. Among the four forces the talk says leaders must hold in tension is the one it labels "the bottleneck shifts: decisions, not execution." The constraint is no longer whether you can build it. It's whether you know what to build and whether the data exists. That is the entire thesis of When Execution Becomes Abundant: make execution cheap and the constraint doesn't vanish, it migrates — and it migrates almost entirely to product. The talk states this force in a single line and moves on. It is, for a product audience, the most important line in the talk, and it's treated as a footnote to a structure slide.
The Riverbank Is an Outcome, and Outcomes Belong to Product
The governance pillar contains the framework's best metaphor. Stop trying to control how an agent works, the talk says; you can't dictate the route any more than you can put a tollgate in the middle of a river. Your job is to define the riverbank — the outcome the agent must stay inside — and let the water find its way. Be tolerant of variance in execution, and strict about variance in outcome.
This is presented as a CIO's mental-model shift, and it is one. But "define the outcome and hold the line on it" is not a security instruction or an infrastructure instruction. It's the definition of product management done well. The hardest, most valuable, least automatable thing a product org does is specify what the outcome has to be — clearly enough that an autonomous system can be measured against it — and then defend that definition against drift. The riverbank is a product artifact. The talk builds an elegant governance model on top of outcome-definition and never asks who, in the new org, is actually good at defining outcomes.
It also, almost in passing, makes a point that should worry every product leader. The governance framework it praises — Singapore's — is singled out partly because it explicitly addresses the deskilling trap: organizations have to show they're keeping their people's core skills alive as agents absorb routine work. The talk applies this to engineers. It applies just as hard to PMs. If agents start drafting the requirements, writing the acceptance criteria, and generating the first-pass roadmap, the routine reps that used to build product judgment quietly disappear — and the comprehension gap the talk warns about for junior developers opens just as wide for junior PMs.
Who Writes Your Senior PMs in 2034?
Which brings us to the part of the talk I think about most, and the part that translates most directly to product without any reinterpretation at all. The talk's central org-design image is the hourglass. Most companies, it argues, are racing toward a diamond — cutting their juniors, bloating the middle with "agent managers," and starving the talent pipeline — because reducing junior headcount is the fastest way to hit the ROI targets boards are demanding from AI investments. The hourglass is the alternative: a senior-heavy execution layer, a lean middle, and a deliberately preserved base of juniors learning the craft on the way up.
The argument for keeping the base is unanswerable. Judgment only exists because someone spent years doing the execution and learning from the mistakes. Absorb the entire execution layer into agents and skip that apprenticeship, and you don't have a talent-pipeline problem in 2034 — you have an expertise-pipeline problem, and expertise takes a generation to rebuild. The talk quotes AWS's CEO: you absolutely want to keep hiring kids out of college, because in ten years you'll have nobody who has learned anything.
Every word of that applies to product, and product is more exposed, not less — because product never had a clean apprenticeship to begin with. The way people become senior PMs is by making a hundred small calls on real products, watching half of them be wrong, and developing the pattern-recognition that nobody can teach in a deck. If AI absorbs the entry-level product work — the ticket-writing, the criteria-drafting, the competitive teardowns — the path that produces senior product judgment gets quietly cut at the same moment that senior product judgment becomes the scarcest and most valuable thing in the building. The diamond is coming for product orgs too, and it will arrive disguised as efficiency.
The Honest Caveat
So let me hold both things at once, because the fair version of this matters. AWS has not forgotten product — its written guidance protects the role explicitly, as I said at the top. The talk is aimed at engineering and CIO leadership, and the absence of product in it is far more likely scope than blindness: you can't cover everything in thirty-one minutes, and "go fix your product org" is a different keynote. The very traits the framework prizes — customer understanding, domain depth, knowing what's worth building — are product traits, and the speaker clearly values them. The gap isn't belief. It's that even here, even from a company with product in its doctrine, the function dissolved into "senior engineers" and "domain experts" the moment the org chart got drawn. If product can vanish from the picture under those conditions, it can vanish from yours, where the doctrine may not be written down at all.
But that's exactly the gap this whole project exists to close. The framework assumes a product capability it never specifies: someone deciding which workflows differentiate, someone defining outcomes precisely enough to govern autonomous systems against them, someone holding the line on what gets built when execution is no longer the constraint, and an organization deliberate enough to keep growing the product judgment it will be entirely dependent on a decade from now. The harness is the per-project version of that capability — structured requirements, steering documents as durable context, outcomes made explicit and machine-readable. The product backplane is the org-level version. They are the columns the operating model is leaning on without drawing.
The companies that treat the agentic shift as an engineering-infrastructure problem and let product adapt reactively will get a beautifully reorganized engineering org feeding on an unreliable supply of product direction — faster at building the wrong thing, at higher volume, before anyone notices. The framework is right that the winners won't be the ones with the best AI. They'll be the ones with the best operating model around it. It just forgot to mention that the operating model has a product shape, and that the orgs which name it now are the ones that will still have the judgment to run it in 2034.