AI in Product Management: What’s (Really) Changing?

When I spoke with Jefferson Rabb, CPO at Business Insider, at ProductCon New York, one idea stuck with me: 

“AI is not just helping product teams move faster. It is changing what slows them down.”

For years, product management was built around one simple reality: engineering time was scarce. PMs learned to protect it and prioritize around it.

But that logic has started to shift. Jefferson described a product-led organization where engineering was suddenly moving faster than expected, sometimes faster than the product could keep up with. AI builders are now changing the pace of delivery, but the bigger change is even more interesting… 

The bottleneck is no longer just engineering capacity. It’s judgment, alignment, clarity, and the ability to decide what should be built in the first place. That conversation led me to the question behind this piece: if AI changes the speed of building, how does it change the role of the AI product manager?

This piece is for product managers, product leaders, and aspiring AI PMs who want to understand what AI is really changing beyond the obvious productivity gains. It will reveal why the PM role is shifting from managing scarce engineering capacity to shaping better decisions, faster collaboration, sharper prioritization, and stronger product judgment in an AI-accelerated world. 

AI Product Management Certification

Adopt an AI-first mindset: design AI-native UX, build agents, define modern PRDs, and ship trustworthy AI-powered products.

Enroll now

Key Takeaways

• AI is changing product management by shifting the main constraint from engineering output to product judgment, AI product strategy, and decision quality.

• Product managers will spend less time writing static requirements and more time shaping AI prototypes, validating assumptions, and coordinating faster product loops.

• Vibe coding changes the economics of prototyping, technical debt, replatforming, and build-versus-buy decisions.

• Prioritization does not disappear when teams can build faster. It becomes more important because product bloat, unclear strategy, and weak governance become easier to create.

• The PM role is moving from gatekeeper of engineering capacity to orchestrator of product velocity, customer context, quality, and business impact.

• The PMs who benefit most from AI will not be the ones who automate the most tasks. They will be the ones who redesign how product work flows through the organization.

How AI Flipped the Product-Engineering Bottleneck

Rabb's account starts with a reorganization in late 2025. A strange set of signals showed up almost immediately after his team hit the ground running in January 2026. Engineers were beating their estimates by enough that a project scoped at three to four months would be finished in weeks. And the signal that actually got leadership's attention was what engineering managers started doing with their newfound time.

In his own words:

"We were hearing engineering managers proactively raise their hands, asking for more work. They were burning through work faster than we could schedule it for them."

I want to sit with that for a second. It's a more specific claim than the usual "AI made engineering faster" you see on every other blog post. 

Engineering managers are, almost by job description, the people who protect their team's time. Watching that instinct flip is a sharper signal than any productivity metric. It's a change in behavior that the people doing it didn't have to be coached into.

It's also not unique to one newsroom. GitHub's 2025 Octoverse report, the company's annual look at activity across its own platform, recorded roughly 43.2 million pull requests merged every month on average in 2025, up 23% year over year. That's the literal record of what tens of millions of developers did with their time last year, and it moved in the same direction Rabb is describing. 

Whatever happened at Business Insider, it happened against the backdrop of an industry-wide acceleration, not in spite of one.

And in their case specifically, Rabb says Business Insider's PR team put out one product-related press post the year before this acceleration, against a dozen by mid-year after it. He estimated that the company could end the year shipping more than 20 times its prior product news output. 

Can you see now why "AI makes engineers faster" is a good, but unremarkable claim by now. It's that the speed arrived before anyone built the processes to absorb it, and that gap is exactly where both the opportunity and the risk in this piece live. 

Watch

Why AI Boosts Engineer Confidence but Not Trust

AI coding tools raise engineer confidence by acting as a tireless, non-judgmental collaborator that lowers the cost of trying. That is separate from trust in the output itself, which is falling industry-wide even as adoption climbs. 

Rabb goes one layer deeper. His engineers also started feeling differently. They were more willing to take on unfamiliar codebases, more comfortable with ambiguity, and more willing to absorb a little risk than a year earlier. The theory he shared at ProductCon New York as to why:

"An engineer who works with this technology has a partner that they work with at all times (non-judgmental, always available) that has a very good track record at helping them produce idiomatic code."

The word non-judgmental is the key. Much of an engineer's and AI builder’s hesitation in unfamiliar code is the social cost of guessing wrong in front of other people. Remove the audience, and a lot of that hesitation goes with it.

That rising confidence coincides with industry-wide decline in trust toward AI output. Stack Overflow's 2025 Developer Survey (nearly 49,000 responses, 177 countries) found AI tool adoption rose to 84%, up from 76% the year before, while trust in the accuracy of AI output fell to 29%, down from 40%. Favorability dropped from 72% to 60%. 

Developers are using these tools more and believing them less at the same time. It’s the opposite of how trust in a new technology usually moves.

Confidence and trust are not the same thing, and conflating them is the mistake to avoid. 

Confidence is having a tireless collaborator to think out loud with, which lowers the cost of trying. Trust is believing the specific thing it just told you. An engineer can be more confident entering unfamiliar territory while still distrusting any individual suggestion enough to check it. 

The confidence bought courage, not a pass on verification. The moment an organization treats rising confidence as a substitute for verification rather than a complement to it, that defect-free streak stops being guaranteed.

How to put this confidence/trust distinction to work

• Spend the confidence deliberately. Route engineers toward the unfamiliar codebases and ambiguous problems they used to avoid. That's where lowered hesitation creates the most value.

• Keep verification mandatory, not optional. Treat declining trust as a feature. Never let rising confidence quietly downgrade code review from a requirement to a courtesy.

• Measure outcomes, not vibes. Track real defect, incident, and rework rates and not how fast the team feels. A team that feels 20% faster may not be, and only the outcome data will tell you.

What Changes When Engineering Capacity Stops Being Scarce

When build capacity is no longer rationed, four habits shift: teams stop replatforming, they grow comfortable with technical debt, they treat code as disposable, and they explore multiple solutions in parallel. Each has a real advantage with a real, measurable cost that has to be tracked.

Let’s be candid about all four:

• Replatforming minimizes. Big migrations have always been hard. It usually means a year of error-prone work that often lands you where you started with an even bigger bill. Once you can build the equivalent capability faster than you could negotiate and integrate someone else's, the buy-versus-build math I  spoke about earlier this year flips. 

• Technical debt becomes acceptable. Engineers have always weighed the scalable approach against the fast one. What changed is the cost of guessing wrong: a refactor that took weeks now takes days, so the bet is cheaper to lose.

• Code becomes disposable. Work that would have been unthinkable when engineering hours were precious — starting before stakeholder buy-in, building things you expect to throw away — is now routine, because the cost of trying dropped.

• Exploration goes parallel. Multiple engineers now solve the same problem in different ways at once, knowing only one solution ships.

None of this is wrong, but it's worth pricing honestly, because the costs land alongside the optimism:

The technical debt bill is real and measurable

GitClear's 2025 AI Copilot Code Quality report analyzed 211 million changed lines of code (2020–2024) and found that duplicated code blocks became roughly eight times more common in 2024 than two years earlier. 

What’s more, refactoring collapsed and short-term churn (code rewritten or reverted within two weeks) climbed steadily. A monitored debt with a plan to service it is a defensible choice; an invisible one is not. 

GitClear's data suggests many teams are in the second category without knowing it.

The replatforming confidence isn't universal

Gartner expects 40% of enterprise apps to carry task-specific AI agents by the end of 2026, up from under 5%.

Separately, over 40% of agentic AI projects will be canceled by the end of 2027 due to cost, unclear value, or weak risk controls. 

This is a great warning for product teams. Speed makes it cheap to start things, not cheap to finish them. 

Half of what you rush to build, there’s a chance you'll pay to unwind. Therefore, the discipline shifts from "can we build it?" to "should this exist, and can we maintain it?" I wrote about this in more detail in my recent coverage of product prioritization in an AI era so do check that out.

How to adopt these shifts without the downside

Each of these moves is worth making but only with a guardrail that keeps the upside from turning into a liability. Use this as a working checklist for product and engineering leads.

Abundance rewards teams that make their tradeoffs explicit and punishes the ones that let them stay invisible. The speed is free, but the discipline to track what it costs is not.

Verification Is the New Bottleneck in AI Product Development

Faster code generation moves the bottleneck to verification. To your team's capacity to review, test, and trust AI output before it ships. Gatekeeping shifts from protecting an engineer's time to protecting the trustworthiness of what gets produced.

When engineering output multiplies, the work shifts downstream to whoever has to confirm the output is correct, safe, and worth shipping. That's verification, and most teams haven't scaled it to match.

In July 2025, the AI research nonprofit METR ran a randomized controlled trial with 16 experienced open-source developers across 246 real tasks on codebases they knew well. 

Given the best AI tools, those developers took 19% longer to finish. It’s the opposite of what the researchers expected. Stranger still, the developers predicted a 24% speedup beforehand and still believed AI had made them about 20% faster afterward, even though it had slowed them down.

Add the AI evaluation, AI ethics, RAG, and agentic architecture to the mix, and you’re looking at a convoluted and stretched-out timeline.

That result doesn't mean AI is not fast. It means the speed gain is conditional and has to be thought through. AI's advantage shrinks, and can reverse, in exactly the settings where verification is hardest:

• Large, mature codebases with years of accumulated convention.

• Strict quality bars, where "almost right" isn't good enough to ship.

• Familiar work, where typing a known solution beats prompting for one and checking it.

How to manage verification risk before scaling AI output

Product management and development teams can fix it by matching the level of review to the risk of the work. They need to decide on purpose instead of by default. Use the table below as a quick triage before greenlighting AI-heavy work.

The Capacity Inversion Framework: How to Prioritize When Capacity Isn't the Constraint

The Capacity Inversion Framework is a five-gate test for deciding what to build once engineering capacity is no longer the limiting factor. Instead of asking whether a team can afford to build something, it asks whether the thing should exist at all. The framework runs each initiative through five sequential gates: Conviction, Clarity, Capability, Reversibility, and Verification. 

This is the question Rabb's talk circles without ever quite landing on a name for it, and I think it's the most important strategic shift buried in the whole talk:

"If capacity is no longer the dominant prioritization concern, this has us asking a bit of an existential question: what replaces it? This one may seem rather obvious, but it's kind of refreshing to simply be able to ask: is this thing a good idea?"

What I think actually needs to replace it isn't a better scoring model. It's an earlier, harder set of filters that ask a different question entirely: not "can we afford this," but "should this exist." 

I've named and ordered them below, and added a fifth that the talk didn’t raise, because I think it's the one teams adopting this playbook are most likely to skip. 

Run an initiative through the gates in order. A clear "no" at any gate is a reason to stop, not a hurdle to argue past.

Gate 1 — Conviction: Is this worth building on its own terms?

Would you still build this if it took three months instead of three days? If feasibility is the only reason it's appealing, it fails the gate.

Scarce capacity is used to perform this filtering for free. Only the strongest ideas survived a limited queue, so "having bandwidth" was a kind of endorsement. Abundance removes that filter, which means weak ideas now sail through on feasibility alone. 

The danger here lies in plausible ideas that no one would have fought for under scarcity.

In practice, strip the cost out of the decision and see if the idea still stands. Write the user or business outcome you expect before anyone discusses how easy it is to build. If the outcome is thin but the build is cheap, that's a fail, not a green light.

Gate 2 — Clarity: Does this simplify the product, or just add surface?

Every feature you ship spends your users' attention, even the cheap ones. A feature has to earn a place in the interface, not just a slot on the backlog.

This is product bloat, formalized. When shipping was expensive, the cost of building was an accidental brake on clutter. You simply couldn't afford to add everything. 

Remove that brake and interfaces grow features, each defensible alone and collectively very exhausting. The cost moved from your engineers to your users, where it's harder to see.

So, for every addition, name what it lets you remove, consolidate, or simplify. Track product surface area (count of features, settings, screens) as a real metric, and treat a rising count with flat outcomes as a warning, not a sign of progress.

Gate 3 — Capability: Can the rest of the organization capitalize on this?

"Shipped" and "valuable" are not the same thing. Speed in engineering is wasted if support, sales, data, or compliance can't absorb what it produces.

A feature that ships on schedule into an organization that isn't ready for it, generates cost, not value. They end up with untrained support reps, a sales team that can't position it, and a compliance review that wasn't scoped. 

Engineering velocity makes this failure mode more common, because the constraint that used to give downstream teams time to prepare just disappeared.

Before greenlight, name the specific downstream team that has to act on this and confirm they have the capacity to. If no one outside engineering owns the rollout, you're shipping into a void.

Gate 4 — Reversibility: If you had to kill this in 90 days, shrug or crisis?

Cheap reversibility is one of the real gifts of fast, disposable code, but only if you price it up front instead of discovering it after the fact.

When a feature turns out to be a mistake, it's now faster and less painful to pull it back out than it used to be. The cleanup is quicker, and teams are less attached to work that was cheap to ship in the first place.  

That's a strategic advantage if you design for it. It's a trap if you don't, because the initiatives that couple themselves to everything else are the ones you'll most regret being unable to remove. The exit cost is also a hidden read on how big a bet you're actually making.

To mitigate, classify each initiative by its exit cost before you build (shrug, headache, or crisis), and build the off-ramp into the design (feature flags, clean data boundaries, minimal coupling) for anything you can't comfortably reverse. If killing it in 90 days would be a crisis, you're making a far larger commitment than the roadmap line implies.

Gate 5 — Verification: Can you trust the output at the speed it's produced?

Does the team have enough qualified review and testing capacity to trust this output, or is the speed being funded by skipped verification? This is the gate most teams skip and the one most likely to be the real constraint.

The research earlier in this piece suggests it's where the bottleneck actually relocates. A product team that clears the first four gates but can't clear this one hasn't removed its constraint. It's hidden somewhere less visible and more expensive to find later. Usually in production, usually under time pressure.

This is the one gate you don't get to wave through. Confirm that review and testing capacity scales with output before greenlight, using the verification-risk triage above to size it. Treat a "no" here as a hard stop, not a negotiable.

That fifth gate is the addition I'd defend most strongly to a skeptical CPO. It's tempting to read a talk like Rabb's and conclude the lesson is "move faster, worry less." 

The actual lesson is narrower and I’d say you can move fast through the first four gates, and treat the fifth as the one place you don't cut corners. It's the only gate that, if skipped, costs you the trust that made the speed possible to begin with.

The Capacity Inversion Evaluation Table

This checklist is for reviewing roadmap items in a world where engineering capacity is no longer the automatic bottleneck. Its purpose is to stop teams from shipping work just because AI has made it easier to build. The table helps product leaders and PMs pressure-test whether an initiative is still strategically sound when delivery speed is no longer the main constraint.

Use it during roadmap reviews, quarterly planning, AI-assisted prototyping reviews, or any discussion where the team is tempted to be overconfident.

How to use the evaluation

Score each question from 1 to 3.

• 1 = Red flag
  The initiative is weak, unclear, risky, or likely to create more noise than value.

• 2 = Needs work
  The idea may be worth pursuing, but the team needs more clarity, evidence, ownership, or constraints before committing.

• 3 = Strong signal
  The initiative is strategically sound, operationally realistic, and worth moving forward.

After scoring, use the total to guide the decision:

• 20–24: Move forward
  The idea is strong enough to proceed, assuming normal discovery and delivery checks still apply.

• 14–19: Refine before committing
  There may be value here, but the team should tighten the problem, scope, success metric, or operating plan before adding it to the roadmap.

• 8–13: Do not prioritize yet
  The idea may be feasible, but feasibility is doing too much of the selling. Rework the case before investing more team energy.

How to interpret the results

A high score means the idea is worth proper discovery, design, and delivery work. A low score does not always mean the idea is bad. It means the team may be mistaking speed for strategy.

The most important signal is the pattern. 

• If the first two questions score low, the product idea itself is weak.

• If the middle questions score low, the idea may be good but the organization is not ready for it.

• If the final three questions score low, the team’s operating model has not caught up with AI-assisted delivery speed.

How the Product and Engineering Roles Are Blurring

The product-engineering boundary is dissolving in both directions. Engineers are gaining formal product authority while product managers, now AI builders, are shipping their own prototypes and commits. It's structurally enabled by stronger AI tooling and tools like Claude Code for PMs, not just a cultural choice to collaborate more.

Claude Code for Product Managers

Claude Code is already changing how the best PMs work — at Stripe, Linear, and the fastest-moving teams in tech. Use the AI tool reshaping product work to prototype, analyze, and ship, before a ticket is written.

ENROLL NOW

The last piece of this is structural. It's the part I think will outlast the current moment, even if the specific tools change. 

Rabb, CPO at Business Insider, describes deliberately bringing engineers into product decisions earlier. Meanwhile, product managers on his team have started using prototyping tools to ship actual commits and small applications themselves. 

He frames the old way of working as a relay race: product finishes its leg, fully wrapped, then hands off to engineering. The new way looks more like a basketball game. Both sides are on the floor at the same time, adjusting in real time rather than waiting for a handoff.

I think there's a structural reason this blur is happening now rather than five years ago, and it's not just that the tools got better.

GitHub's 2025 data shows TypeScriptis is becoming the most-used language on the platform by contributor count, ahead of both Python and JavaScript. One reason GitHub points to is that TypeScript gives AI-generated code clearer rules to follow.

In simple terms, TypeScript helps developers define what a piece of code is supposed to receive and return. That means mistakes can be caught earlier, before a human reviewer has to step in.

That matters beyond language rankings.

It shows that software development is moving toward clearer “contracts” between people, code, and AI tools. The more clearly a team can define what it wants, the easier it becomes for an engineer or AI builder (or an AI agent) to act on that instruction safely.

This helps explain the blur Rabb describes between product and engineering roles. PMs are not getting closer to engineering only because everyone wants to collaborate more. The tools themselves are making that collaboration easier. As AI-assisted development becomes faster and more structured, the gap between “what a PM can describe” and “what a team can build” gets smaller.

The Bottleneck Moved. Did Your Org Chart Notice?

For most of PM history, the question if engineering could do it was doing more strategic work than anyone gave it credit for. It was a filter, a pacing mechanism, and an excuse all at once. 

Take it away, as a small number of organizations already have, and what's left exposed is judgment: conviction, readiness, reversibility, and the discipline to verify what's being produced.

The bottleneck didn't disappear. It moved into the room with whoever decides what gets built next. That's a harder job than the one it replaced, and right now, almost nobody's operating model has caught up to it.

If you're rethinking how your team prioritizes work in an environment like this, our guide to product prioritization frameworks is a good starting point for the classic, resource-constrained models. Moreover, our AI Product Strategy certification goes deeper on building a strategy that survives contact with exactly this kind of shift.

AI Product Strategy for Leaders

By the end, you will possess a board-ready AI Strategic Roadmap and Governance Framework, positioning you not just as a product builder but as the executive leader driving your company’s transformation.

ENROLL NOW