For most of the history of software, the constraint was the actual building. There was always more to build than engineers to build it.
That’s no longer true on a growing number of teams. Build time has compressed enough that the real constraint is deciding: what to build, in what order, for which users. Engineers can ship faster than product teams can decide, and sometimes faster than users can absorb.
When building stops being the constraint, every weakness in product thinking becomes visible immediately. You can’t outrun a weak strategy with velocity anymore.
Every time tooling shifts this fast, the reflex is to predict who gets replaced. PMs can now ship, so engineers are cooked. Engineers can now write specs, so PMs are cooked. Both takes are wrong. And both will wreck how you staff a team.
For years, a huge amount of a PM’s week went into connective tissue. Writing tickets, breaking epics into stories, generating status updates, cross-referencing specs against the codebase to find what was missing. Administrative PMing. AI handles most of that hygiene now, and it’s only going to handle more. That's not a loss. That’s an unlock. The part AI can’t compress is the part that made most of us want to do product work in the first place: taste and curation. Knowing what to focus on instead of boiling the ocean. Figuring out why this problem is worth solving, and how to align stakeholders who each have a legitimate claim on the roadmap.
Same shape on the engineering side. A huge amount of an engineer’s week used to go into work that was necessary but not the job. Scaffolding, boilerplate, the fifth CRUD endpoint that week, grinding through the mechanical parts of a refactor. AI handles most of that now. This is why you hear the old heads talking about loving to code again.
The part AI can’t compress is system design under real constraints, knowing which abstraction will still make sense in 18 months, reading a codebase’s history to understand why something is the way it is, calling the tradeoff when the stakes are real, and knowing when to stop.
When the mechanical work stops being the constraint, curation becomes the whole game. The people who can curate win. The people whose value was mostly throughput or coordination are in a different conversation.
The old handoff model put a price on the artifacts. Both got cheap. Not free. Cheap. A PM with a coding assistant can stand up a working prototype in a weekend that used to take a six-week POC. A solid PRD can be a 90-minute exercise with an AI collaborator that stress-tests the thinking as you go.
When the artifacts get cheap, the question stops being how do we produce them and starts being what are the stakes of the decision they're describing.
Picking the next song on an R&B station is not the same call as routing a payment that moves a billion dollars. One is reversible, taste-driven, and the user tells you within seconds whether you got it right. The other is irreversible, correctness-driven, and the cost of being wrong is measured in lawsuits.
Low-stakes, reversible, taste-driven work: the prototype is the spec. Ship, watch, iterate. A written doc is overhead. High-stakes, irreversible, correctness-driven work: the spec is the thing, and the prototype is the sanity check underneath it. A team that ships first and specs later is one outage away from a very bad week.
Most teams aren’t failing because they picked wrong on an approach. They’re failing because they picked one approach and applied it everywhere. Feature thrash is what happens when you use the R&B-station playbook on payment routing. The teams that ship well read the stakes of the decision in front of them and pick the approach that fits.
Here’s the part I’m still working through.
The old model had clean ownership lines: product owned the what and the why, engineering owned the how, design owned the experience.
Those lines were never quite real, but they were real enough to run an org on for a decade. The AI era is dissolving them. A PM who ships a working prototype over the weekend isn’t purely on the “what” side. An engineer making product calls at 9pm because the PM isn’t in the room isn’t purely on the “how” side either.
That’s fine until something goes wrong. Then the old reflex kicks in, everyone retreats to their lane, and the thing itself doesn’t ship.
The orgs I see doing the most interesting and successful work here aren’t the ones that have figured out the new role definitions. It's the teams that have stopped hedging. Somebody decides. Somebody owns the outcome.
If you’re working through this on your team, I’d love to hear what’s working. More on org structure, methodologies, and what “a good product team” even means in this era — soon.
