Coherently solve user problems
The software product management role was created to manage the scarcity of product capabilities due to high build costs. Engineering time was limited, delivery cycles were slow, and experimentation was expensive. Building the wrong feature burned real team capacity, blew up plans, and left behind debt. Applied AI tools such as agents are removing this constraint. The cost of building and shipping ideas is collapsing. This does not mean software delivery is free. Instead, it means the cost of ideating, building, and shipping features is falling much faster than the cost of deciding what should exist and making it coherent, secure, supportable, and contract-ready.
Because of this change, product management is moving from managing the scarcity of engineering to defending coherence against the abundance of possibility. This shift became clear to me while working on an agent-native drug discovery workbench and has only become more obvious since then. The way I had described features on earlier products stopped working once the system became more dynamic and the team could prototype faster than I could enumerate every possible interaction. I realized that the scarce resource was no longer the ability to build. It was the ability to correctly decide what should exist.
A brief history
Product management started in the consumer product space with Neil McElroy's early brand-management memo at Procter & Gamble, which argued that someone should be directly responsible for whether a product succeeded, not just for its production. Software adopted the role for a similar reason. As software became a real product business, companies grew beyond the point where founders could still decide what was worth building on their own. The PM role was adopted to take over that function. The role was meant to sit between technology, customers, and the business and make decisions about what mattered, who it was for, and why it was worth doing.
Later, ideas in the Agile Manifesto tried to push teams back toward that view by emphasizing customer value and adaptation over rigid planning. But software became economically important faster than it became easy to build. Delivery stayed complex and expensive to change, which kept the cost of mistakes high and made coordination harder. Under those conditions, product managers increasingly had to define success in terms of what could actually ship. As delivery became the main bottleneck, the job shifted from asking what would make the product best in theory to asking which features had enough value to justify the team's limited time and could realistically make it out the door. That shift pulled the role beyond deciding what to build and into making sure features actually shipped.
This is the version of PMing most people still have in mind. The argument in this essay is that its central constraint, expensive shipping, is now weakening. Once that happens, the obvious next question is what becomes the new bottleneck.
The assumptions
Our foundational assumption for this essay is that shipping is no longer the main bottleneck. The rapid growth in coding agents will drive the cost to go from idea to delivered feature toward zero. As the bottleneck around building and shipping code weakens, the bottleneck will shift to decision quality. For years PMs were forced to figure out what was worth building with the limited bandwidth the team actually had. If building and shipping become trivial, the real question becomes whether you can separate the good ideas from the bad ones before the product fills up with slop. I wanted to understand just how far this bottleneck had shifted. In mid-2025, I built an agentic workout app from scratch in just two weeks. Features could be added in hours and bugs could be fixed in minutes. Not every product is this easy to build, but the cost curve has moved far enough that treating delivery scarcity as the default is no longer safe.
As building gets cheaper, buyers get more options and their own friction to build drops. Their willingness to stitch together smaller tools rises, they can change tools faster, and their tolerance for bad software falls. Once that happens, PMs no longer just have to defend what the team should build, but also why the product should exist at all.
If those two assumptions hold, the PM role does not disappear, it shifts back to its original mandate.
What changes
The first change is in the role's mandate. Cheap feature generation changes the core question from “What can the team afford to build?” to “What should actually exist?” This forces PMs into tougher judgment calls since they have to be much clearer about who the product is for, why it deserves to exist, and where its boundaries need to persist.
That is why PMs will have to spend more time focused on product coherence. In an abundant build environment, the default instinct is to build every idea anyone, including AI, mentions. That logic sounds great until the product starts accumulating individually defensible features that collectively feel like slop. Users notice whether the product feels usable, trustworthy, and right. When shipping is trivial, just having a capability stops being the differentiator. Now what matters is whether the product feels like it understands the user's workflow instead of just flooding them with options. Because of this, user research will matter more, not less.
I saw this directly on the drug discovery workbench project. Once we started working on the first dynamic agent-based features, the hard questions were no longer which fields to add, but more behavioral, such as what the system should remember, how it should adapt, and what had to remain static. Since many users were encountering an agentic system for the first time, the behavior boundaries and system defaults mattered more than the surface feature list.
The same tools that make shipping features cheaper also make research, synthesis, and prototyping much faster. These capabilities separate the PMs who use these tools to amplify their insight from the PMs who use them to replace it. The first group will turn that speed into better judgment, deeper user understanding, and tighter decisions. The second will mostly produce more output and confident-sounding bad ideas. The new pace can be so fast that, on the same workbench team, working prototypes and new model variants were often showing up within a day of us brainstorming them, well before I could fully enumerate the technical needs. That cadence forced me to stop acting as a scope bottleneck and focus instead on making sure I had enough user understanding to react quickly to new capabilities and that the team understood the user, the problem, and the boundaries.
This pace will also impact how teams perceive the PM's authority. Because these tools are available to everyone on the team, more people will show up with a built artifact, a plausible data story, and an argument for why something should ship. When the team is aligned, they’ll move insanely fast. When it is not, it becomes a direct challenge to the PM's judgment. This makes the role more adversarial. PMs will be judged less for having a point of view and more for having one that survives disagreements and proves directionally right. Because of this, a lot of PMs are going to discover they never had product authority or unique user insight.
The same pressure will also, maybe a bit more slowly, change how customers evaluate buying products. As buyers gain the ability to build or assemble their own tools, PMs have to get closer to how their product is positioned and what the buyer is actually paying for. They have to defend why the product deserves to be bought rather than built. In some cases the answer will be expertise, integrations, continuity, support, regulatory compliance, or liability transfer. If a PM cannot clearly articulate what the customer is buying beyond features they could cheaply clone, the product likely should not exist at all.
Once PMs shift from managing delivery scarcity to defending judgment and coherence, the artifacts they author have to change too. The roadmap becomes more of an investment thesis and less a list of promised features. Its job is no longer to enumerate every feature the team will build, but to explain why a problem space is worth attacking, why it matters now, and where to draw the boundary. The PRD changes in the same way. It becomes less a fixed specification and more a decision document built around guardrails and evaluation criteria. It focuses on clarifying product behavior, especially how user behavior shapes the experience, what success actually looks like, and what must remain stable. Its scope also broadens as it frames the larger problem the team is trying to solve and the constraints that should shape its features. I learned this the hard way while trying to use a traditional PRD to describe agent capabilities for researchers and finding that I could never capture all the edge cases. Things became clearer once we rewrote the spec section as a behavioral profile describing the agent's temperament, interaction style, and limits. I also saw that this change expanded the PRD to frame the full problem rather than a single milestone.
To supplement the PRD, PMs will now be expected to build prototypes and assemble evaluation sets. Because building is cheap, teams will expect interactive and testable artifacts, not more polished documents. To know whether features are actually solving the target problem, the PM will need to build and own the evaluation set. I learned this while building NLP-based products, where curating my own eval sets made it possible to spot drift as models changed, including cases the team missed.
Many of these “new” responsibilities already sit within product management, but work that used to be secondary or reserved for executives will increasingly become central to the IC PM role.
Second-order impacts
Once the PM has defended what ideas are worth making real, the next challenge is managing what happens as those ideas accumulate in the product. This is where the role starts looking less like feature planning and more like alignment management.
A surprising amount of that work will come down to preventing metric distortion and local optimization. Rapid building, deployment, and iteration make it easier for teams and features to optimize against weak metrics. If the success metrics are naive, they will be hacked. PMs will need to spend more time on metric design, counter-metrics, and failure-mode analysis. A green dashboard can easily hide a product that is getting worse for users.
Defaults also become a differentiator. In a world drifting toward feature parity, products will increasingly win or lose based on their default behavior. PMs will have to shape the product's judgment much more deliberately. The difference between a good product and an annoying one usually comes down to default behaviors, not features. Good products step in at the right moments, stay out of the way when they are not needed, and leave the user in control when it matters. When those defaults are right, the product feels like a natural extension of the workflow. When they are wrong, it feels noisy, creepy, or generic. We ran into this directly when deciding what the system should suggest, what it should expose, and what it should keep behind a harder boundary. We found that because most users were encountering an agentic product for the first time, we had to dial down the automation, increase assistance, and preserve more user control.
How PMs handle all these changes will also drive the market to split. The next wave of products will likely fall into three classes: vision-led products, derivatives, and feature slop. Additionally, cheap building will make room for new features that were previously too simple or too complex to build profitably. In this new wave, the common failure mode will not be missing features. It will be too many. Since shipping is easy, the hard part becomes adding capability and variability without degrading the product. The companies most obsessed with shipping velocity will be the ones most likely to walk straight into this trap.
Should PMing still exist
If this is where the market is headed and the role is shifting this much, it is fair to ask whether the PM role even needs to exist.
In one sense, no. The version of PMing built around managing delivery scarcity will no longer be needed. A role built to squeeze features through expensive engineering cycles becomes unnecessary once shipping gets cheap. As the delivery bottleneck weakens and tracking is automated, the work built to manage that constraint becomes unnecessary. But this does not mean the role should disappear, just that it should return to its core value.
For PMs inside larger software companies, this means the role will shift away from delivery management toward a focus on vision and coherence. Some PMs will move to the buyer side, where they stay close to the user and shape decisions about what to stitch together, what to build, and what actually merits buying. Other PMs will be part of the wave of founders starting new, leaner companies where a tiny team using agents can hold the thesis, set the boundaries, and keep the product coherent without layers of internal PMs.
So PMing should not disappear. It should move upward in responsibility and outward across the market. This broadening across the market may even increase demand for the people who actually know users well and can maintain product coherence. As team productivity rises, the scarce skill is no longer pushing work through a process. It is steering that new abundance toward something that deserves to exist.
Let's not
PMs are currently rewarded for getting things built. As shipping gets easier, success as a PM will shift. The job will become less about generating motion and more about deciding what deserves to exist, what must be measured, what must be constrained, and what should never ship. The best PMs will not be the ones with the most ideas or the cleanest process. They will be the ones who can keep the product coherent and the team aligned while everyone around them can generate software quickly and cheaply.
That brings the role back to where we started. Product management was created to know your user well enough to make judgment calls under delivery constraint. That constraint is changing, but the need for judgment and user understanding is only increasing. In an age of abundance, product judgment will come down to preserving coherence and knowing, when asked to add a feature, when to say clearly, “let's not.”