I read the Snap CEO announcement last Monday morning. 65% of the company's new code is now written by AI. A thousand people laid off. Smaller teams, same output, $500 million in annualized savings.
My first thought: are engineers done?
Then I stopped.
Wrong question.
The Old Bottleneck
I've been a product manager for four years. In that time, I've said one sentence more than any other:
"We can do it — we just don't have the bandwidth right now."
Here's what that looked like in practice: a clinic asks us to send appointment reminder texts 30 minutes before the visit instead of 10. Reasonable request, small change. My answer: two sprints. Six weeks. Maybe eight if something else came up.
That was engineering bottleneck in its natural state. Requests accumulated, sprints filled up, PMs got stuck in the middle managing a queue instead of a product. When someone asked "why doesn't this feature exist yet?" the honest answer was "we don't have bandwidth" — which is both true and completely uninformative.
Snap's announcement says: that bottleneck is dissolving.
So Where Did It Go?
When engineering gets faster, a different question becomes critical: how quickly can you recover from a wrong decision?
In the old world, a bad feature cost three sprints. You called it a learning, moved on. The sprint was already full anyway — one wasted sprint disappeared into the noise.
In the new world, that same feature ships in one sprint. But now your team is running three things in parallel. One wrong call is buried among two other wrong calls. Mistakes compound faster.
When execution speed increases, decision quality matters disproportionately more.
In late February, we shipped a new tab on the patient card interface. Fast — nearly three times faster than we would have six months earlier. Three weeks later, I pulled the analytics: more than 80% of users who opened the tab were leaving within 10 seconds. We'd solved the right problem in the wrong place. Reversing it cost almost as much time as building it had.
That's when I understood: when you move faster, regret moves faster too.
Is the PM Job Changing?
Yes. But not the way most people think.
The headline is "AI replaces engineers." A more accurate framing: AI is commoditizing engineering capacity. Decision capacity is still human work.
PMs have spent years directing most of their energy toward one question: "When can we build this?" Because that's where the constraint was. Backlog negotiations, sprint planning, capacity discussions. Managing a queue, not a product.
That constraint is shifting. "When?" is getting shorter as an answer. "Why?" is moving to the center.
Why are we building this feature? Is this actually what the user wants, or is it what they said they want? What does it cost to not build it?
Answering those questions genuinely — with data, with real user understanding, without the excuse of engineering backlog filling the silence — that was never easy. It's still not.
A Thousand-Person Signal
I don't know how many of Snap's thousand cuts were product managers. The announcement doesn't say. But here's what I know:
The PM who was hiding behind "we don't have bandwidth" is more exposed now.
When that excuse disappears, product decisions are in the open. If things are still slow, if calls are still wrong, the question won't route to engineering.
It'll come to product.
That should concern some PMs. It gave me pause for a moment too.
But here's the thing: if my job is genuinely about making the right decisions — not managing queues, not writing JIRA tickets — and engineering capacity is no longer blocking those decisions from reaching users, then this is actually good news.
The bottleneck was always here. In judgment. In the quality of the "why." In whether we really understood what we were building and for whom.
It's just more visible now.