Speed vs. Strategy: The False Choice AI-Accelerated Product Teams Are Facing (Part 1 of 2)

Hey there,

I recently spoke with a CPO at a $50M edtech company who told me engineering is accelerating faster than PM and UX can keep up. By December, she said, she'll have idle engineers.

Her first instinct? Find ways to speed up product and design.

In the last few months, I've started seeing this pattern repeatedly. AI tools are making engineers demonstrably more productive. Product teams feel the pressure to match that velocity. Leadership wants to know: How do we make PM and UX faster?

That's the wrong question.

When product leaders say "speed up PM/UX," what does that actually mean in practice?

Faster user story creation. Quicker spec writing. Abbreviated discovery. Compressed design cycles. Leaner documentation. Shorter review periods.

Notice what's happening? You're doing the same work, just faster and worse. You're optimizing for a paradigm that's already obsolete.

The fundamental error is assuming that PM work should scale linearly with engineering velocity. That more engineering output requires proportionally more PM output. That if engineers can build twice as fast, PMs need to define requirements twice as fast to "keep up."

This assumption confuses activity with value.

Engineering work is binary in ways that product work isn't. Code compiles or it doesn't. Tests pass or fail. Dependencies resolve or they break. AI can accelerate binary work more easily because the feedback loops are immediate and unambiguous.

Product work is what my CPO friend called "colorful." It requires market judgment, strategic trade-offs, customer insight, competitive positioning. You can compress the time it takes to write down product decisions, but you can't compress the thinking that should inform those decisions.

When you try, you don't get faster strategy. You get shallower strategy masquerading as speed.

The engineering team that ships features twice as fast has genuinely doubled their productivity. The PM who writes specs twice as fast has just halved the thinking that went into each one. These aren't equivalent accelerations.

A real example from that same edtech company.

Their product serves data analytics to higher education institutions. The PM team had been pushing dashboard redesigns for months—round after round of proposals to make reporting "easier" with "fewer clicks." Classic feature-function thinking: optimize the existing solution.

Meanwhile, the CPO attended some customer training sessions. She watched faculty members' eyes glaze over. She discovered that Customer Success wasn't teaching customers to use the dashboards—they were just pulling reports FOR customers and emailing them the results.

She also noticed that the 20% of power users—the Excel jockeys with stats PhDs—weren't asking for better dashboards. They wanted direct API access.

The fundamental problem wasn't that the dashboard UI needed optimization. The problem was that the data was too complex for ANY dashboard UI to handle all use cases elegantly.

After these observations, the CPO arrived at a strategic solution: an AI report bot where users ask questions in natural language and get back data plus charts plus textual explanation. Not a better version of the thing that wasn't working. A different approach to the problem.

The PM team couldn't get there on their own because they were stuck in "optimize the existing solution" mode. They couldn't see that the existing solution could never work well enough. Why? Because they were optimizing for speed and volume. Ship dashboard improvements. Hit the sprint goals. Keep engineering busy.

Nobody had created space for the kind of thinking that leads to "wait, we're solving the wrong problem."

When you take the speed bait, you get really good at iterating on things that shouldn't exist. You ship faster toward the wrong destination.

When engineering starts outpacing product, the real question isn't "How do we make PM faster?"

The real question is: "What should PM actually do when AI handles more of the tactical execution?"

This might seem contradictory. Engineering is faster, so shouldn't you need MORE PM capacity? But AI is also making PM tactical work faster, so shouldn't you need FEWER PMs?

The answer is neither. You need different PMs doing different work. The old equation—more engineering output requires proportionally more PM output—assumes PM value comes from tactical coordination. But if that tactical work is what AI is eliminating, then scaling PM headcount to match engineering velocity just throws more people at work that's disappearing.

One answer is obvious: operate with fewer PMs. If tactical work is what justified the headcount, and that work is shrinking, the math is simple. This is what most organizations will do—capture the cost savings and move on.

But that's only the right answer if you believe PM work was primarily about tactical execution. If you believe the real value was always supposed to be strategic—and the tactical work was just what PMs had time for—then the question becomes different: Can your remaining PMs actually do strategic work?

The work that used to justify PM headcount—writing specs, grooming backlogs, coordinating handoffs, managing dependencies—is being handled increasingly by AI tools. Some of it will be eliminated entirely. Some of it will be absorbed by engineering teams that can now self-serve.

This creates a genuine crisis for product teams. But the crisis isn't "we're too slow." The crisis is "we're not clear on what value we create when the tactical work goes away."

My CPO friend put it perfectly: "Everything the PMs came up with on their own is feature-function. Nothing was strategic new initiatives."

That's not a speed problem. That's a capability problem masquerading as a speed problem.

Strategic product work doesn't scale with engineering velocity because it's not output-based. It's judgment-based.

Strategic PMs spend time in places that feel "unproductive" by traditional metrics:

This work doesn't produce Jira tickets. It produces clarity about what tickets are worth creating in the first place.

You can't do this work faster. You can only do it or not do it. And when your PMs are underwater with spec writing and backlog grooming and sprint planning, they're not doing it. They're too busy "keeping up" to think strategically.

The irony is that AI's compression of tactical work should create space for strategic work. But only if you redesign what PM does instead of just demanding they do the old work faster.

When engineering accelerates and product "falls behind," organizations actually have three options:

Most organizations will probably choose option three. It feels balanced and reasonable.

But all three options assume PM work should scale with engineering work. They're arguing about ratios and headcount and velocity matching.

They're all wrong.

There's a fourth option nobody's talking about: Redefine what PM work is in an AI-accelerated environment.

This doesn't mean just augmenting PM work with AI tools to write specs faster—though teams should absolutely do that. It means fundamentally reconceiving the role around the judgment work that becomes more valuable as tactical execution becomes less time-intensive.

What does that look like? It looks like:

The dashboard-to-chatbot example illustrates this perfectly. The strategic move wasn't iterating faster on dashboards. It was recognizing that dashboards were the wrong solution architecture. That's judgment work. That's what human PMs should be doing. And you can't speed that up—you can only create the conditions for it to happen.

The reason product leaders default to "speed up PM" instead of "redefine PM" is simple: redefining the role requires uncomfortable honesty about capability gaps.

If strategic thinking is what separates valuable PM work from commodity PM work, then you have to confront a hard question: How many of your current PMs can actually do strategic work?

And if the answer is "not many," you have an even harder question: Is that because you hired wrong, or because you never developed the capability systematically?

Most organizations have spent years measuring PM success by tactical metrics. Even teams that have moved to OKRs and outcome-based measurement often just translate the same tactical mindset into different language. The OKRs become proxies for feature velocity: "Increase user engagement by 15%" becomes shorthand for "ship the features we think will increase engagement." The shift from outputs to outcomes sounds strategic, but if your PMs are still spending 80% of their time on execution mechanics, you've just changed the scoreboard without changing the game.

We've created entire performance management systems around what's measurable and immediate rather than what's strategic and consequential. Now we're supposed to pivot to evaluating strategic judgment when we've never defined what that looks like, never trained people to develop it, never created career paths that reward it?

That's terrifying. It's much easier to just ask everyone to move faster.

The teams that figure this out in the next 18 months won't be the ones who made PM faster. They'll be the ones who got clear on what PM should actually do.

This requires saying "no" to the pressure to just match engineering velocity. It requires honest conversations about role clarity and strategic capability. It requires accepting that some of your current PMs might not have the skills for where product work is heading—not because they're incapable, but because nobody ever invested in developing those skills.

It also requires recognizing that the "speed up PM" instinct, while understandable, is actively harmful. Every initiative focused on helping PMs write specs faster or manage backlogs more efficiently is energy you're NOT spending on developing strategic capability. You're optimizing for the work that's becoming obsolete.

The false choice between speed and strategy isn't just wrong—it's dangerous. Speed without strategy is just thrashing in place. And in a world where AI keeps making tactical work less time-intensive, the teams that figure this out will be the ones who got clear on what strategic product work actually looks like when you're not hiding behind process and volume.

Many product teams are about to discover they've been running fast in the wrong direction. Will they have the courage to stop running and start thinking.

Of course, this raises an uncomfortable question: If strategic thinking is what separates valuable PM work from commodity PM work, how do you actually develop that capability systematically? I'll explore that in Part 2 next Monday.

Break a pencil,

Michael

P.S. Know a product leader whose engineering team is accelerating and they're scrambling to figure out what PM should become? Forward this to them. They're probably feeling this pressure acutely but don't have language for it yet.

P.P.S. I work with product teams on systematic AI adoption—helping them move from "make PM faster" to "redefine what PM does." If your team is ready to make that shift (not just talk about it), learn more here.