Why I'd Bet On Product-Led Now
Same team, same agent. Eighteen months ago this took committees. Today it took a day. The difference wasn't the agent.
Last time I said the willingness to tailor was what I'd protect most. Now AI is here, and that's the test of it.
The teams pulling away aren't applying a template. They're tailoring agentic capability to the specific shape of their product. The teams that stall are the ones treating AI as another deliverable to schedule across twenty stakeholders.
Take the developer enablement platform team I work with. They've fully embraced agentic, and it isn't bolted onto the side of their product, it's the backbone. They can adapt, test, and roll out patches to the toolset at speed, with product-specific instructions tailored to whoever is consuming the platform. The agent knows who is using what version, for what purpose, and which edge cases matter. The team commits to a change, a cutoff, an estimate, and the rest happens.
Rewind eighteen months. Same team, same brief, no product-led model. They'd have spent days and hours in meetings trying to identify which teams were even using the module. Then coordinating with up to twenty separate dev and ops teams, plus release management, plus change management, trying to land on a deadline. Then supporting every one of those teams through the change so they could fit it into their schedule. Decisions by committee. Weeks of overhead before a single line of code moved.
The contrast isn't subtle and it isn't theoretical. Same people, same capability, same problem space. The difference is the operating model underneath them, and the agent built into the product they own.
Product-led is to agentic what data governance is to AI
I think about it like data and AI. If you don't have your data governance and data quality standards defined, your benefit from AI is minimal. You'll get something, but the upside is capped, and what you do get needs constant validation because the inputs are noisy.
Operating model is the same shape of problem one level up. If you don't organise around the product, set the purpose, set the boundaries, hold the team in place, your benefit from agentic is minimal. You can sprinkle agents over project teams and you'll release a bit of knowledge here and there. But you'll need people to validate everything, because the agent doesn't see end to end. It can't. There's no end-to-end to see.
A product-led team has a future. That's what the agent needs to do its job properly. It needs to see the theme behind the requests, what we're working towards long term, so it can organise the product for what it will be, not what it is in this point in time. That forward shape is what gives the agent traction. Without it, the agent is a clever search engine. With it, the agent is a participant in the product's direction.
Can I skip the operating model bit?
The tempting shortcut is to apply agents to the existing project structure and hope for the best. It's a small step, and it nets a small return. Some knowledge gets released, some friction gets eased, but you'll still need humans to validate everything because the agent has no continuous context to lean on. You haven't changed the system. You've added a productivity tool to a system that wasn't designed for one.
There's a more interesting alternative for organisations that genuinely cannot, or will not, restructure right now. You build a dedicated context agent per business unit. The context agent learns, watches, and over time it captures the hidden governance the org never wrote down. All the markets, all the edge cases, all the unspoken rules. Once the context agent has seen the territory, opening it up via A2A starts to look genuinely best-in-class. And if you ever do decide to formalise governance after that, the work is mostly done. The knowledge is already mapped.
It's a real option. But it's harder to set up, and it's a different bet. You're saying you'll retrofit understanding into a structure that doesn't naturally produce it. That can work. It's just expensive, the timeline is longer, and you're hoping the context agent stays ahead of the entropy of the org around it.
Where the multiplier varies
Not every product-led team will get the same multiplier. The dev enablement example is a clean one. The consumers are other dev teams, the dataset is versions and dependencies and telemetry, the boundaries are crisp.
Business-facing products run into a harder dataset, one with ego and emotion and politics in it. The benefit is still there. The agent has more to navigate, and the work to get it there is heavier.
Same model, different shapes. Same principle, applied with judgement to the actual work. The model bends to the work, the way it always does. AI doesn't change that. AI is the test of it.
Where this leaves you
Doing nothing isn't an option. The teams that already have the operating model right are pulling away, not by a little, by an order of magnitude on speed and adaptability.
Where you start depends on your maturity. Restructure to product-led if you're ready to. Retrofit a context agent per business unit if you're not. Sprinkle agents on project teams if you want a small uplift while you decide. Each is a real choice. None of them is doing nothing. And the choice itself is a maturity diagnostic.
The end goal should be product-led. Everything else is either a path toward it, or a delay before it. AI doesn't punish you for the structure you have. It rewards you, hugely, for the structure you actually need.
More to come in this series.