The problem

Cheap AI-assisted development broke the intake funnel PM practice was built around. The old model assumed the PRD came first: an idea got written up, prioritized, and only then built, because engineering capacity was the scarce resource doing the filtering. Now anyone can prompt a working prototype into existence before a PM ever sees a request — and that prototype can already be touching systems of record, storing customer data, or quietly running in production. The artifact entering the product conversation is no longer a request to evaluate, it’s a fait accompli to classify.

This isn’t just a solo-founder problem. Enterprises are accumulating what one of the source articles calls a “prototype graveyard” — AI-generated tools built by individual employees or teams, outside any intake process, that nobody has decided to keep, promote, or kill. At the same time, the economics are shifting hard enough that the org chart itself is being repriced: companies running AI-native teams are posting 3-5x the revenue-per-employee of traditional SaaS orgs, and backlogs of “would save 200 hours a year but cost 2,000 to build” internal tools are suddenly worth building. A PM function still organized around gatekeeping scarce engineering time is structurally unequipped for either problem.

The approach

This is a course, not a piece of software, and it’s built the way the rest of my content pipeline works: I don’t start from an outline, I start from a curated set of real source material and let the argument emerge from it. The seed here is a Substack piece on product management under cheap software governance, plus two supporting pieces on AI-native org economics and on context-engineering as a management skill — each one run through my Substack-to-course-ideas pipeline, summarized, and distilled into standalone idea entries with their sourcing kept intact.

The course’s spine is a reframe: PM work splits into two frameworks for handling AI-generated artifacts that show up already built — a Prototype Classifier (what is this thing, what does it touch, is it safe) and a Demotion Audit (does it get retained as-is, promoted to a real system, or retired). Around that spine, the working modules pull in the two adjacent ideas already captured: how revenue-per-employee and headcount economics are being repriced at companies like Klarna as agents take over functional work, and why writing a self-contained, assumption-free prompt for an AI is the same discipline Tobi Lütke credits with making him a better CEO — because AI, unlike a two-year colleague, doesn’t fill context gaps for you.

At this stage the project is a curated idea library with sourcing and a clear thesis, not a finished curriculum — next step is turning these three idea threads into an actual module sequence with exercises.

What I learned

The clearest thing that came out of researching this is that “shadow IT” and “PM gatekeeping” used to be two separate problems with two separate playbooks, and AI-assisted development just merged them into one. When building software required real engineering time, unauthorized tools stayed small and rare because building them was expensive. Once the cost of producing a working prototype collapses, the volume of ungoverned artifacts stops being an edge case and becomes the default flow of how products get made — which means the classification and audit step can’t be a periodic cleanup exercise, it has to be a standing discipline.

Where this could go

The natural extension is treating this less as a course about individual PM judgment calls and more as a governance framework an organization could actually adopt: a lightweight intake-in-reverse process where any AI-built tool that touches real data or a real workflow gets run through a classifier and a demotion/promotion decision on a cadence, the same way security teams run periodic access reviews. Paired with the org-economics thread, there’s a second course-length argument here about what PM headcount and role definition should look like inside an AI-native org where the scarce resource is no longer engineering hours but well-specified problems and evaluation frameworks — which points toward a sequel course on restructuring PM teams around token budgets and agent oversight rather than sprint capacity.