The Expanding PM: Why Product Managers Must Own the Company's AI Knowledge Layer

The Coordination Illusion

When I was scaling an R&D organization from 30 to 150 developers at a digital bank, the bottleneck was never the engineers. They could write code. The bottleneck was alignment - specifically, the growing gap between what the product was supposed to be and what individual developers understood it to be on any given Tuesday morning.

The onboarding program I built was, in part, a knowledge transfer machine. New engineers needed to understand not just how the system worked but why it worked that way - what decisions had been made, what constraints were real versus historical, and what the product vision actually meant at the level of a feature's edge case behavior. When that knowledge lived in tribal memory, scaling broke it. When we built it into structured documentation, scaling became possible.

That experience did not involve AI agents. It barely involved LLMs. But the problem it surfaced is exactly the problem that the AI era has made ten times more urgent: structured, queryable product knowledge is organizational infrastructure, not documentation overhead.

The product manager is typically described as a coordinator - the person who bridges engineering, design, and business. This framing is accurate as far as it goes, and it undersells the role by approximately a factor of three.

The PM is not a coordinator. The PM is the organization's most concentrated point of product truth. They hold the user research, the business logic, the product vision, and the constraints that bind all three together. They are the person who knows both what the product does and why it should do it - the only person who holds that intersection consistently.

In a company without AI, that concentrated knowledge mostly flows through meetings, documents, and the PM's own judgment in real-time discussions. In a company with AI agents writing code, fielding support queries, and generating marketing content, that same knowledge becomes the input layer for every system the company runs. And most companies have no one formally responsible for maintaining it.

That is the problem this article is about.

The Hidden Job: Knowledge Architecture for AI

Ikujiro Nonaka and Hirotaka Takeuchi, in their 1995 study of how Japanese organizations create and sustain competitive advantage (The Knowledge-Creating Company), introduced a distinction that has become more important with every passing year of AI development: the difference between tacit knowledge - what people know but cannot fully articulate - and explicit knowledge - what organizations have converted into structure, language, and form that others can learn and act on.

Their core finding: sustainable competitive advantage comes not from holding tacit knowledge but from the processes by which organizations externalize it - converting the knowledge in individual heads into institutional structure that persists, scales, and transfers. Organizations that externalize well compound. Organizations that depend on individual tacit knowledge plateau and fragment when key people leave.

In 1995, externalization meant documentation, process manuals, training programs, and design methodologies. In 2025, it means those things plus structured data layers that AI systems can query. The PM, as the organization's most concentrated carrier of product truth, is the natural owner of this externalization process.

What does this look like in practice?

The failure mode without this is one most product teams know intimately: AI coding assistants that produce technically correct but product-incoherent code. Support bots that answer questions about features that no longer work the way the documentation describes. New engineers who make reasonable decisions that contradict product principles nobody ever wrote down. Marketing content generated from an LLM that is factually accurate about the product but tonally and strategically off.

All of these failures trace to the same root: the AI was not wrong. It just did not have access to the right knowledge. And nobody was responsible for ensuring it did.

This is the PM's job. Not because it was always listed in the job description - it rarely was - but because the PM is the only role in the organization that touches all four knowledge layers simultaneously. Assigning it anywhere else produces a worse outcome.

Andy Grove wrote in High Output Management (1983) that the output of a manager is not what they personally produce but the output of the organization under their influence. Applied here: the PM's leverage in an AI-augmented company is not the product decisions they make in meetings. It is the quality of the knowledge architecture that enables every other decision - made by developers, agents, support teams, and marketing systems - to be a good one without the PM being in the room.

The Research Layer Has Already Changed

In Continuous Discovery Habits (2021), Teresa Torres makes the case that product discovery should not be a phase or a project - it should be a continuous operational rhythm, with weekly customer touchpoints, regular assumption testing, and a living map of user opportunities that the whole team can see and build against. The model was already the standard for strong product teams before AI. It remains the standard. What has changed is the scale at which it is achievable.

The cognitive overhead that made "weekly customer interviews" feel aspirational rather than achievable at a stretched PM is collapsing. AI-assisted research tools can now transcribe and theme qualitative interviews at scale, surface patterns across hundreds of support conversations, identify language gaps between how users describe a problem and how the product addresses it, analyze competitive positioning from public content, and generate provisional persona updates from behavioral signals in near real-time.

The work that used to require a dedicated UX researcher, a research ops function, and a two-week synthesis sprint can now happen weekly - if the PM has the tools and the discipline to run it.

The judgment layer - deciding which insights actually matter, separating real user needs from stated preferences, identifying which problems are worth building for - remains irreducibly human work. AI can find patterns. It cannot decide whether a pattern represents a real market opportunity or a vocal minority. That distinction requires context, experience, and skin in the game. It requires, in short, a PM.

McKinsey's June 2023 report on the economic potential of generative AI estimated that it could add between $2.6 trillion and $4.4 trillion in annual value across 63 use cases. A significant portion of that value accrues to knowledge work - specifically the synthesis, structuring, and application of large amounts of qualitative information, which is exactly the work that currently makes continuous discovery difficult for stretched PMs.

The PM who builds the research capability now - continuous discovery habits augmented with AI synthesis tools - will operate with a level of customer intelligence that was previously available only to companies with large, dedicated research teams. The PM who waits will be two years behind on a compounding advantage.

The Four Absorptions Already in Progress

The conversation about AI eliminating jobs tends to focus on entirely new capabilities replacing entire roles. The more accurate picture, at least in product teams right now, is subtler: AI is eliminating the execution overhead of several roles while leaving their strategic core intact. The strategic core of those roles was always adjacent to - or inside - product thinking. When execution overhead shrinks, the case for separating these roles from the PM brief weakens considerably.

PM Absorbing Project Manager

The distinction between a product manager and a project manager has always been somewhat artificial, and at most fast-moving companies it was already thin. The PM owns the "what" and "why." The project manager owns the "when" and "how well it is coordinated." In practice, strong PMs were always informally doing both - the project manager role often existed to provide bandwidth, not a distinct strategic function.

AI-assisted project management tools are now handling the execution overhead that made the separate role defensible. Sprint planning that once required manual capacity analysis. Dependency tracking that surfaced conflicts weeks late. Status updates that nobody wrote because they took too long. Risk logs that were created and never maintained. All of this is tractable with AI-augmented tooling that any capable PM can run with 20% of the time it previously required.

What remains of project management is strategic delivery ownership - knowing what ships in what order, why, and what the tradeoffs are. That is the PM's core brief. The execution layer around it no longer requires a dedicated role at most stages of company growth.

Marty Cagan, in Empowered (2020), argues that the defining characteristic of truly empowered product teams is that they are accountable for outcomes, not outputs. The shift from output accountability (did we ship the sprint?) to outcome accountability (did we move the metric?) has always been a PM-owned shift. The project management layer that focused on output tracking becomes less relevant as delivery tooling absorbs its execution cost.

PM Absorbing Designer

This is the more contested absorption, and rightly so. Design is not just execution - it is a discipline with deep craft knowledge about visual language, accessibility, interaction patterns, and user psychology that takes years to develop. The argument for PM absorbing design is not that the craft disappears. It is that the execution layer of design - the wireframing, the responsive layout generation, the component variant production - is increasingly handled by AI, and what remains is exactly the design thinking that PMs were always supposed to bring.

Figma's AI feature suite, launched in 2024, auto-generates wireframes from text descriptions, produces responsive layout variations, suggests component usage, and generates design alternatives based on existing system rules. This does not replace a senior designer's system-level thinking. It does make the PM who used to wait two weeks for a wireframe capable of producing a testable prototype in a day.

The relevant question is not "can AI replace designers?" - the answer is clearly no for mature, complex product systems where design craft is a genuine competitive differentiator. The relevant question is "at what stage of company growth does a dedicated design function justify its cognitive overhead?" and "for the PM who cannot get design resources, what can AI tools now make possible that was previously impossible?"

Both answers are moving rapidly in the direction of PM-led design direction, supported by AI execution, for a larger range of companies and contexts than was true two years ago.

PM Absorbing Research Director

This is the absorption that should already be complete in every product organization, but almost never is. Research is the PM's job. The argument that it belongs to a separate function rests entirely on execution overhead - the cost of recruiting participants, running interviews, synthesizing findings, and maintaining research artifacts. As AI compresses that overhead, the case for separating research from PM decision-making collapses.

The PM who runs continuous discovery - weekly customer touchpoints, regular qualitative synthesis, live assumption testing, behavioral data interpretation - produces better decisions than the PM who commissions a research project and waits for a report. This was true before AI. AI makes it achievable for a far larger number of PMs than previously had the bandwidth.

Critically: the research that happens inside a PM's own practice, connected to their daily product decisions, compounds differently than research delivered from a separate team. When the PM runs the interview, the insight arrives in a context where the PM already holds all the relevant product constraints. The connection between what the user said and what should change in the product is immediate. When research travels through a hand-off, something in that connection degrades.

PM Absorbing Feature Development (When Developers Get Architecture Right)

This is the fourth absorption - and the most conditional. It is also the one most likely to generate the sharpest disagreement, which is precisely why it belongs in the argument.

The claim is not that PMs should replace developers. The claim is more specific: when developers invest their effort in building the right architectural foundation, a PM equipped with AI coding tools can implement product-layer feature logic directly, without a developer handoff for every business requirement.

Andrej Karpathy - former OpenAI co-founder and Tesla AI Director - named this mode of working "vibe coding" in early 2025: describing desired behavior in natural language, letting AI handle the implementation, and iterating against the output rather than against the code itself. The description is casual. The implication is structural.

Tools like Cursor, Claude Code, Lovable, and v0 have made this genuinely viable for product-layer work in well-structured codebases. "Well-structured" is the operative phrase. These tools work well when developers have built:

• Clean internal APIs that expose business logic with stable interfaces, without leaking infrastructure details that require specialist knowledge to navigate
• Composable services with clear boundaries, so a change to one feature does not require understanding the full system
• A data model and backlog system that translates business requirements into concrete, queryable, buildable tasks - so the PM's natural language intent can be grounded in the actual data model
• Infrastructure that handles the hard parts - authentication, rate limiting, data pipelines, multi-tenancy, deployment - without requiring the PM to understand or touch them
• Automated testing and CI/CD pipelines that catch mistakes before they reach production, so the PM's AI-generated code is validated by systems, not by an engineer manually reviewing every change

When developers have built this foundation, the product layer becomes accessible. The PM can translate a user research insight directly into a shipped feature without a requirements document, a sprint ticket, a developer estimate, a review cycle, and a deployment sign-off. The loop closes in hours, not weeks.

The counterargument - that PMs cannot be trusted to write production code responsibly - is addressed in the counterarguments section below. The short version: the quality enforcement is structural, not human. If the developer has built the testing and deployment pipeline correctly, the PM's AI-generated code cannot ship without passing it. The gate is not the engineer's review. The gate is the system the engineer built.

This is what it looks like when developers are genuinely measured on infrastructure quality rather than feature velocity: the infrastructure they build becomes the multiplier on every other role's output. A development team measured on how well they enable PM autonomy produces fundamentally different architecture than a team measured on how many tickets they close.

How Developers Should Be Measured Now

The velocity model of developer productivity - measuring engineers on story points, features shipped per sprint, or tickets closed per week - was always a proxy, not a measure of value. When code production was the bottleneck, velocity was at least correlated with the thing that mattered. In an era where AI coding tools can accelerate code production significantly, the proxy breaks down.

GitHub published research in 2022 showing that developers using Copilot completed assigned coding tasks 55% faster than those working without it. Set aside for a moment the question of code quality - the raw speed finding alone raises an uncomfortable question: if developers can write code 55% faster, what exactly are we measuring when we measure how much code they wrote?

The answer the research community settled on years before AI made it urgent is: you should be measuring the quality and reliability of what gets deployed, not the volume of what gets written.

The DORA Metrics

Nicole Forsgren, Jez Humble, and Gene Kim published four empirically validated measures of software delivery performance in Accelerate (2018), grounded in six years of research across thousands of technology organizations worldwide:

• Deployment frequency: How often does the team successfully release to production? Elite performers deploy on demand, multiple times per day.
• Lead time for changes: How long from a code commit to running in production? Elite performers: less than one hour.
• Mean time to recovery (MTTR): How quickly does the team restore service after a failure in production? Elite performers: less than one hour.
• Change failure rate: What percentage of deployments cause a failure requiring remediation? Elite performers: 0-15%.

The critical insight from the DORA research is that high performers on all four metrics simultaneously achieve better organizational performance - not just better technical metrics. Elite DevOps performance correlates with profitability, market share growth, and employee satisfaction. These are not developer productivity metrics that live in a technical silo. They are business performance indicators that happen to be measured in the engineering function.

The SPACE Framework

The SPACE framework, published in ACM Queue in 2021 by Forsgren and colleagues, addresses a limitation of DORA: four deployment metrics are not sufficient to capture the full picture of developer productivity, especially in a team context. SPACE adds four dimensions:

• Satisfaction and wellbeing: Developer experience as a leading indicator of every other dimension. Burnt-out engineers produce fragile systems regardless of their commit velocity.
• Performance: Outcomes produced by the system - not just outputs from individual developers but the value delivered to the organization and its users.
• Activity: Volume of actions completed - code commits, pull requests, code reviews. Useful context but dangerous as a primary metric.
• Communication and collaboration: How effectively teams coordinate and share knowledge across boundaries - specifically relevant to the knowledge architecture argument above.
• Efficiency and flow: Ability to complete work with minimal interruption, context-switching, and friction. High-flow developers produce more and produce it better.

The SPACE framework's most important contribution is its warning about Activity metrics: a developer shipping 50 commits per week that introduce technical debt is high on Activity and damaging on every other dimension. A developer shipping three carefully considered changes per month that reduce system fragility by a measurable amount is low on Activity and valuable on Performance, Efficiency, and the long-run Satisfaction of the whole team.

Matthew Skelton and Manuel Pais, in Team Topologies (2019), argue that team cognitive load is the most overlooked variable in engineering organization design. A team given too much surface area to own - too many systems, too many responsibilities, too many contexts to switch between - will underperform not because the individuals are weak but because the architecture is asking too much of them simultaneously. The developer measurement shift is, at its core, a cognitive load question: are we measuring what engineers produce in conditions that allow them to produce it well?

The 2027 PM Job Description (A Provocation)

The following is not a real job posting. It is an extrapolation of where the role is heading, based on the absorptions described above and the early signals visible at the fastest-moving product organizations right now.

To be clear: the above describes a stretched, demanding, high-leverage role that only works if the AI tools in each domain are genuinely reducing execution overhead. It does not work if the PM is expected to hand-produce wireframes in Figma, manually run project tracking, and personally transcribe user interviews. The role expansion only makes sense at the same time as the AI tooling absorbs the execution layer.

The companies already structured this way - and there are more of them than the organizational consulting literature acknowledges - are running product orgs with half the headcount of their peers and shipping faster. This is not a hypothetical future state. It is a current competitive reality.

The Counterarguments Worth Taking Seriously

This article would be dishonest if it did not steelman the strongest objections. There are four.

The Craft Depth Objection

Senior designers bring more than execution. They bring deep craft knowledge - visual language, accessibility, information hierarchy, the psychology of visual attention - that takes years to develop and cannot be described to an AI tool by a PM who does not have it. Collapsing the design role into a PM's brief risks replacing craft with competent mediocrity.

This objection is strongest at mature product organizations with complex, differentiated design systems - where visual language is a genuine competitive moat. At a Series B SaaS product with a standard design system and a competent PM who can direct Figma AI sensibly, the objection is weaker. The argument for PM-led design is scale-specific and context-specific. It is not universal.

The Cognitive Overload Objection

This is the strongest objection and deserves the most honest treatment. Adding knowledge architecture, research direction, design direction, and delivery ownership to the PM brief does not create a better PM. It creates an overwhelmed one who does everything at a level of depth that serves nobody well.

The honest answer: this role expansion only works if AI tools are genuinely reducing execution overhead, not just adding new tasks. If the PM is expected to maintain a knowledge graph manually in a markdown wiki, hand-produce wireframes, and personally run project tracking with a spreadsheet, the expansion makes the role untenable. The expansion is contingent on the execution infrastructure keeping pace with the responsibility surface.

Organizations that adopt this model without building the supporting AI tooling first are not making the PM role more powerful. They are setting a good person up to fail.

The Accountability Clarity Objection

When the PM owns everything, who is accountable when design fails? When a deadline slips? When research was misleading? Shared accountability and total accountability often look similar and perform very differently. Total ownership, the objection runs, may just be everywhere-accountability that means nowhere-accountability.

The response here is that in most product organizations, the PM already carries this informal accountability. When something ships badly - even when designers and project managers were nominally responsible - the PM is who the organization looks to for the explanation. Formalizing the accountability would clarify the expectation, not change the reality of how it currently works.

The Code Quality Regression Objection

If PMs are writing feature code with AI tools, who catches the edge cases? Who ensures the code is maintainable a year from now? Who prevents the PM from accidentally introducing a security vulnerability, a data race, or a performance regression that manifests six months after they shipped the feature?

This is the most technically grounded objection and the one developers most frequently raise when this argument is put to them. It deserves a precise answer rather than a dismissive one.

The answer is: the same systems that catch these problems when junior developers write code with AI assistance. Which is to say - the quality enforcement is not human, it is structural. If developers have built the right testing pipeline, CI/CD process, API boundary enforcement, and automated code review tooling, then PM-generated code that violates quality standards does not ship. The gate is not "a senior developer reviewed this." The gate is "the system passed this."

The objection is strongest in organizations where the quality enforcement is human - where a senior developer's code review is the primary quality gate. In those organizations, PM feature authorship would indeed regress quality rapidly. But that is an argument for investing in automated quality infrastructure, not an argument against PM authorship.

There is a second, harder edge to this objection: maintainability. AI-generated code can be correct and pass tests while being architecturally incoherent - structured in ways that make future changes expensive, named in ways that confuse the next developer, and organized in ways that do not match the existing codebase's conventions. This is real. The response is that in a well-structured codebase with strong linting, style enforcement, and architectural pattern documentation, the blast radius of a PM's AI-generated code is bounded by the API boundaries the developer built. The PM operates in a defined domain. The developer owns the underlying architecture that determines how much damage an incoherent feature implementation can do.

The honest summary: this fourth absorption only works when developers have invested in infrastructure quality seriously enough that the guardrails are real. At organizations that have done this work, PM feature authorship is already happening. At organizations that have not, the objection is correct - and the right response is to build the infrastructure, not to debate whether PMs should eventually be given it.

What This Means Right Now

If you are a PM: Start building the knowledge architecture before anyone asks you to. The team that notices the agents are misaligned, the support function is working from outdated product docs, and the new engineers are making decisions based on three-year-old Confluence pages - and does something about it - will be ahead of the conversation when this becomes a formal expectation. The PM who waits for a job description to expand will be two cycles behind the PM who expanded it proactively.

If you are a CPO or VP Product: The PM headcount you have is probably the right investment direction. The specialist headcount around them - dedicated project managers in mid-stage product orgs, dedicated researchers where continuous discovery tools exist, dedicated designers at companies without differentiated visual systems - is where the ROI question is worth asking seriously. The expansion of PM responsibility is not a cost reduction play. It is a coordination reduction play. Fewer handoffs means faster decisions and less misalignment. That is worth examining regardless of the headcount implications.

If you are a developer or engineering leader: The DORA metrics and the SPACE framework are not abstract concepts. Both are instrumentable today with available tooling. Measuring your team against them surfaces a picture of software delivery performance that velocity metrics cannot. The developer who can point to deployment frequency, change failure rate, and system stability - and show the trend over time - is describing their value in terms that survive the AI era. The developer who can only point to tickets closed is not.

More specifically: start measuring developer success by how much the PM can build without engineering involvement. This is an uncomfortable metric for teams used to being the bottleneck. It is also the most accurate leading indicator of whether the architecture investments you are making are producing leverage or just overhead. A development team that has built the right foundation should be shrinking the number of requests that require a developer, not growing it.

If you are building an AI-native product team: The product knowledge graph is table stakes, not a nice-to-have. Every AI system you integrate - coding assistant, support bot, marketing content generator, customer onboarding agent - will be exactly as product-coherent as the knowledge it is given access to. Build the knowledge architecture before you build the AI features, not after you discover the AI features are generating product-incoherent outputs.

"The AI was not wrong. It just did not have access to the right knowledge. And nobody was responsible for ensuring it did."

The debate this article is trying to start is not about whether AI changes the PM role - that much is obvious. The debate is about what the change actually is, whether the PM community is treating it with the right level of seriousness, and whether organizations are restructuring fast enough to capture the advantage that is available to the ones who figure this out first.

The PM role is not under threat from AI. It is being handed more leverage than it has ever had. The question is whether the individuals in it - and the organizations around them - are willing to pick it up.

This Is the Work I Do

Operating Architecture is the discipline I practice - aligning the people, systems, and processes that actually run a company so growth scales without breaking the organization. Product team structure, knowledge management, and the PM brief sit at the center of many of the organizational reviews I run. I come in when the gap between the product's intended direction and what is actually being built has grown wide enough that the organization feels it in speed, quality, or team friction.

If this essay surfaced uncomfortable questions about your own product organization - about where product knowledge lives, how AI systems and new engineers are being aligned to product vision, or whether the PM function is being used at the leverage it is capable of - those are exactly the questions worth a conversation.

Related Reading

• The KPI Trap - Why your measurement stack may be producing the wrong incentives. Includes the DORA-SPACE alignment argument and the Goodhart's Law failure modes that hit PM teams measuring output instead of outcomes.
• The Operator-Consultant Method - How I run organizational reviews, including product team structure diagnostics.
• The AI Transformation Operator Playbook - The implementation side of AI adoption in operations - relevant for the knowledge architecture and AI agent alignment arguments above.
• Use Cases from the Field - Patterns from real organizational reviews across fintech, food services, civil engineering, and growth-stage tech companies.