At one moment a business team has stopped filing product requests. They started going directly to one engineer, and a few days later they have working software.
I read about a setup like this recently in a post a post by a fellow PM. The post described the situation in their organization from from the perspective of the product manager who had effectively been cut out of the loop. The engineer had a title I had seen before: Forward Deployed Engineer. They sat with the business department, worked out the problem, built it and shipped it — no product manager, no backlog, no development team in the usual sense.
When this specialist appeared, for the first three or four months nothing much changed. Then the department realized it could skip the queue, and started going to the engineer with almost everything. Anything they asked for was treated as “decided” and “settled”.
The stakeholders were obviously delighted. No prioritisation calls. Nobody explaining why the thing they asked for is ninth on a list.
The PM from the post raised it with their manager and was told not to worry, engineers are not going to replace product managers. They asked the PM Community for advice and mentioned that they had started looking for another job. I can see why they started looking.
So I went and read about the role. And then about four other roles that keep getting confused with it. This is what I found.
What a Forward Deployed Engineer actually does
FDE: how do we solve this customer’s problem?
How to solve a specific problem technically? How to quickly create a working solution? What does this specific client/department need? How to bring the selected problem to a technical outcome? Discovery + implementation are very close to the user.
An FDE — the term comes from Palantir. The full title is Forward Deployed Software Engineer, a software engineer who works very close with a customer. They talk to the users, work out the problem, design the solution, write the code, deploy it, and then watch whether it helped.
In short, their questions are:
- how do we solve this customer’s problem?
- How do we solve this specific problem technically?
- How do we quickly create a working solution?
- What does this specific client/department need?
- How do we turn the selected problem to a technical outcome?
- Their area: discovery + implementation are very close to the user.
For comparison, a Product Manager role askese:
- Is this problem worth the product’s resources at all?
- What and why should we build?
- How does this support the product strategy?
- Which users/markets/problems are prioritized?
- How to allocate limited resources among the problems?
- Their area: Roadmap, product coherence, prioritization
The FDE term is most associated with Palantir, where these engineers sit in the customer-facing part of the company rather than in a product team. The point of the role is to shorten the distance between a real operational problem and working software for one specific customer.
Most companies using the title mean some version of that. Some deploy the engineer to an external client. Some, like the case I read about, put them next to an internal department. The mechanics are the same either way.
Is this really a fight between roles?
I was curious and started digging. As I found out these roles are answering different questions.
FDE: how do we solve this customer’s problem?
PM: is this problem worth the product’s resources at all?
The answers often line up. A customer has a real problem, it is worth solving, someone solves it fast. Good.
They come apart when the request is real but small, or real but specific to one account, or real but the third version of something the product already half-does.
In the case I read about, that question had simply been deleted. The operating model went from
business need → product evaluation → prioritisation → engineering → delivery
to
business asks → engineer builds
Fast, popular, but missing an important layer.
The four neighbours
I also noticed several neighbouring roles that sound similar but work quite differently in practice. And the boundaries between them can be surprisingly thin and vague.
| Role | Main question | Where they sit | Write code? | What they optimise for |
|---|---|---|---|---|
| Product Manager | What should we build, and why? | Inside the product team | Usually no | Product value, users, business |
| Forward Deployed Engineer | How do we solve this customer’s problem, fast? | Next to one specific customer or department | Yes, a lot | An outcome for that customer |
| Solutions Engineer | Can our existing product solve this prospect’s problem? | Sales / pre-sales | Sometimes prototypes, rarely production code | Technical fit, closing the deal |
| Implementation Manager | How do we get this customer live on what they bought? | Post-sales, professional services | Usually not | Go-live, onboarding, adoption |
| Product Engineer | How should we build this part of the core product? | Inside product engineering | Yes, they are an engineer | Quality and value of the core product |
Solutions Engineer — before the sale. Sales is talking to an enterprise prospect. The prospect asks whether the product will work alongside their existing systems and their own authentication. Sales cannot answer at that depth, so the Solutions Engineer comes in: understands the customer’s architecture, runs a demo, sketches the integration, sometimes builds a proof of concept, removes the technical objections. The business goal underneath is to show technical fit and help close the deal.
Implementation Manager — after the sale. The contract is signed and now someone has to make it real. Configuration, data migration, integrations, permissions, testing, training, go-live, handover to customer success. The question is what this particular customer needs in order to launch successfully. Not what the product strategy should be next year. In some companies this role is nearly a project manager. In others it is nearly a technical consultant. The title tells you very little.
Product Engineer — inside the product. Not a PM who learned to code. A software engineer with strong product thinking. The difference shows up in how they take a problem. Instead of asking, “What does the ticket say?”, their thinking is closer to: this new screen is more than we need, we could reuse the state we already have and show the reason inline, and that solves most of it far cheaper. They still own building the software. They just refuse to build it blind.
Product Manager — zoomed out one level. Which problems deserve investment, for whom, why now, and how those decisions add up to a product that makes sense.
One request, five roles
A large B2B customer can say: we need a custom executive dashboard.
Solutions Engineer, before they buy: what do you actually want to see? Most of that our dashboard engine already does. Let me show you.
Implementation Manager, after they buy: we need the data source connected, permissions defined and UAT done before the September launch.
FDE: show me how you make these decisions today. The CEO wants revenue, churn, pipeline and customer health in one place. Connects the sources, writes the transformations, ships a working dashboard.
Product Engineer: five customers have asked for this. Maybe the product needs a configurable dashboard builder. Builds it into the core product.
Product Manager: wait. Why do customers keep asking for custom dashboards? What is the underlying problem? Is a builder the right answer, and for which segment? Does it help retention or expansion? Is it worth two engineering teams for three months, and what are we dropping to pay for it?
Every one of those is a reasonable response. I’m still slightly amazed that the same request can involve five different people. Sometimes it looks less like specialization and more like responsibility being sliced very thin – but I’ll stop there.
Where the overlap really is
The overlap between PM, FDE and Product Engineer looks real. All three can sit with a user and investigate a problem:
- PM: should we solve this?
- FDE: how do we solve this customer’s problem?
- Product Engineer: how should this be built into the product?
Maybe this kind of division only really makes sense in a very large organisation?
The part that actually worried me in that post
In that post, the PM described how a FDE collapses a long chain — stakeholder, PM, analyst, engineer, implementation — into something much shorter: stakeholder, engineer, working software. With a good FDE that is genuinely fast.
But delivery efficiency does not answer the investment question. Engineering capacity stays finite even when delivery feels unlimited. A company can get very good at building things and, at the same time, much worse at choosing which things deserve to be built.
So the mature version of this is not PM instead of FDE, or FDE instead of PM. It is closer to: the PM decides which problems are worth investment, and the engineers get a lot of freedom in finding and building the solution.
The dangerous version is not having FDEs. It is replacing “what should we build and why” with “you are the customer, tell us what you want”.
That produces a lot of software. It does not necessarily produce a good product.
The part I keep thinking about
For most of my career the line was clear. I work out what should be built and why, someone else builds it. That line is moving, and not because product managers got worse.
The common claim now is that AI is making software cheaper to build. I built and shipped a working app myself this year with AI help (I’ll do the numbers later and write about that too, because the economics are not nearly as shiny as the current AI posts make them sound). Anyway,I’m not an engineer, and that definitely creates extra cost and rework when I’m vibe coding and I will not pretend otherwise, but the MVP is live, and I did ship it.
None of that makes me an FDE. It did change what I think the PM role is there to protect.
If defining a solution and building it keep moving closer together, the part that doesn’t disappear is deciding which problems are worth anyone’s time.That was never the easy half. It’s just the half nobody notices until nobody is asking the question anymore.
One practical note if you read job ads:
Solutions Engineer and Implementation Manager can both look very PM-like in a description. FDE and Product Engineer roles almost always require real software-engineering skills.
So I stopped starting with the title. Two or three lines of the job description usually tell you more:
- Who is this role’s customer — a prospect, a paying account, or the product’s users?
- Where in the lifecycle does it appear — before the sale, after the sale, or inside the roadmap?
- Is this person expected to write production code themselves?
Answer those three and the title stops mattering.
Leave a Reply