Nate B. Jones, speaking as a longtime product manager, pushes back on the popular framing that the PM's job in the age of AI is to become a prototyper. He treats prototyping with tools like Lovable, Claude Code, and Codex as table stakes, not the heart of where product is going. His central claim: AI makes generation easier, which moves the bottleneck. Cheaper software does not empty human value out of product work; it shifts the scarce resource from the first version to the judgment about what should exist at all.
The new PM discipline, he argues, is to classify software abundance into market value, useful internal tooling, or things to delete. That is a more strategic and more technical job than the old one.
Jones opens with Microsoft's internal Power Platform numbers as a picture of what AI looks like at a large company:
The obvious story is that low-code and AI let more people build software. The real story, he says, is that product management is moving from rationing scarce engineering to classifying and strategizing with software abundance.
What arrives in the product conversation is no longer just a request. It is often a working artifact: a dashboard, a workflow, a lightweight app, a local automation, a customer-facing prototype, or an agent that already touches the system of record.
Jones argues the best PMs will not be "ticket brokers." They will understand markets, users, workflows, technical systems, data, evals, permissioning, cost, reliability, and trust well enough to decide where software abundance should be pointed.
He is careful: this does not mean every PM must become a full-time engineer. It means AI products are technical systems, and the technical aspects of AI are profoundly determinative of overall behavior. Product decisions now involve model behavior, agent loops, data access, workflow boundaries, retrieval, evaluation, latency, cost, permissions, and failure modes. A PM who cannot reason about those things is "missing the product."
When software production gets cheaper, the scarce thing is not the first version or first prototype. The scarce thing is great judgment about:
Traditional PM rituals (PRDs, roadmap reviews, planning cycles, launch checklists, prioritization meetings) made sense when software was expensive. They were built around slow work so engineering time was consumed deliberately. When software is expensive, the company needs a filter, and the PM was the filter. You could not afford every stray idea or every department cloning the product.
AI destroys that filter by changing what people can produce before they ever reach product and engineering. The top of the funnel used to be words, mockups, spreadsheets, and persuasion. Now it is working tools, dashboards, automations, agents, and "half-real" or "zombie" products.
Jones rejects the instinct that the PM's new job is to be the one who prototypes while no one else does. His point is the opposite: everybody's job is to prototype. A local automation may reveal a platform gap. A messy agent may show customers want an outcome the official product does not support, and the customer service rep, not the PM, may have built it.
The company needs broad building because that is where new demand becomes visible. But broad building without judgment becomes sprawl: useful work stays hidden, risky work spreads without support, and nobody knows which tools the business now depends on. The product function must hold both ideas at once, letting more people build while deciding carefully what the business will rely on.
Microsoft framed its Power Platform governance (inventory, telemetry, permission review, environment controls, data policy) not as a reason to stop employees from building, but as a way to let them build while protecting the company.
Jones cites the Guardian's 2026 State of Secret Sprawl report: AI service secrets exposed on public GitHub reached 1.2 million in 2025, up 81% year over year. He predicts another roughly 80 to 100% increase this year. Faster creation means more credentials, more local workflows, more integrations, and more places for access to leak. Product leaders inherit that problem when useful tools spread before anyone decides what class of thing they are. The key questions, now product questions and not just engineering questions: What data does it touch? What systems does it write to? Who owns it?
It is tempting to read all this as an internal-tooling problem, but that makes the role too small. Cheap software makes PMs more responsible for market judgment, inside and outside the business. Because first versions are cheap, the sharp question becomes "Why are we building this at all?" The PM must understand the market well enough to aim production:
That, he says, is not product management. That is product judgment.
The "prototype commons" is the informal space where new tools (scripts, dashboards, agents, automations, half-real products) appear before the company has classified them. It is messy but valuable: it reveals hidden demand, missing platform primitives, customer pain, and internal workflows the official product process has not yet understood.
But the commons needs stewardship. If nobody owns it, useful work stays invisible and risky work spreads without support. If product shows up only to say no, employees hide useful tools until something breaks. The better posture is open discovery: "Show us what you made. Show us the problem it solves. Who uses it? What data does it touch? What did you learn?"
Jones's central practical framework is a "production-class ladder" with distinct rungs. The key principle: the first version of a thing and the supported version of a thing do not have to be the same.
These are very different classes and should not be mixed up.
In the old model, PMs decided what entered engineering, and that became supported, official software. In the new model, PMs also decide what gets promoted out of the prototype commons. Demotion matters as much as promotion. If everything only moves up, the support level becomes a junk drawer, a pile of old obligations nobody wants to own.
PMs must decide what customer promises to make in production, what promises to make internally, and where to intentionally leave the rest demoted or at the personal-software level. If you don't, the company pays support costs on dead software faster than it can name it. That is the new tech debt.
Discussion has focused on how fast AI moves an idea to a prototype, which was useful in showing that first-version costs collapsed. The next question matters more: what happens after the prototype exists?
The better answer is a default-allows system for experimentation plus a very intentional promotion path governed by product for work the business will rely on.
For PMs, Jones's prescription:
He closes on optimism: for years PMs had to say "we can't build everything." Now they get to play the other side of the board: "We can build everything. What should we build?" Be the post-prototype PM, and use your judgment to build a true production-class ladder that channels your organization's creative energy toward what matters for customers.