Why product managers are a bottleneck and how product ops can fix it

Engineering teams using Cursor and Claude Code are shipping code in hours that used to take days. Meanwhile, product managers (PMs) are still spending a week and a half on a product brief – hunting through Confluence, Slack, Zendesk, and Gong, trying to assemble enough context to make a decision.

That's the strange inversion happening inside product organizations right now. And if you haven't felt it yet, you will soon.

The "how-to-build" function has been fundamentally compressed by AI. The "what to build" function hasn't. And that gap is widening every quarter.

The PM is now the bottleneck

It's not just the information hunt slowing things down. A huge chunk of a PM's week goes into aligning stakeholders on strategy – leadership, then sales, then marketing, then back to the exec team because priorities shifted.

Each conversation starts from a slightly different version of the truth, so the PM ends up as a human synchronization layer, manually reconciling what different parts of the organization believe the strategy actually is.

That work easily eats half the week. And none of it shows up as output.

So you get engineers asking "what's next?" more often than PMs can answer. You get PMs spending more time in alignment meetings than in customer conversations. If your PMs are the slowest part of the system, your whole organization moves at their pace.

This is the bottleneck. And it's not going away on its own.

What AI slop looks like in a product org

The failure mode I see most often? A product brief lands on a leader's desk that reads beautifully but says nothing.

Well-structured, grammatically perfect, all the right sections – and completely generic. It could be a spec for any product at any company. The PM used AI to generate something that sounds like a great brief but isn't grounded in actual customer pain, strategic priorities, product understanding, or competitive reality. It's confident, polished, and hollow.

The deeper failure: the product manager applied no judgment. They followed the process, just faster. They took a workflow that used to take a week and compressed it into an afternoon, but didn't use any of the time they saved to think harder.

AI is incredible for pressure-testing assumptions, surfacing the counter-argument you hadn't considered, going three layers deeper into a customer problem than you'd normally have time for. None of that happened. The PM used the most powerful thinking tool we've ever had as a typing accelerator.

That's AI slop in a product org. And it's a leadership signal that your PMs aren't being challenged to think, rather they're being rewarded for producing.

Agents without context are just expensive autocomplete

Here's the clearest way I can put it: strip the context away from a frontier model, and you're just paying for a very fluent guesser.

Let’s say you’ve got a product manager who asks an agent to draft a brief for a new feature. The agent has no access to the company's strategy doc, no customer feedback from Zendesk and Gong, no past decisions about similar features, and no view of what's already on the roadmap.

What comes back is structurally fine but says things like "users want a more intuitive experience" and "this will drive engagement." It's not wrong, exactly. It's just useless. It could apply to any product, anywhere.

That's expensive autocomplete. You're paying for compute and PM time, and you get a confident-sounding document with no real signal in it.

The fix isn't better models, it's better context.

From process enforcer to context architect

Most product ops teams today spend their energy making sure people follow the right steps. Did the PM use the template? Get the right approvals? Update the roadmap tool? It's enforcement work. Important, but it's overhead.

The shift I'm seeing in the best product ops teams is this: instead of enforcing how humans coordinate, they're designing what information AI agents have access to, so coordination happens automatically.

They're curating the strategy docs, customer feedback, past decisions, and competitive landscape – making sure everything is current, structured, and findable. Then agents connect that context for PMs the moment they need it, instead of PMs spending hours hunting it down.

That's the move from process enforcer to context architect. And it's the most important evolution happening in product ops right now.

So what does the context layer actually contain?

The context layer is everything an agent – or a new PM joining your team – would need to know to make a good product decision. In practice, it breaks down into six categories:

Strategy and direction: product strategy and vision, OKRs, roadmap, milestones, goals
Customer signal: feedback, support tickets, sales call notes, user interviews, usage data, segmentation, research
Competitive context: positioning, what competitors are doing, market signals
Your actual product: documentation, codebase, ideas, explorations
Institutional memory: past decisions, experiment results, why you built things the way you did
Team norms: what good looks like in your org, your standards, guidelines, templates

None of this is new information. It's information that already exists in your company – scattered across ten tools and three people's heads. The context layer is what you get when you bring it together and keep it current.

The three most common context gaps right now

Scattered customer feedback

Customer feedback scattered across four or more systems with no synthesis layer is the most common gap by far. Zendesk has support themes, Gong has sales objections, surveys have NPS comments, Slack has random screenshots – and no one's pulling it together.

Each PM does their own ad-hoc synthesis, starting from a different baseline every time.

Past decisions living in people's heads

Why did we kill that feature in Q2? Why did we choose this architecture?

When someone leaves, the knowledge leaves with them. And suddenly, a new PM is making the same mistakes that were figured out eighteen months ago.

Barley used strategy docs

This one surprises people – strategy docs that are technically current but never referenced. Updated nine months ago, buried in Confluence, and never opened. The doc exists, but it isn't doing the work of aligning the team.

How to know if your team has a context problem

A few quick diagnostics you can run this week.

Ask three PMs the same question about the product strategy. If you get three different answers, you have a context problem.
Measure the time from "we should do this" to "here's a brief leadership can approve." If it's measured in weeks, context is the reason.
Ask your PMs what they spend most of their time on. If the honest answer is "looking for information and getting people aligned" instead of "making decisions," you have a context problem.

What good quality control actually looks like

Better context gets you halfway there. But you still need teams to interrogate the output rather than accept it.

A few things that build on each other:

Interrogate the output

If an agent says "customers want feature X," that's a starting point, not a conclusion. How many customers? Which segments? Real pain or nice-to-have? Product leaders are used to this muscle. ICs need to develop it when reviewing AI output.

Define what "good" looks like

Make it concrete – templates, examples of strong briefs, gold-standard prompts. Agents need structure to produce useful work, and so do the humans reviewing it.

Turn every piece of feedback into learning

When a brief comes back with rework, when leadership pushes back, when an agent misses an obvious customer segment – that's a signal. Update the agent's instructions, refine the skill, sharpen the prompt.

Treat your agents like new hires: every mistake is an opportunity to update the playbook.

Measure outcomes, not compliance

Stop tracking "percent of product briefs that follow the template." Instead, track time from idea to validated brief, and rework rate after leadership review. Quality reveals itself in those numbers.

What Monday looks like when you've got this right

The most visible difference? They're not running status meetings.

Status synthesis happens automatically – agents pull from the systems where work is happening and surface what's changed. What the team is spending Monday on instead: reviewing where context has gone stale, identifying gaps from last week's briefs, and designing the next agentic workflow to automate.

They've also stopped measuring template compliance and started measuring decision velocity and quality. So Monday includes looking at metrics like "how long did our last three features take from insight to spec" and "how much rework did leadership review generate."

The judgment question nobody wants to answer

AI is great at making us feel right. It's much less reliable at telling us when we're wrong.

Junior PMs, especially, are vulnerable because they don't yet have the pattern recognition to know when an agent is confidently leading them astray. And this is the part I worry about most.

You develop judgment the way you always have: direct contact with customers, watching frustration on their face when something doesn't work, sitting in sales calls, shipping things, and seeing what happens, deeply understanding your product and the ones you compete with.

None of that changes. What changes is that you have more time for it, because the agent handles the synthesis work that used to consume your day.

So protect time for the human judgment activities. Mandate them, even.

15 minutes a day reviewing real customer feedback.
A monthly sales call ride-along.
A user interview every two weeks.

The agents free you up – make sure you actually use that freedom for the things that build taste.

The honest truth about building this inside Productboard

We're going through this shift ourselves. And you know what? The hardest part isn't even the technology. What slows things down is the context hygiene.

You can't bolt AI onto a messy organization and expect magic. We've had to invest seriously in keeping our own strategy docs current, our customer feedback synthesized in one place, our past decisions documented somewhere findable.

The teams that get value from AI fastest treat context as a product. They version it, maintain it and assign ownership to it. The teams that struggle treat AI as a tool you bolt on top of existing chaos.

And here's the uncomfortable truth: building this layer surfaces all the organizational dysfunction you'd been working around. Stale docs, undocumented decisions, conflicting priorities, and a lack of alignment on strategy and vision.

AI makes these problems impossible to ignore, which is painful in the moment, and incredibly valuable over time.

Key takeaway: Do this one thing differently tomorrow

Stop policing the process. Start removing the bottleneck in what to build next.

For most product ops teams, the default is enforcement – templates, approvals, and tool updates. That made sense when coordination was the constraint. It isn't anymore. Today, the constraint is that product managers can't get to a confident answer about what to build fast enough, because the context they need is scattered, stale, or stuck in someone's head.

Pick the single biggest thing slowing your PMs down – usually customer feedback synthesis, or finding the latest strategy doc, or figuring out what was decided about a similar feature six months ago – and curate that context properly. Make it accessible. Make it current. Then build the ops agents that automate the rest.

You'll know it's working when PMs stop coming to you for permission and start coming to you because the system actually helps them think.

Want to go deeper on this?

Martin Felcman will be taking the stage at Product Operations Summit Amsterdam to break down exactly how product ops teams can make this shift – from process enforcer to context architect.

Join hundreds of product ops leaders for two days of sessions, workshops, and real talk about the future of the function.

Grab your ticket