There was a line in an a16z piece from January that I keep coming back to:
"Every feature that can be built will be built."
Most people read this as optimism. I read it as a warning.
Software development has always been organized around scarcity. Engineering capacity was limited. Sprint planning existed to manage that scarcity. The backlog was a waiting list — things you wanted to do but couldn't yet afford to.
AI coding agents broke that equation. A small feature can be shipped in hours now. A medium one in a few days. The technical constraint still exists, but not like before. Not enough to structure your whole process around it.
And when a constraint moves, everything downstream needs to shift with it.
The natural first reaction is: "Great — we can build more."
That's the wrong frame.
The real question is: when capacity stops being the bottleneck, what does prioritization even mean?
In the products I work on, the backlog has always been a filtered list — things users asked for, things we believed in, filtered through "what can we actually do this quarter." That filter is essentially gone now. So what's left?
If we can build everything, and we start building everything, what are we actually saying to users? What does the product stand for? Which problem are we genuinely solving?
These used to be questions for an annual strategy offsite. Now they're operational.
The same a16z article has an uncomfortable admission tucked in: "Models are still not very good at deciding what to build next — the ideas tend to be bland and derivative."
So AI can build anything. But it doesn't know what to build.
That gap is exactly where the PM's job lives now. Not just "what should we build?" — but more importantly, "what should we deliberately not build?"
Last month a user on one of our products asked for a visualization of weekly measurement trends — a chart, basically. Reasonable request. Technically buildable in a day now.
We didn't build it.
Because the same week, a different user flagged that appointment reminders weren't firing reliably. Less flashy. Doesn't feel like a "feature" at all. But it's something users touch every single day, and when it breaks, it actually affects patient care.
Choosing between those two is the actual job. And you can only make that choice if you're clear on what the product is trying to do — not what's technically possible.
There's another thread worth pulling. The a16z piece notes that all our current tools are built for execution: IDEs for writing code, Figma for design, spreadsheets for modeling. But tools for exploration — for thinking, for deciding what not to build — barely exist.
That's not an accident. The market has raced to increase building capacity. Nobody's built the tool that helps you say no with confidence and a clear audit trail.
Maybe that's a product opportunity. Maybe it's just work that has to be done with judgment and clarity, no tooling. Either way, it's hard. And most teams aren't doing it.
Paul Graham wrote something years ago that stuck with me: "Good product isn't about adding features. It's deciding not to add them."
That was true before AI. It's more urgent now.
"We can't build it yet" is no longer a valid answer to anyone. You have to say "we chose not to build it" — and then explain why. Out loud. In front of stakeholders who can now point to an AI agent that could have it done by Thursday.
That's a harder, more visible, more accountable position for PMs to be in.
It's also the only position that matters anymore.