AI changed who can build software. That part is obvious by now. What’s less obvious is what happens to the coordination functions inside technology organizations — product management, compliance, UI/UX design, QA — that existed because building took time. These functions grew up inside a centralized development pipeline where PMs defined work, compliance was baked in, and engineering judgment was applied by default.
That pipeline is dissolving. Engineers ship faster with AI assistance. PMs prototype tools themselves. Domain experts build internal workflows over a weekend. Building is everywhere, and when AI removes the routine work, it leaves the judgment calls. Think of it like GPS and taxi drivers: knowing every street and traffic pattern used to be the expertise; GPS commoditized that, leaving just the driving. AI is doing the opposite for coordination functions — it’s commoditizing the routine work and leaving the expertise. That’s good for the people who have the expertise. It’s a problem when someone builds something useful and doesn’t realize the expertise was supposed to be part of the process.
This piece is about what that means for product management specifically. Compliance, design, and DevOps each face their own version of this shift, and I’ll get to those separately. But Product Management is the coordination function that sat at the center of the old pipeline, so it’s the one where the dispersal is most visible — and where the question “what is this role for now?” lands most directly.
What Breaks When Nobody Applies the Product Lens
When someone, wherever they are in the org, builds something useful, they solve their own problem — often creatively and well. What they skip is everything around the problem. There’s no rollout plan — they just deployed it. There’s no thinking about downstream effects, who else this affects, or what happens to the users who now depend on it when the builder moves on. There’s no consideration of whether this duplicates a capability the product already has, or conflicts with one that’s in flight. There’s no lifecycle plan — no iteration path beyond their own use case, no real owner for the support burden it creates. They might be willing to support it, but it isn’t their primary job.
None of this means the thing they built is bad. It means the broader product judgment was never applied. I wrote about the engineering version of this pattern in Infrastructure by Adoption, An AI-Engineering First Principle — tools become infrastructure through adoption rather than decision. The same thing happens from the product side. Something becomes customer-facing, or workflow-critical, starts accumulating dependents, and the product lens was never applied because the builder was focused on their own problem. The risk isn’t that people build the wrong things. It’s that the right things become depended on before anyone has decided they should be.
The Threshold Principle
Before getting into what this means for PM, here is the principle that ties everything I’m saying together: the level of rigor should match the weight of what’s been built. That sounds simple. But in practice, it requires agreement on what counts as weight.
A tool one person uses to solve their own problem doesn’t need a PRD, a compliance review, or a design audit. A tool that three teams depend on probably does. A system that customers interact with definitely does, along with a rollout plan and compliance documentation. No matter what, you need a way to decide when a fuller set of questions should be asked and answered. Polish levels are one way to provide the shared vocabulary for this conversation — not a gate, but a common language for “how much rigor does this need right now?”
This reframes what coordination functions are for. PMs, compliance, engineers, QA, and designers aren’t gatekeepers of the build pipeline. They’re the people with the experience to recognize when something has crossed a threshold — and to help calibrate the response. The hard part isn’t applying the judgment. It’s agreeing on what counts as a threshold in the first place.
Sometimes that threshold is about complexity. Sometimes it’s user experience, or compliance, or PII. It’s hard to define cleanly in the abstract, but usually obvious when you’re looking at a real tool. The goal isn’t to review everything — that’s neither practical nor useful. It’s to make the criteria clear enough that builders can self-assess, and to be available (without taking ownership) when that self-assessment says “I think I need help with this.”
Having builders distributed across the org also distributes accountability. A builder owns solving a specific customer problem, and they might solve it in a way that doesn’t match how a PM or designer would have built it into the product.
That isn’t a failure. Cohesion and customer experience aren’t the same thing. A builder can improve CX at some cost to cohesion. But someone still has to notice when that tradeoff starts to matter. The PM (or whoever holds the lens) owns recognizing when a local win needs to be re-examined through a broader one.
There’s a real tension here that’s worth calling out. If coordination functions become “available to help” with everything builders ship, they can run into a capacity and context switching problem; they stop having time for the work they’re actually accountable for. The PM who’s answering questions from six people building side tools isn’t taking the time to keep stakeholders informed or building prototypes to inform their thinking. The compliance lead who’s fielding every “is this okay?” question isn’t answering the compliance questions that sales is waiting for. The line between being supportive and becoming support staff is real. The threshold is what protects against this. If the criteria are clear, most builders self-assess correctly and rarely need to escalate. The ones who do escalate are the ones who should be escalating. That only works if the criteria are published, taught, and trusted — which is the thing the framework actually requires.
What This Means for Product Management
Product management is one of those jobs that looks easy from the outside. Everyone who understands a problem and builds a solution thinks they’ve done the hard part — and for their own use case, they probably have. What they’re not thinking about is the 80% of product work that lives beyond their immediate problem: how does this fit into existing workflows, what does success look like beyond adoption, how do we communicate changes to people who depend on it, how do we ensure adoption, when does it need iteration, etc. They did the part that feels like product management from outside of product management. The rest is often what they don’t know they’re skipping.
This doesn’t mean PMs need to personally review every tool that gets built across the organization. PMs are already pulled in too many directions by too many people — adding “review everything the entire org builds” to their plate would just create a new bottleneck. The shift is different: PMs help define the threshold criteria. They set up the questions builders should ask to determine whether their creation needs product involvement. Where the engineering recognition checklist asks “would anything break if this went down?”, the product equivalent asks “would any user or workflow be surprised if this changed?” If the answer is yes, that’s when a PM gets involved — not to take over, but to help apply the lens the builder doesn’t have.
The other thing that’s changed is how PMs actually work. When engineering was the scarce resource, the PM’s artifact was the document — the PRD, the spec, the one-pager — because the document was how you secured engineering time and communicated what to build. Now engineering isn’t scarce, and the document isn’t the best way to develop an idea anyway. With AI building tools, a PM can produce a working prototype in the format of the existing architecture in a matter of hours. Multiple prototypes a week is now not just expected, it’s the norm.
This isn’t just a change in tooling. It’s a change in how people think and communicate. Some people think with writing and some people think with building — and AI lets PMs do both. You can think with writing, prototype the idea to see if it holds up, get feedback from SMEs faster, form opinions faster, and make mistakes faster. The PRD or spec, if you still need one, comes later to lock in the thinking after iteration (and if compliance requires it). That’s a better artifact than the one you would have written before the prototype existed, because it captures what you actually learned.
Working this way is faster — and that speed has consequences for everything built around the old pace. The tempo changed. Some of the old rituals still work at the new speed; some don’t. 2-3 week long sprints made sense when a team shipped a handful of things at a time. They’re the wrong ceremony when one PM is producing multiple prototypes and engineering is shipping continuously.
Milestones need the same rethinking. “Feature X is done” misses that “done” now means “done at polish level 2 for this outcome, and we’ll move to polish level 3 if adoption justifies it.” Milestones should represent outcomes and carry a polish level, not a binary complete/not-complete status. Engineers can ship faster; PMs need to work faster in their own way; and the rituals have to accommodate both.
All of that is new. But there’s an older part of the PM job that becomes more important, not less. PMs have long been coordinators. They did it by knowing a little bit about a lot of functions — enough engineering to know when a plan is unrealistic, enough design to know when the UX is going to trip someone up, enough about the data flows to know when to loop in compliance. That role was mostly implicit. Different PMs did more or less of it depending on their background and their org’s maturity.
When building was centralized, that implicit coordination was enough, because most of what got built went through the same pipeline anyway. Now it isn’t. The lines between engineering, product, design, DevOps, and general builders have blurred — engineers do more PM and DevOps work, PMs prototype including new designs, designers build functional things that solve engineering problems, and domain experts ship tools that all three used to be involved in. In that environment, the PM’s coordinator role has to become explicit. Lead through influence. Help the groups that didn’t previously have good access to cross-functional coordination get some of it. Route things: this needs a compliance conversation, that needs an architecture review, this other thing overlaps with what the growth team is building. PMs used to apply judgment before anything was built. Now they apply it after something proves it matters.
This is actually the part of PM work AI is worst at. Models can write a PRD, generate a prototype, draft a changelog, summarize a user interview. What they can’t do is get three people in a room to agree — manage opinions, navigate organizational politics, broker tradeoffs between competing functions, or align stakeholders who see the same problem differently. Cross-functional coordination is the work that doesn’t automate. It’s also the work that’s becoming more important, because distributed building creates more coordination surfaces, not fewer.
Done well, the coordinator role pays off in both directions. When a PM reviews something a builder created, they might recognize that it solves a problem the product team was already planning to address, or that it could improve an existing feature elsewhere in the product. And it’s prototyping in real conditions — there’s no better stress test than a tool that’s already being used by the builder under actual pressure. The builder gets product context they didn’t have. The PM gets signal about unmet needs — or more clarity on needs they were already tracking.
There’s also a canary-in-the-coal-mine element. A builder may have quietly solved a problem that’s bigger than their team, or touched on a contract, a partner relationship, or a strategic decision they don’t have visibility into. Catching that early — while it’s still a weekend tool rather than something three teams depend on — is the difference between a quick conversation and a much harder, potentially demotivating one later. The check-in is how that signal reaches the people who need to act on it. That exchange doesn’t happen by accident — it happens when the check-in is easy to facilitate and the environment feels collaborative.
What to Do About It
Your mileage will vary on which of these matters most. But a few principles are worth acting on regardless of your specific situation.
Make the criteria visible, then teach people to use them. Builders need to know what thresholds exist and what triggers involvement from Product Management (or compliance, engineering, DevOps, or design). Publish the recognition checklists. Make them short and digestible, even if they don’t cover everything at once — you need people to come to you, and they won’t if they expect to be overwhelmed. Publishing isn’t enough on its own, though. Run a short training session, walk through real examples, show people what a self-assessment actually looks like in practice and what you might do to help when they want it. Checklists that people don’t know how to use are the same as no checklists at all.
Make expertise a service, not a gate. PMs, compliance leads, engineers, and designers should be resources that builders can reach — a Slack channel, office hours, a standing check-in. The question shifts from “did you get sign-off?” to “did you get the right eyes on this?” If getting help is easier than hiding, people will get help. It also lets builders maintain ownership of what they’ve created, which matters for both motivation and ongoing maintenance.
Use polish levels to calibrate rigor, including at the milestone level. A prototype doesn’t need a PRD. A tool that customers or multiple teams now depend on does, along with a rollout plan and compliance documentation. Match the process to the maturity of the thing, not to a one-size-fits-all standard. This applies to how you define milestones too — “done at polish level 2 for this outcome” is a more clearly communicated milestone than “done.”
Lighten up the ceremonies and processes. If prototyping is multiple times a week and shipping is continuous, the old cadence of weekly sprint reviews and monthly roadmap cycles is out of sync with how the work actually happens. Keep the ceremonies that still serve a purpose; cut or compress the ones that are running on inertia.
Create visibility into what exists. If something is being used by a team, processing real data, or sitting in a workflow, it needs to be accounted for somewhere — a service catalog, a building block registry, a shared inventory. The specific mechanism matters less than the principle. You can’t apply the right lens to something you don’t know exists.
Build a culture of surfacing, not permission. This whole framework depends on people being willing to say “I built this” and the organization responding with support rather than suspicion. If surfacing what you built is met with “why didn’t you ask permission?”, you’re never going to get visibility. The response that works sounds more like: “Great. Let’s make sure it’s covered, let’s work on it together where it needs work, and you still own it.” Covered, collaborative, constructive — and the builder keeps ownership. That’s what reinforces the enthusiasm and motivation you want more of, instead of training people to stop bringing things forward.
The Role Didn’t Disappear. It Moved.
I don’t think I have a final answer to the question in the title, and I’m not sure anyone does yet. But the ideas here are where I’ve landed so far. It’s worth noticing that the frontier AI companies are hiring PMs aggressively — they aren’t shedding the role, they’re expanding it. That’s a useful signal. Product management isn’t primarily about writing requirements documents that engineers implement, or being the single throat to choke on whether something should get built. It’s about the judgment: the lifecycle thinking, the workflow understanding, the coordination across functions, the recognition of what’s worth doing and what isn’t; applied at the moments those things actually matter.
That’s a harder job in some ways. It requires defining the criteria clearly, being accessible without being overrun, and trusting that most builders will self-assess honestly. It also requires letting go of the control and comfort of owning the pipeline, because the pipeline isn’t a thing you can own anymore. But it’s also a more interesting job, because the PM’s value stops being about gatekeeping access to engineering time and starts being about applying judgment where it genuinely matters.
And here’s the thing AI is worst at and won’t catch up to soon: getting humans to agree. Writing code, generating designs, drafting documents, summarizing research — all of that is getting commoditized. Aligning six people with six different priorities and six different read-outs of the same situation is still a human job. It may be the most human job left in building software. PMs have been doing it the whole time, often without being recognized for it. The organizations that handle the AI-enabled shift well won’t be the ones with the most process. They’ll be the ones where builders know when to ask for help, where asking is easier than hiding, and where PMs are present at the moments their expertise matters most.
