The PdM Obsolescence Debate and the Rise of FDE: How AI Is Redrawing Role Boundaries in Software Organizations

• Intended readers: Anyone re-evaluating the future of their role (PdM / SE / engineer / consultant), startups considering FDE hiring, engineers working in Japanese SIer / contract development firms
• Prerequisites: Familiarity with how PdM, engineering, and SE roles are divided in Web / SaaS development organizations
• Estimated reading time: about 25 minutes

Overview

“AI will make PdMs unnecessary.” “No, AI will make engineers unnecessary.” Both framings argue for the elimination of one role or the other. But what is actually happening is not the disappearance of roles — it is a redrawing of role boundaries.

The central hypothesis is simple. As AI has dramatically lowered implementation costs, the “middle translation layer” inside organizations is being stripped away. Translating vague customer requests into something engineers can act on, and translating engineers’ technical judgments into something customers can understand — this translation function can now be absorbed directly by engineers augmented with AI.

The role rising to absorb that stripped-away work is the FDE (Forward Deployed Engineer). Embedded on the customer’s site, drawing out context, building prototypes on the spot, and even making product decisions — this model, which Palantir has cultivated since 2008, is now being adopted in lockstep by major AI-era players such as Anthropic, OpenAI, and Ramp. a16z has gone so far as to call it “the hottest job in tech”¹.

That said, “PdMs are obsolete” is a sloppy argument. Only the requirements-translation function is falling away. Strategy, prioritization, stakeholder alignment, and roadmap management remain. In fact, Andrew Ng points out that “as implementation gets cheaper, demand for people who decide what to build grows,” and even suggests the engineer-to-PM ratio could invert (from a traditional 6:1 to 1:2)². The same data is read both as “PdMs are unnecessary” and as “PdMs need to grow in number” — this seemingly contradictory situation is itself evidence that role boundaries are being redrawn.

This article examines this picture through three lenses: Palantir / OpenAI / Anthropic’s actual FDE hiring practices, Marty Cagan’s framing of PdM, and Coase’s transaction cost theory. Finally, I discuss the temperature gap with Japanese SIer organizations, and where engineers’ new moat lies.

Will the PdM Role Disappear? Separating What Falls Away from What Remains

The reason the PdM-obsolescence debate becomes sloppy is that the PdM role is treated as a single monolithic function. In practice, PdM work can be decomposed into at least the following five layers.

Layer	Content	Status in the AI era
Strategy / vision	Defining “why we build”	Remains (in fact, more important)
Prioritization	Decisions about allocating limited resources	Remains
Requirements translation	Customer requests → engineer-facing specs	Falling away
Documentation	Specs, sprint plans, progress tracking	Falling away
Stakeholder alignment	Coordinating with execs, sales, support, customers	Remains

Marty Cagan defines the essence of the PdM role as “accountability for value and viability,” placing vision, strategy, and prioritization at the core³. This definition does not waver in the AI era.

What is falling away is not Cagan’s core work, but the “translation, organizing, and documentation” auxiliary work that had clung to its edges. An AI-augmented engineer can organize requirements from customer conversation logs without help. Sprint plans can be drafted by AI and then cleaned up by the engineer. This layer no longer needs a dedicated translator.

What matters here is not to conflate the falling-away parts with the remaining parts. “PdMs are obsolete” looks at the parts falling away; “PdMs need to grow in number” (Andrew Ng) looks at the parts that remain. These are simply different facets of the same data.

What Got Stripped Off the Moment AI Made Implementation Cheap: The Structural Position of the Middle Translation Layer

The software industry has long divided roles on the premise that “implementation is expensive.” Because engineers are scarce and valuable, their time should be focused on code — and so the people who organize requirements (PdMs), the people who talk to customers (sales / SE), and the people who manage progress (PjMs) became independent specializations forming a middle translation layer.

When implementation costs drop, that premise collapses. If AI assistance raises an individual engineer’s productivity, then the economic logic of dividing labor “to protect engineers’ time from translation work” weakens. Stack Overflow’s 2025 Developer Survey reports that 84% of developers either use AI tools or plan to — AI assistance is no longer the domain of early adopters, it is an industry standard⁴.

There is one easily-missed caveat: AI is not performing translation perfectly on its own. The same Stack Overflow survey shows that 45% of developers cite “spending more time debugging AI-generated code” as their biggest frustration, and 66% report spending additional time fixing “almost-but-not-quite-right AI output”⁵.

So what is actually happening is:

1. AI produces a “first draft” of requirements translation
2. AI-augmented engineers talk directly with customers and clean up that draft
3. The economic benefit of routing through an independent “translation specialist” thins out

This is a structural shift. Translation work has not disappeared. The translation role has moved from a “dedicated middle layer” to an “engineer + AI” pair.

What FDE Really Is: The “Field-First, Prototype-First” Role with Palantir Origins

The role embodying this restructuring is the FDE. The model Palantir established in 2008 was long viewed as “a specialized job at a specialized company.” But entering the AI era, it has suddenly diffused into the industry standard.

The defining feature of the FDE is that it integrates functions that used to be divided into separate roles into a single person:

• SE (Solutions Engineer) function: embedded on-site at the customer, drawing out requirements
• Engineer function: writing code and building prototypes on the spot
• PdM function: deciding what to build and how to prioritize
• Consulting function: stepping into the customer’s business process transformation

Palantir’s official description states that a FDSE (Forward Deployed Software Engineer) is someone who “embeds with customers to configure Palantir’s existing platforms and solve their hardest problems”⁶. While a traditional engineer “delivers one feature to many customers,” an FDSE “delivers many features to one customer” — the axis of division is fully inverted.

According to The Pragmatic Engineer’s reporting, until around 2016 Palantir had more FDEs than traditional software engineers¹. This shows that Palantir’s organizational design of “not separating out the middle translation layer” has been functioning for years.

Then, in 2024–2025, this design began to spread across the industry:

• OpenAI: Started FDE hiring in early 2025. From an initial 2 people, it has now grown to more than 10 across 8 cities¹
• Anthropic: Hires FDEs aggressively on the Applied AI team. Job descriptions read “embed with strategic customers to build production applications using Claude”⁷
• Ramp: A fintech operating roughly 15 FDEs in a pod structure¹
• Salesforce, Commure, Matta, Gecko Robotics, Lindy and others — adoption is expanding across industries¹

a16z’s “hottest job” label is not hyperbole¹. At minimum, the companies running at the AI frontier are uniformly shifting toward FDE-style organizational design.

Why Anthropic / OpenAI Put FDEs at the Center: Organization Design in the AI Era

A question arises here. Why are AI vendors themselves placing FDEs at the heart of their organizations? Aren’t they exactly the ones who should be claiming “AI handles translation, so human intermediation is unnecessary”?

The answer lies in a structural limit: AI can ask questions, but it cannot weigh tacit knowledge.

Anthropic’s FDE job description lists “production experience with LLMs including advanced prompt engineering and agent development” as a required qualification⁷. It also states that FDEs are “expected to act as Anthropic’s highest-level representative in customer environments and to work autonomously under ambiguity.”

This means the company that knows LLMs best is putting a role at center stage that integrates “LLM × human field judgment.” The AI vendor itself is acknowledging that AI alone cannot fully draw out customer context — and that is precisely why it invests in FDEs to carry that responsibility.

Polanyi’s famous proposition, “we can know more than we can tell”⁸, comes back into play here. What customers truly need is often something the customers themselves cannot articulate. The work of inferring this tacit knowledge from observation, questions, and traces is not something current AI can perform independently. But with AI assistance, one human can cover a wider scope — and that is the economic condition that makes the integrated FDE persona viable.

I discussed this in more depth in The Five Layers of Context IT Engineers Should Recognize, but context is layered: “things the customer takes for granted,” “unwritten industry rules,” “internal political dynamics,” and so on. The reason FDEs are on the rise is that as AI has become capable of processing surface context, the relative scarcity value of humans who can draw out deep context has risen.

The Engineer’s New Moat: From “Implementation Speed” to “Context Extraction”

From here, the implications for individual engineers become clear. In a world where implementation is cheap, the engineer’s moat (barrier to entry, source of competitive advantage) moves from implementation speed to somewhere else.

Old moat	New moat
Writing code fast	Articulating the customer’s tacit knowledge through questions, observation, and traces
Knowing many algorithms	Validating hypotheses through prototypes
Designing architectures	Making product and prioritization decisions autonomously
Mastery of languages / frameworks	Giving appropriate instructions to and evaluating output from AI
Writing careful documentation	Resolving ambiguity through direct stakeholder conversation

One caveat. Stack Overflow’s 2025 survey shows trust in AI tools dropped to 29% (down 11 points year over year)⁴. Having delegated implementation to AI, engineers have shifted to the evaluator side. That evaluation work — code review, hallucination detection, cross-checking against requirements — still requires human expertise.

In other words, it is not that “implementation skills become unnecessary.” Implementation skills remain as a prerequisite for evaluating AI output, with “context extraction” and “product judgment” stacked on top.

I discussed this in A Junior Engineer’s Vibe Coding Productivity Guide and The AI Delegation Paradox, but the shift is especially harsh for junior engineers. It is hard to acquire “context extraction” alone while implementation experience is still shallow — because you cannot evaluate AI output.

PdM Survival Strategies: Three Directions to Compensate for the Lost Translation Function

What about survival strategies for PdMs? The core work Marty Cagan defines for the PdM³ — strategy, prioritization, stakeholder alignment — remains, but something else has to deliver value in place of the lost translation function.

Three directions seem most plausible:

Deepening into strategy and vision

Deciding “what to build next” is hard to replace with either AI or an FDE. Market analysis, competitive analysis, customer segment design, multi-year roadmaps — these are judgments operating on multi-year time horizons, qualitatively different from on-the-spot tactical decisions in the field. If FDEs handle tactical field judgment, the PdM scales up to organization-wide strategic judgment — that division of labor holds together.

Deepening into stakeholder alignment

Executives, sales, support, legal, compliance, partner companies — coordinating multiple stakeholders is too heavy a load for an FDE (the nature of customer embedding caps bandwidth for internal politics). PdMs remaining as in-house coordination specialists is a viable direction.

Deepening into metrics and experiment design

A/B test design, cohort analysis, retention design — data-driven decisions still require human judgment. The role of deciding what to measure and how to interpret it, even while delegating analysis to AI, remains.

What I want to flag here is that all three directions are “upward deepening” into PdM higher-order functions. If the response to the lost translation function is “do more meticulous translation,” it cannot differentiate from AI-augmented engineers. But if it commits fully to higher functions — strategy, alignment, experiment design — it can coexist with FDEs.

The Temperature Gap in Japanese Companies: SIer Structure and Friction with the Shift to FDE

The discussion so far has focused mainly on U.S. startups. In Japanese companies, especially SIer and contract-development organizations, the situation is quite different.

The structural traits of Japanese companies fall into three points:

1. The PdM concept is shallow. The very idea of “someone who owns the product” has trouble taking root in an SIer / contract-development model. Requirements are issued from the customer side, and the SIer tends to be a collective of “people who just build.”
2. Multi-tier subcontracting. Prime contractor → first-tier subcontractor → second-tier subcontractor, and so on — the translation layer is piled in multiple strata. Each layer makes its living from the translation function.
3. Weak requirements-definition capability on the customer side. “Customers who cannot articulate requirements” are common in Japan. The very structure of SIers translating on the customer’s behalf creates strong inertia against AI-era restructuring.

Under this structure, the shift to FDE-style work is likely to lag. In particular, the “just build” layer is in the highest-AI-replacement-risk position. The moment implementation became cheap, “just build” jobs — somewhere along the multi-tier subcontracting chain — start falling away.

That said, Japanese companies do have an opportunity. The culture of SIers, which keeps a close distance to the customer’s field, is actually well-suited to the FDE role. Sales SEs hearing requirements at the customer site, engineers building them — if this division of labor can be reorganized into an “sales SE + engineer + AI” integrated persona, Japanese companies can approach the U.S. startup FDE model.

But that reorganization requires resolve on the organizational side. Cleaning out the middle layers of multi-tier subcontracting and concentrating authority and responsibility on field engineers — this is a deep transformation of Japanese corporate structure. The ideal organizational form I discussed in Organization Context Engineering First and the shift to FDE discussed here are connected at a deep level.

Reading Role Boundaries Through Coase’s Transaction Cost Theory

Finally, let me re-read this restructuring through the lens of economics.

In his 1937 paper “The Nature of the Firm,” Ronald Coase argued that the boundaries of the firm are determined by transaction costs⁹. If the transaction cost of carrying out a function in the market (information search, contract negotiation, performance monitoring) exceeds the cost of doing it inside the organization, that function is internalized. If it is lower, the function is pushed out to the market (outsourced).

Applying this theory to role boundaries in the AI era:

• AI has lowered the transaction cost of implementation. The cost of the “communicate requirements → have it implemented → accept the deliverable” process has dropped.
• But the transaction cost of extracting requirements has not dropped. The work of articulating the customer’s tacit knowledge still carries high transaction costs.
• As a result, a role that integrates “requirements extraction” and “implementation” becomes economically rational. That is the FDE.

A 2025 California Management Review paper¹⁰ pushes this further. AI agents lower the internal cost of automation, but at the same time raise the transaction cost of dependence on external platforms. In other words, there is a seesaw structure where “as one transaction cost falls, another rises,” and organizations must redraw their boundaries in response.

The rise of FDEs is one manifestation of this seesaw. As implementation transaction costs fell, the relatively-higher “transaction cost of requirements extraction” is being internalized, and the role configuration is being restructured.

Japan’s SIer structure can be re-read through Coase’s theory too. Multi-tier subcontracting was a division of labor designed to lower the “transaction cost of implementation” of an earlier era. Once AI lowers implementation cost, the economic rationale for that division of labor itself begins to wobble — this is the essence of the structural pressure facing the Japanese SIer model.

Conclusion: After the Middle Layer Falls Away, “Closeness to Context” Is Everything

AI has lowered implementation cost, and the role boundaries inside software organizations are being redrawn. Roles do not disappear — boundaries get redrawn.

To summarize:

1. Among PdM responsibilities, requirements-translation and documentation are falling away. AI-augmented engineers absorb them directly.
2. The PdM’s core work (strategy, prioritization, stakeholder alignment) remains. Its importance is actually rising (Andrew Ng predicts “more PdMs”).
3. FDEs are on the rise, absorbing the falling-away work. Palantir-origin, now spreading to Anthropic / OpenAI / SaaS startups.
4. The engineer’s new moat is “context extraction.” Not implementation speed, but the ability to articulate the customer’s tacit knowledge.
5. Japan’s SIer model carries strong inertia. The middle translation layer of multi-tier subcontracting is losing its economic rationale in the AI era.
6. The structure is fundamentally Coasian. This is a natural response of organizational boundaries to changing transaction costs, not an AI-specific phenomenon.

What does this mean at the individual level? It all comes down to one line: “closeness to context” becomes the core of career strategy.

• Work close to the customer (FDE-style career path)
• Sharpen the skills of articulating tacit knowledge (questioning, observation, trace reading)
• Retain implementation skills as a “foundation,” now in the role of evaluator of AI
• Choose your position: deepen into the higher-order PdM functions (strategy, alignment, experiment design), or aim at the FDE-style integrated persona

The parent article, Growing Your Own Context: A Survival Routine for Individual Engineers, was about “survival skills assuming the organization does not supply context.” This article discusses the opposite future — what happens if we enter an era where AI supports context extraction and closeness to the field becomes the primary axis of organizational design.

The two are not in conflict. The default today is “context is not surfaced.” But the people who learn to grow context for themselves under that default are precisely the ones who will deliver the most value once the FDE-style role becomes standard. Today’s survival skill becomes tomorrow’s moat — that is the final implication of this article.

Related Articles

For more on this theme, see also:

• Growing Your Own Context: A Survival Routine for Individual Engineers — the parent article; survival routines for engineers when context is not supplied
• Organization Context Engineering First — the ideal form on the organizational side
• A Junior Engineer’s Vibe Coding Productivity Guide — growth strategies for junior engineers in the AI era
• The AI Delegation Paradox — AI delegation and the human role
• The Five Layers of Context IT Engineers Should Recognize — the theory of context layers

References

References below correspond to the citation numbers in the body text.

Additional References (Not Numbered in the Body)

• Forward Deployed Engineer (FDE) — OpenAI Careers — OpenAI official careers page. Primary-source confirmation that the FDE role exists at OpenAI. [Reliability: high]
• A Day in the Life of a Palantir Forward Deployed Software Engineer — Palantir’s official blog. Describes the day-to-day work of an FDE from a practitioner’s perspective. [Reliability: medium–high]
• Moving To The Product Operating Model by Marty Cagan — Commentary on Cagan’s latest book. Components of the Product Operating Model. [Reliability: medium]

1. What are Forward Deployed Engineers, and why are they so in demand? — Gergely Orosz, The Pragmatic Engineer (2025). A comprehensive primary-source overview of FDE history, hiring trends, and practices at major companies. The a16z “hottest job” assessment and the specific Palantir / OpenAI / Ramp headcounts in this article come from here. [Reliability: medium–high] ↩︎ ↩︎² ↩︎³ ↩︎⁴ ↩︎⁵ ↩︎⁶

2. Andrew Ng: Product Team Ratios Evolving to Just One Software Developer for Every Two Product Manager — HackerNoon (2025). An analysis based on Andrew Ng’s remarks. Original source: Ng’s X post. [Reliability: medium] ↩︎

3. The Role of Product Management — Silicon Valley Product Group — Marty Cagan, SVPG. Primary source on the PdM’s original role (value, viability, strategy, prioritization). [Reliability: medium–high] ↩︎ ↩︎²

4. Developers remain willing but reluctant to use AI: The 2025 Developer Survey results — Stack Overflow Blog (2025). Source for the AI tool adoption rate (84%) and AI trust (29%, down 11 points year over year). [Reliability: medium–high] ↩︎ ↩︎²

5. 2025 Stack Overflow Developer Survey: AI section — Stack Overflow (2025). Source for detailed data, including 45% citing “spending more time debugging AI-generated code” as their biggest frustration, and 66% spending additional time fixing “almost-but-not-quite-right AI output.” [Reliability: medium–high] ↩︎

6. Palantir Technologies — Forward Deployed Software Engineer — Palantir official careers page. Primary source for the FDSE role definition. [Reliability: high] ↩︎

7. Forward Deployed Engineer, Applied AI — Anthropic — Anthropic official careers page. Primary source for Anthropic’s FDE job description and required qualifications. [Reliability: high] ↩︎ ↩︎²

8. The Tacit Dimension — Michael Polanyi (1966). The classic work establishing the concept of tacit knowledge. Source of “we can know more than we can tell.” [Reliability: high] ↩︎

9. The Nature of the Firm — Ronald H. Coase, Economica (1937). The classic paper establishing the relationship between transaction cost theory and firm boundaries. [Reliability: high] ↩︎

10. From Coase to AI Agents: Why the Economics of the Firm Still Matters in the Age of Automation — California Management Review (2025). A recent treatment applying Coase’s theory to the age of AI agents. [Reliability: medium–high] ↩︎