The Future of Product Development

Product management is rapidly changing due to coding agents like Codex and Claude Code. These tools collapse the traditional information gap between PMs and engineers, allowing PMs to directly inspect implementations and trade-offs without waiting for explanations.

This tighter loop enables PMs to understand technical constraints faster and focus more on solving business problems. As a result, less time will be spent writing PRDs, running sprint rituals, and handling rote operational work—and more time will be spent driving outcomes.

We are already seeing this shift as the bar to land a product job is becoming hire, and less headcount is required. It'll soon become obvious that beyond 2025, a Product Manager's job is categorized by extreme ownership, or the requirements to do whatever is necessary to mark the chart go up and to the right.

Forward Deployed

Within the last 18 months or so, forward-deployed engineers (FDEs) have been one of the most difficult and competitive roles to hire for. Palantir was the first company to create this role, and many AI-native startups, including Scale AI, have seen great success copying this go-to-market motion. A forward-deployed engineer is essentially an on-prem sales engineer. The engineer embeds themselves within an enterprise customer to deeply understand the context of the customer’s business and how they have built their software. The engineer then becomes the glue or middleware, shaping toolsets to work best in the context of the enterprise customer. By doing so, they drastically shorten time-to-value and inherently create stickiness.

The challenge of hiring is that you must find business-minded engineers who are comfortable navigating large-company decisions as well as intricate code. Another trade-off for the company is deciding whether to send a brilliant engineer to accelerate deal closing or keep them focused on product execution. Holding this tension, we can reasonably conclude that with coding agents, companies can instead send forward-deployed PMs. PMs are already aligned with creating business value, and by sitting next to the customer during implementation and use, they can leverage this tight feedback loop to guide the roadmap and increase value and differentiation.

Context Engineering With Markdown

How can a PM bridge the gap between themselves and an engineer?

While I have been code-adjacent my entire career, I am confident in saying that I am a lousy engineer. There are many reasons I would not cut it as a SWE, but the primary one is my lack of patience. As a customer-facing PM, when I see a business problem, I want to solve it as quickly as possible. This has meant that the code I have written is narrow in scope and brittle (hello monoliths). As a result, I have actually been banned from making PRs—for good reason. However, the trade-offs between fast solutions and code that does not scale are disappearing.

I have had incredible success with context engineering using Markdown (.md) files. I start with a root-level Markdown file that is written by an engineer. This file dictates the rules of the codebase, with example patterns shown by referencing the parts of the codebase that execute the domain. Any time a major refactor is done, this Markdown file is updated by a coding agent. Before any planning step is done by Codex or Claude, this file is always fed into context first.

The second type of .md file comes from the LLM-based planning step. After the initial back-and-forth in defining scope, trade-offs, and non-functional requirements, the agreed-upon plan is written down in Markdown. This document includes the problem being solved, why certain trade-offs were made, known limitations, the scope of implementation broken down into PRs of roughly 300–400 lines of code, and the required test coverage. This file represents what a PRD is meant to be and becomes the blueprint for parallel agents to work. Each agent can pick up a discrete task and update the Markdown files with steps taken, results, and test coverage. The result is the output consists of bite-sized PRs that are reviewable by SWEs and well documented. If changes are requested, this format is modular enough that plans can be updated by an LLM planner without the model losing context and the entire feature grinding to a halt.

The nice thing about forward-deployed work is that the solution space is constrained: the customer has hard requirements, and the solution platform has hard primitives. When the core domain objects and invariants are already defined (the “DTOs”), the PM’s job is mostly to map customer workflows onto those primitives and shape the integration contract—endpoints, semantics, and failure modes—rather than inventing something open-ended.

Blurring Boundaries

It will take time for each company to figure out the new boundaries between engineering and product strategy as these lines blur. Depending on the business and culture, these roles may look very different. In some large enterprises, I can even see the creation of a new role—the technical project manager—who takes over the reporting and communication functions product managers historically handled, while product managers who own business outcomes become more like GMs, with engineering teams reporting into them.

While I could be totally off base with this org-chart prediction, the undeniable truth is that for Product Managers to stay relevant, they must become more technical.