Product Management Has a Velocity Problem

When code is cheap, product judgment becomes the constraint

The sentence I've been waiting for

I heard it last Friday: "We fired our head of product. They weren't able to move as fast as our engineering team." It's starting at small companies, but it signals a bigger crisis for product management.

The old world

For decades the bottleneck was hands-on-keyboards. Engineering time was scarce, so we optimized for ceremony and alignment: quarterly OKRs, monthly business reviews, weekly product reviews, daily stand-ups, constant user research. The rituals worked because code was expensive.

A feature that took six weeks to build could justify two weeks of user research, a week of spec writing, and four rounds of design review. The math worked. PM overhead was a rounding error compared to engineering cost.

The new constraint

When code generation accelerates for certain types of work, the constraint shifts to thought, judgment, and decision-making. Product management gets reexamined from the ground up. The old cadence doesn't survive when builds happen in hours.

An engineer with Cursor or Claude can ship specific features in an afternoon. Standard authentication flows? Done by lunch. CRUD dashboards? Finished before standup ends. Basic payment integrations? Two hours, including tests.

This doesn't apply to everything. Distributed systems, novel architectures, ML pipelines, compliance-heavy features, and scale-sensitive work still require careful engineering. But the subset of product work that is now genuinely fast has grown large enough to create tension.

The PM is still running their two-week discovery sprint. Still scheduling five stakeholder meetings. Still writing the 12-page spec document. By the time the PRD is ready, engineering has already shipped three other features and is wondering what product is doing all day.

The velocity mismatch

PMs operate at a cadence designed for a different era. The tools and processes that made sense when engineering was the bottleneck become the bottleneck when code gets cheap.

The pattern repeats:

• A PM spent three days crafting the perfect roadmap presentation. Engineering shipped four features during those three days and asked why they weren't in the deck.
• A product team ran a month-long customer research initiative to validate a feature concept. By the time they presented findings, the engineering team had prototyped, tested, and deprecated two similar approaches.
• A head of product got fired not for poor judgment, but for taking two weeks to make a decision that engineering could implement in two hours.

But slowness rarely comes from individual PM output alone. The deeper issues:

• Unclear company strategy means PMs spend weeks building alignment that shouldn't be necessary
• Reactive leadership creates constant reprioritization, making previous research obsolete
• Conflicting incentives across functions force PMs into negotiation cycles that delay decisions
• Shifting goals invalidate carefully researched product directions mid-stream

The gap continues to widen. Treating it purely as a PM performance problem misses the organizational dysfunction underneath.

The career implications

This shift threatens the entire PM discipline. If product thinking can't keep pace with product building, one of two things happens:

1. Engineering starts making product decisions (often badly, without user context or business strategy) 2. Companies stop hiring PMs and just let AI agents make the calls

Neither is good. The first leads to technically impressive products that nobody wants. The second leads to feature churn without strategic direction.

But there's a third path: PMs who evolve their practice to match the new environment. Discovery work fundamentally takes time (market sizing, qualitative research, enterprise needs analysis, and validation don't accelerate at the same rate as code generation), so the answer lies in making PM judgment more accessible to the systems doing the building.

This raises new risks. Velocity without validation can erode user trust, accelerate technical debt, create brand inconsistency, and ship misaligned features at scale. PMs must actively manage these trade-offs, which means evolving new skills: understanding how AI consumes context, recognizing agent failure modes, and designing systems that preserve strategic coherence even when execution accelerates.

What changes

Making faster decisions misses the point. The real challenge: making your decisions accessible to the systems doing the building.

When an AI agent is implementing a feature, it needs instant access to different types of product judgment:

• Business prioritization: Why this feature matters more than alternatives
• UX clarity: What experience principles guide implementation choices
• Strategic trade-offs: How this fits into long-term product direction
• Risk assessment: What could go wrong and what safeguards matter
• User segmentation: Which user groups this serves and which it doesn't
• Sequencing logic: Why now versus later, and what dependencies exist

But encoding judgment is only one dimension of PM work. PMs still need to:

• Align executives around strategic direction
• Negotiate cross-functional trade-offs in real-time
• Set long-term vision that guides multiple teams
• Design rollout sequences that manage risk and dependencies
• Build trust with customers and stakeholders through direct engagement

Tools that capture structured context support these activities but don't replace them. The value is in making PM reasoning available to engineers and AI systems at decision time, reducing the coordination overhead that slows everyone down.

The silver lining

The same founder asked, "Can an AI teach my engineers taste?" Yes. Taste is a series of decisions and judgments. AI can teach engineers and agents taste, but it needs human direction. People who care about users, customers, and what the company can achieve.

Product management survives this shift. PM as process coordinator doesn't. The future belongs to PMs who can encode judgment, not just exercise it. Who can build systems that scale taste, not just demonstrate it in quarterly reviews.

The PMs who figure this out won't get fired for being too slow. They'll be the ones who kept their companies building the right things even as execution velocity increased. Not by working faster, but by making their thinking more accessible to the systems and people who need it.