Cheap software made your PM job harder, not easier. Here's the new job.

So, I'm really excited about this one because I feel like as a PM for a very long time, I have something to say about product management and what is happening now. And so much of what I see in training courses is around the idea that PMs are becoming prototypers. PMs are using Lovable. PMs are using Claude code. PMs are using Codex to prototype. That's fine. I don't think that is the heart of where product is going. I think that's just table stakes at this point. And so, I want to have a deeper conversation with my fellow PMs about what is happening in our discipline and how we need to change and evolve in the age of AI because I think the prototyping advice is oversold and we need to be very deliberate about what we're doing because it comes back to the same idea that I've been kind of really sitting with, which is the idea that AI makes generation easier. So, it moves the bottleneck and we need to be very intentional about how we leverage human expertise from there to make sure that we are effective with our intelligence, our scarce human intelligence, and we drive what really matters for the business. If you're wondering what AI looks like at a big company, Microsoft has a story for you. They have built more than 1 million Power Platform assets inside the company. Power Platform is what they call their sort of AI tooling, right? That includes more than 18,000 different robot environments or agent environments, 170,000 Power Apps, 50,000 Power Automate flows, and 1,200 chatbots. The obvious story here is that low code and AI are letting more people build software, right? The real story is that product management is moving from rationing scarce engineering to classifying and strategizing with software abundance. That matters because the thing arriving in the product conversation is no longer just a request in most cases. It's often a working artifact. It's a dashboard, a workflow, a lightweight app, a local automation, a customer-facing prototype, maybe an agent that already touches the system of record. So, the old product question was should I even build this? The new product question often starts a step later. Somebody already built something, now the company has to decide whether it should matter and and sense make out of it. This is the PM shift that I want to talk about today. It is becoming the discipline that classifies software abundance into market value, internal tooling that's useful, or that decides to delete it. And that's a much more strategic job. It's also a much more technical job. The best PMs in the next few years will not be ticket brokers. They will be people who understand markets and users and workflows and technical systems and data and evals and permissioning and cost and reliability and trust well enough to decide where software abundance ought to be pointed. There is not much room left for the non-technical PM. I don't mean every PM has to become a full-time engineer. I mean AI products are technical systems and the technical aspects of AI are profoundly determinative of their overall behavior. So, we need to understand them well to work with them. Product decisions now involve model behavior and agent loops and data access and workflow boundaries and retrieval and evaluation and latency and cost and permissions and failure modes. A PM who cannot reason about those things is missing the product. At the same time, AI does not empty human value out of the product work. It actually just shifts the bottleneck. 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. So, the old PM job was really built around scarcity. Product rituals make sense when software is expensive, so PRDs and roadmap reviews and planning cycles and launch checklists, prioritization meetings, all of that is built around slow work so that engineering time is consumed deliberately. That was the whole point. When software is expensive, the company needs a filter, the PM is the filter. You can't afford every stray idea. You can't afford every department cloning the product, and the PM had to run the filter. AI kind of destroys that filter because it changes what people can produce before they ever reach product and engineering. And so the top of the funnel used to be words, and it used to be mock-ups and spreadsheets and persuasion, but now it's got working tools and dashboards and automations and agents and half real products, like zombie products, right? A product leader can no longer wait passively for polished business cases in that world. The useful signal may already be running inside a team along with a lot of noise that isn't useful. So, what you need to do in that world is not to shut it down. I hear a lot of PM instincts to say, "Well, our job now is to prototype." And nobody else's. No, everybody's job is to prototype. The local automation makes full use of platform gap. A messy agent may show that customers want an outcome the official product doesn't support, and maybe the customer service rep built that, not the PM. So, you need to understand where the good ideas in your org are coming from in the form of artifacts and prototypes. 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 has to hold both ideas at the same time. Let more people build and decide carefully what the business will rely on. The world is producing more software-shaped work than product organizations were ever built to evaluate. The same pattern is happening inside companies, right? Microsoft's internal Power Platform ecosystem is a great example here. More than a million citizen development assets inside one company with governance built around inventory and telemetry and permission review and environment controls and data policy. Microsoft didn't share all of this as a reason to stop employees from building. Instead, it presented governance as a way to let employees build while protecting the company. GitGuardian's 2026 state of secret sprawl report says AI service secrets exposed on public GitHub reach 1.2 million in 2025. It's up farther now. It was up 81% year-over-year in 2025. It's going to climb another 80 or 100% this year, I bet you. Faster creation means those mistakes. It 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. The question is what data does it touch? What systems does it write to? Who owns it? Those are now product questions, not just engineering questions, and they require more of our technical market judgment, not less. It's It's so easy to hear all of this as an internal tooling problem. But that would make the world too small. Cheap software makes PMs more responsible for market judgment, and that includes judgment from the market around all of our tooling inside and outside the business. But now first versions are really cheap, and so the question for us becomes really sharp. Why are we building this at all? The PM has to understand the market well enough to aim production successfully. Which customer problem is really worth solving here? Which workflow is close enough to money and retention and trust so that it's forming a really good habit with customers. Which competitor feature is just noise? Which customer request is a symptom of a much deeper issue? Which internal prototype reveals real demand, and which one is just local convenience for one team? That's not product management. That is product judgement. So, what does the new job look like in practice? Let's start with 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 road map all sprout up together. That space is messy, but it's really valuable. It reveals hidden demand and missing platform primitives and customer pain and internal workflows that the official product process has not yet understood. But, a common 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. So, within that context, I think the better posture for PMs to adopt 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? Then, use a production class ladder. A production class ladder has a few rungs that help you make sense of this messy prototype commons and apply your PM judgement in ways that encourage innovation rather than discourage it. So, let's start with personal tools. A personal tool is for one person, right? It can be scrappy. It should stay away from sensitive data unless the company has rules for local handling. And, it's something that you don't have to have a lot of other standards around. Go up a level. A team beta is used by a small group. It will need an owner. It will need a backup owner. It should have a short description. It should talk about the systems it touches, why it benefits the team, and there should be a failure plan. Go up another level. A supported internal product is software the company does depend on. It does need product ownership. It needs platform partnership. It needs access management and monitoring. It needs documentation and support and auditability and a change process. It's much more serious. A customer-facing product or a feature is part of the company's external process. This is the fourth rung on the ladder. It needs the usual product standards plus AI-specific evals and governance where the surface requires it. And the important point is that 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, right? In the old model, PMs decided what entered engineering and that is what became supported and that's what became official software. In the new model, PMs also decide what gets promoted out of the prototype comments. And demotion matters just as much as promotion here, right? 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 that nobody wants to own. So, 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. And that is a real PM shift because if you don't do that, the company will pay support cost on dead software faster than it can name it. That is the new tech debt. And so the product conversation has spent a lot of time on how fast AI can move an idea to a prototype. And I hear that over and over again from PMs. That was useful. It showed us that the cost of first versions have collapsed and we get to play a part in that as PMs. I think the next question matters more. What happens after the prototype exists? 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 better answer is a default allow system for experimentation and a very very intentional promotion path governed by product for work the business will rely on. And so that's the decision rule I recommend. If you're a PM, 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? That's the new product job. In the meantime, keep your head up as a PM. This is an incredibly exciting time to be in product. For so long, we've had to say we can't build everything. Now we finally get to play the other side of the game board. We get to say we can build everything. What should we build? And I love that we get to challenge of exercising our judgment. So be the PM that is post-prototype. Figure out how to use your judgment to build a true production class ladder to help your organization channel its creative energy to build what matters for customers. I'll see you next time. Cheers.