Abha Dogra is the chief product officer at IBS Software.
In 2006, Palantir introduced a role that redefined how software companies from Google to OpenAI create customer value: Forward-deployed software engineers (FDEs) are embedded directly inside client organizations, not to sell, but to build.
While traditional engineers created single capabilities for many customers, forward-deployed engineers focus on enabling many capabilities for a single customer.
The model can be expensive and talent-intensive—requiring elite engineers to embed directly within customers for months at a time—but it can also be radically effective, which is why it has become one of the most sought-after jobs in the tech industry.
The approach addresses something the software industry had long known but rarely acted on: The closer you are to the problem, the better the solution. That same principle can be just as valuable for product managers (PMs) and product teams.
The Translation Problem In Product Management
Product management has always been a discipline of translation. Product managers (PMs) sit between customer reality and engineering execution, converting observations into specifications that developers can action.
This process can be clunky and ineffective. By the time a customer’s problem travels from discovery interview to final testing, it has passed through multiple handoffs, each introducing an opportunity for interpretation and assumption.
The original context—the frustration, the workaround, the unstated expectation—is lost further with every step. The final round of customer testing becomes the moment of truth where the gap between what was built and what was needed finally surfaces.
The problem with this model is the structure itself, rather than the process. Requirements are most accurate when gathered close to the problem. The further away they’re collected, the more details get lost.
“Shifting left” in software development means moving testing and quality checks to occur earlier in the cycle, catching defects earlier. FDEs make this shift by getting close to the customer’s environment, observing real workflows before prescribing solutions and closing the loop immediately.
AI As The Force Multiplier
AI is making this approach easier and more practical.
Imagine a PM inside a customer’s operations center watching a disruption unfold. With AI tools, they can translate what they observed into a mock workflow or interactive prototype during the same conversation, then refine it live with the customer. Instead of waiting weeks for handoffs, the customer reacts to something tangible immediately.
After that session, AI can turn audio recordings into detailed requirements specifications, convert them into phased product releases, generate mockups, identify edge cases and structure the material for engineering review in hours.
The PM’s job shifts, too. They will spend less time documenting manually and more time on the judgment calls AI cannot make: reading organizational dynamics, distinguishing habit from real pain and deciding which patterns are important enough to shape the roadmap.
Why The Operating Model Matters More Than The Tools
The AI landscape moves so quickly that any approach built around specific products can be outdated the moment it is published. That’s why I suggest thinking about this as an operating model rather than a tool strategy.
Instead of organizing PMs only around internal product domains, companies can deploy them around customer environments or industry verticals. A PM working with airlines, for example, develops the operational fluency to act not just as a product leader, but as a business process analyst by bringing together domain expertise, product knowledge and proven practices drawn from similar workflows across multiple customers.
Their role shifts from managing handoffs to observing workflows, shaping better specifications, prototyping solutions and feeding repeatable patterns back into the core product.
The Feedback Loop That Feeds The Platform
There is a second benefit to this model, one that product organizations are only beginning to realize but that Palantir understood early. When your best product thinkers are embedded in customer environments, the knowledge they build doesn’t just improve one customer’s outcomes but can be used to make the whole product better.
As a Palantir FDE explained in a recent interview, some of their most valuable product capabilities were discovered in the field by FDEs solving specific problems and then built into the core platform for every customer to use.
The same dynamic applies to forward-deployed product management. When a PM working inside an airline’s operations center discovers that a specific type of crew disruption generates a predictable downstream failure in cargo scheduling, that insight becomes the seed of a platform feature that every airline customer eventually benefits from.
This is the compounding advantage of proximity. The further product teams sit from customer environments, the more they are designing based on assumptions. The closer they sit, the more they are designing from evidence.
Putting It Into Practice
Adopting an FDE model in product management requires real changes in talent, leadership and operating design, not just asking PMs to spend more time with customers.
The first challenge is talent diversity. Unlike engineering, product teams are built from varied backgrounds like engineering, sales, consulting and business. This means individuals won’t approach this shift with the same instincts. Leaders must recognize those differences and invest accordingly.
The second challenge is behavioral. This model requires PMs to unlearn a deeply embedded handoff mindset, which takes more coaching than most organizations expect on tasks like observing workflows directly, synthesizing insights in real time and collaborating rather than passing static documents between functions.
The third challenge is organizational. If product teams are generating richer outputs—interactive mockups, workflow simulations, AI-assisted specifications—engineering can’t keep operating as if it’s receiving a traditional text handoff. Architects and engineers need greater ownership in interpreting context and engaging earlier around dynamic artifacts.
The best implementations start small: A few high-value customer workflows, strong PMs paired with engaged engineering counterparts and early cycles treated as capability-building rather than scale deployment.
The goal isn’t simply to add AI into the process—it’s to build a product organization that combines domain insight and customer context into better decisions and better products.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
