Date: 2026_05_29 Source: https://www.youtube.com/watch?v=b6J387xJvHg Duration: 758 Platform: YouTube Creator: AI News & Strategy Daily | Nate B Jones
Cheap Software Made Your PM Job Harder, Not Easier. Here's the New Job.¶
Executive Summary¶
The "PMs are becoming prototypers" narrative is oversold — it's table stakes, not the heart of where product is going. AI makes generation easier, which moves the bottleneck. The scarcest thing is no longer the first version — it's great judgment about what ought to exist, what ought to be deleted, who the product is for, the standard it needs to meet, and what the company is willing to bet on. The PM function is shifting from rationing scarce engineering to classifying and strategizing with software abundance. The production class ladder — personal tools → team beta → supported internal product → customer-facing product — is the operating framework for this new world. Demotion matters just as much as promotion. "A ladder that only moves upward is going to become a junk drawer."
The Microsoft Example¶
Microsoft has built more than 1 million Power Platform assets inside the company, including: - More than 18,000 robot/agent environments - 170,000 Power Apps - 50,000 Power Automate flows - 1,200 chatbots
The obvious story is that low-code and AI are letting more people build software. The real story is that product management is moving from rationing scarce engineering to classifying and strategizing with software abundance. The thing arriving in the product conversation is no longer just a request — it's often a working artifact: a dashboard, a workflow, a lightweight app, a local automation, a customer-facing prototype, maybe an agent that already touches the system of record.
The Old PM Job vs. The New PM Job¶
Old question: "Should I even build this?" New question: "Somebody already built something. Now the company has to decide whether it should matter and make sense out of it."
The old PM job was built around scarcity. Product rituals make sense when software is expensive — PRDs, roadmap reviews, planning cycles, launch checklists, prioritization meetings. All of that is built around slow work so that engineering time is consumed deliberately. When software is expensive, the company needs a filter. The PM was the filter. You can't afford every stray idea.
AI destroys that filter because it changes what people can produce before they ever reach product and engineering. The top of the funnel used to be words, mock-ups, spreadsheets, and persuasion. Now it's got working tools and dashboards and automations and agents and half-real products — "zombie products."
The Scarcity Reversal¶
When software production gets cheaper, the scarcest thing is not the first version, the first prototype. The scarcest thing is great judgment about what ought to exist, what ought to be deleted, who the product is for, the standard it needs to meet, and what the company is willing to bet on.
There is not much room left for the non-technical PM. AI products are technical systems, and the technical aspects are profoundly determinative of their 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.
The Secret Sprawl Problem¶
GitGuardian'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. 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 question is not only whether a prototype seems useful — it's what data does it touch, what systems does it write to, who owns it. Those are now product questions, not just engineering questions.
The Prototype Commons¶
The prototype commons is the informal space where new tools appear before the company has classified them — where scripts and dashboards and agents and automations and half-real products built because employees can finally solve problems that never made it onto a roadmap all sprout up together. That space is messy, but it's really valuable. It reveals hidden demand, missing platform primitives, customer pain, and internal workflows the official product process has not yet understood.
But a commons still needs stewardship. If nobody owns it, useful work stays invisible and risky work spreads without the right support. If a product shows up only to say no, employees will start hiding useful tools until something breaks.
The Production Class Ladder¶
The framework for classifying software abundance:
Rung 1 — Personal tools: For one person. Can be scrappy. Should stay away from sensitive data unless the company has rules for local handling. No lot of other standards needed.
Rung 2 — Team beta: Used by a small group. Needs an owner, a backup owner, a short description, systems it touches, why it benefits the team, and a failure plan.
Rung 3 — Supported internal product: Software the company does depend on. Needs product ownership, platform partnership, access management, monitoring, documentation, support, auditability, and a change process. Much more serious.
Rung 4 — Customer-facing product: Part of the company's external process. Needs the usual product standards plus AI-specific evals and governance where the surface requires it.
The important point: These are very, very different classes and we shouldn't mix them up. The first version of a thing and the supported version of a thing don't have to be the same.
Demotion Matters Just as Much as Promotion¶
A ladder that only moves upward is going to become a junk drawer. Everything eventually gets to production or gets to some kind of support level, and it's just a pile of old obligations nobody wants to own. You need to think about what kinds of customer promises you want to make in production, what kinds of customer promises you want to make internally, and where you want to leave the rest to be intentionally demoted or left at the personal software level.
"That's the new tech debt." The company will pay support cost on dead software faster than it can name it.
The Decision Rule¶
Stop asking only whether your team can build faster. Ask what class of software you're looking at: - Is it a personal tool? - Is it a team beta? - Is it a supported internal product? - Is it a customer-facing promise?
Then ask the harder question: Should this exist? Who is it for? What standard does it need to meet and what are we willing to rely on?
The Better System¶
The better answer is a default allow system for experimentation and a very intentional promotion path governed by product for work the business will rely on.
If the answer is "we don't know, we don't have a plan" → the company gets a graveyard of demos. If the answer is "everything goes to production" → the company gets chaos. If the answer is "only central product and engineering may build" → the company wastes a ton of creative capacity that AI just unlocked.
The Strategic Shift¶
For so long, PMs have had to say "we can't build everything." Now they finally get to play the other side of the game board: "We can build everything. What should we build?"
The PM that is post-prototype uses judgment to build a true production class ladder to help the organization channel its creative energy to build what matters for customers.
🦐 Summary by Thrawn the Prawn — Strategic Analysis Division