Product Management Is Inventory Control

What happens to prioritization when execution is free

A tweet made the rounds recently arguing that AI-accelerated development makes product managers more valuable than ever. The logic: if Claude Code can ship a feature in hours that used to take weeks, then "building the wrong feature" becomes catastrophically expensive. Therefore the person who decides what to build—the PM—is now the critical bottleneck.

It's a comforting narrative for PMs. It's also wrong, and wrong in an interesting way.

Start with the math. If building the wrong feature used to cost three weeks of engineer time and now costs three hours of compute, bad prioritization just got massively cheaper per instance. You can build the wrong thing and recover before lunch. The absolute cost of a mistake cratered.

What changes is the volume of decisions. When shipping is nearly free, you're making ten times more build/kill calls per week. Each mistake is cheap, but consistently bad judgment compounds faster because you're running the loop at higher frequency. That's a real problem—but it's a different problem than the one being claimed, and it cuts both ways. If shipping is cheap, you can also course-correct almost immediately. Try five things, see what sticks, kill the losers.

The tweet confuses the cost of a single bad decision (which dropped) with the throughput of the decision process (which spiked). These require different responses. One calls for better prioritization. The other calls for faster iteration.

But the deeper error isn't mathematical. It's categorical. The tweet equates product judgment with product management, and they are not the same thing.

Product judgment is taste. It's the ability to look at what you've built and know whether it's right. It's choosing well under constraint, informed by experience, shaped by contact with actual users. It's real, it's durable, and it matters more than ever.

Product management is the organizational role that grew up around product judgment when execution was expensive. It's the roadmap, the sprint plan, the prioritization framework, the stakeholder alignment meeting, the RICE score, the quarterly OKR review. It's the process infrastructure that exists to ensure scarce engineering resources get pointed at the right thing before you commit them.

Think about what a PM actually does day to day. They gather requirements from stakeholders. They negotiate priorities across teams. They sequence work into sprints. They manage the backlog. They write tickets detailed enough for engineers who lack full business context. They run standups and retros and planning poker.

Every single one of these activities exists because building software is expensive and slow. When you can only ship one feature this sprint, you'd better make sure it's the right one. When an engineer costs $200k/year and context-switching is ruinous, you'd better give them clear, well-specified work. When three teams share a platform, you'd better coordinate their roadmaps so they don't collide.

This is inventory control. It's the careful management of a scarce resource—engineering time—to minimize waste and maximize throughput. It's valuable work. It's also work that is entirely downstream of a cost structure.

Change the cost structure, and the work disappears.

Here's the thing I didn't fully understand about my own career until this conversation forced me to articulate it: I've been operating in the post-PM cost regime for over a decade. I just didn't have the language for why.

I built CaliforniaBirthIndex.org in a week. No roadmap. No sprint plan. No prioritization framework. I had an intuition, I built the thing, and it either worked or it didn't. It worked. It still gets 250,000 visits a month with zero maintenance.

I didn't skip product management because I was ideologically opposed to process. I skipped it because for me, execution was cheap. When you can build and deploy a complete application in days, you don't need to carefully ration engineering time. You don't need a roadmap because the cost of being wrong is a weekend. You don't need sprint planning because the sprint is "today." You don't need stakeholder alignment because you're the only stakeholder.

What I had was taste and fast hands. Product judgment meeting cheap execution directly, with nothing in between.

I was vibe coding before there was a word for it. Not because I was ahead of the curve, but because my particular combination of speed and judgment put me in a cost regime that didn't exist for most teams. For me, execution was cheap enough that the entire PM apparatus was unnecessary overhead. For teams with expensive execution, it was essential infrastructure.

AI is collapsing everyone into my cost regime. That's the shift.

When Claude Code can ship a feature in hours, every team is operating with cheap execution. The cost structure that justified product management—expensive engineering time that must be carefully rationed—is evaporating. And with it, the entire organizational apparatus that grew up around that constraint.

You don't need a roadmap when you can build three candidate features and ship the one that works. You don't need sprint planning when the sprint is a conversation. You don't need RICE scores when the cost of trying something is lower than the cost of scoring it. You don't need a PM to write detailed tickets when your AI collaborator already has the full context of what you're building and why.

This doesn't mean product judgment becomes less important. It means product judgment gets liberated from the process that was mediating it. The person with taste no longer needs an organizational role to exercise it. They just need access to the tools.

Consider what actually happens when execution is cheap. You don't prioritize harder. You iterate faster.

The old model: spend two weeks deciding what to build, then spend six weeks building it. You front-load the decision because the execution is expensive. If you decide wrong, you've lost two months.

The new model: build something in three hours. Ship it. Watch what happens. If it's wrong, build something else tomorrow. You don't need to decide correctly upfront because the cost of deciding wrong is trivially low.

This is a fundamentally different discipline than prioritization. Prioritization is analytical—weigh inputs, score options, sequence a roadmap. What replaces it is recognition—the ability to look at what you shipped and see whether it's working. Prioritization is a planning skill. Recognition is taste. They feel similar from the outside but they are structurally different cognitive operations.

The PM who excels at prioritization—the one who runs a tight backlog and sequences features perfectly—has a skill that is becoming obsolete. Not because it's bad, but because the economic conditions that made it valuable are disappearing. The person who excels at recognition—who can ship fast, watch what happens, and know which signal to follow—that person was always the one who mattered. They just used to need an organization around them to execute on what they saw.

Now they don't.

This is the pattern across all of software development's organizational infrastructure. Agile, Scrum, sprint planning, story points, estimation, retrospectives, standups—the entire methodology industry exists because building software was expensive and unpredictable. Every ceremony, every framework, every certification was an attempt to manage the risk and cost of execution.

Story points exist because teams needed to estimate how long things would take so they could plan sprints. When features take hours instead of weeks, estimation is pointless—just build it and see. Standups exist because managers needed to track progress on expensive multi-week efforts. When the effort is an afternoon, there's nothing to stand up about. Retrospectives exist because teams needed to improve a process that was their bottleneck. When the process is "tell Claude what you want," what's left to retro?

None of these practices were wrong. They were appropriate responses to a cost structure. The mistake is treating them as inherent to the discipline of building software rather than as accommodations for the economics of building software. When the economics change, the accommodations become dead weight.

The tweet I started with claimed that Boris Cherny, who built Claude Code, told us the bottleneck is moving to product management. But listen to what Boris actually listed: prompting, customer conversations, cross-team coordination, deciding what to build.

Half that list is coordination overhead that exists because execution used to be expensive. Cross-team coordination? That's a multi-team problem. If one person with AI can ship what used to take a team, you don't need cross-team anything—you need fewer teams. Prompting? That's not a PM skill, that's just talking to your collaborator. Customer conversations and deciding what to build? Those are real, but they're not product management. They're product judgment. They existed before the PM role did and they'll exist after it's gone.

What Boris actually demonstrated is that the execution bottleneck has dissolved to the point where the remaining work is just thinking clearly about what matters. The tweet looked at that and saw a PM job description. I look at it and see the PM role being subsumed back into the builder, where it started.

Here's what I think actually happens.

In large organizations, the PM role persists for a while as a political function—someone has to negotiate between competing interests, manage stakeholder expectations, translate between business and engineering. That work is real, but it's organizational mediation, not product thinking. It's closer to project management than product vision. And it's exactly the kind of coordination work that AI agents will eat next, because coordination is ultimately an information-routing problem.

In smaller organizations—and in the explosion of solo and micro-team builders that cheap execution enables—the PM role simply doesn't exist. The builder has the taste. The AI has the hands. There's nothing in between that needs managing. This is how I've always worked. It's about to be how a lot of people work.

The tweet argued that "every PM who learns to prompt, prototype, and ship with AI tools just became 10x more valuable." But a PM who can prompt, prototype, and ship isn't a PM anymore. They're a builder. They've collapsed the role back into the direct exercise of judgment through execution. Which is what every good founder already does.

The broader lesson is that a lot of what we think of as "skills" in the software industry are actually adaptations to scarcity. They're ways of coping with the fact that building software was hard, slow, and expensive. Sprint planning is a skill. Backlog grooming is a skill. Writing a good JIRA ticket is a skill. Estimating story points is a skill.

These are real skills that took real effort to develop. People built careers around them. Entire consulting practices exist to teach them. They're just not skills that matter when the underlying scarcity disappears. They're like being really good at optimizing horse-drawn carriage routes. Genuinely valuable—right up until it isn't.

What does matter, and has always mattered, is the thing that was hiding underneath all the process: the ability to see what should exist and recognize it when it does. Taste. Judgment. The thing you can't learn from a certification course because it comes from years of watching what works and what doesn't.

Product management was inventory control. The inventory is about to be infinite. What remains is knowing what's worth building—and that was never a management function. It was always a creative one.