FDE vs Solutions Engineer vs Consultant vs Product SWE

Recruiters mix these up. Job descriptions mix these up. Engineers considering a move into customer-facing work mix these up most of all — and end up in the wrong seat for two years. Having worked the FDE side of the line while collaborating closely with all the others, here's my map of where the boundaries actually sit.

The four roles: Forward Deployed Engineer, Solutions Engineer, Consultant, and Product Software Engineer. They can all appear in the same deal, on the same call, and be doing four different jobs.

The fastest way to tell them apart

Ask one question: what artifact does this person's success produce, and who runs it in six months?

| Role | Primary artifact | Who owns it after | Measured on | |---|---|---|---| | Product SWE | The platform itself | The product team, forever | Product quality, velocity | | Solutions Engineer | The technical win — demos, integrations spikes, RFP answers | Nobody; it served the deal | Deals influenced | | Consultant | Recommendations, architecture docs, sometimes a build | The client, alone | Billable outcomes, client satisfaction | | FDE | A production system inside the customer's environment | The FDE and customer, jointly | Customer outcome in production |

Everything else — reporting lines, comp structure, travel — falls out of that table.

Product SWE: builds the engine

The product engineer's world is the codebase. They optimize for the general case: APIs that serve every customer, abstractions that hold across use cases, a roadmap measured in quarters. Their contact with any single customer is deliberately thin — that's a feature, because it protects focus.

The trade-off: they never see their assumptions collide with one specific customer's fifteen-year-old ERP, undocumented internal API, and compliance team. That collision is where the other three roles live.

I've done pure product work — at Siemens I spent two years on enterprise IoT desktop software, deep in MQTT and a test suite north of a thousand Jest tests. It taught me the rigor. But nothing in that job required me to sit across from the person whose workflow my software was about to change. The FDE job is that meeting, weekly.

Solutions Engineer: wins the deal

The SE (or sales engineer, or pre-sales engineer) is attached to the sales motion. They demo, they answer the security questionnaire, they build the integration spike that proves feasibility, they translate between the account executive and the customer's architects. Good SEs are genuinely technical and criminally underrated.

But the SE's job ends where production begins. The artifacts are disposable by design: a demo environment, a proof-of-feasibility, a slide of reference architecture. Once the contract is signed, the SE rotates to the next deal and someone else inherits the promises.

That handoff is exactly the seam the FDE role was invented to remove. When the person who demoed the system is the person who has to make it real, the demos get more honest and the deployments get faster — there's no telephone game between "what we showed" and "what we build." It also changes what you're willing to show: I've written about which parts of a demo must be real and which can be faked, and the calculus is completely different when you are the one who has to deliver the real version.

Consultant: advises (and sometimes builds) without a platform

The consultant looks the most like an FDE day to day — embedded with the client, running discovery, producing systems or recommendations. Two structural differences change everything:

No platform gravity. A consultant is nominally neutral: they'll recommend whatever stack fits. An FDE deploys their company's platform. That sounds like a handicap but is usually a superpower — the FDE arrives with deep, insider-level expertise in one system, a direct line to the people building it, and the ability to get platform bugs fixed rather than worked around. The consultant sends an email to a vendor's support queue; the FDE messages the engineer who wrote the feature.

No feedback loop. When a consultant's engagement ends, the learning walks out the door with them, into their next unrelated client. When an FDE's deployment ends, the learning flows back into the product. Every gap I hit in the field becomes a conversation with the core team; patterns from one deployment become reusable modules for the next five. When I led the team at Ôdasie, the things we kept rebuilding across client AI deployments — approval workflows, voice pipeline scaffolding, MCP server patterns — hardened into internal tooling precisely because we weren't consultants. We had somewhere to put the learning.

FDE: builds the outcome

So where does that leave the Forward Deployed Engineer? Owning the piece none of the others own: the working system, in production, in the customer's environment, doing the customer's job.

The SE proves it could work. The FDE makes it work.
The consultant tells you how it should work. The FDE ships it and carries the pager.
The product SWE makes the platform capable. The FDE makes one customer successful with it.

If you want the full anatomy of the role, I broke it down in What a Forward Deployed Engineer Actually Does. The short version: half production engineer, half field operator, zero handoffs.

"Is FDE just support with better branding?"

This is the objection I hear from engineers considering the role, and it deserves a straight answer: no — and the difference is what you produce.

Support (even premium, named-engineer support) is reactive. A ticket arrives; you restore the previous state of the world. Nothing new exists when you're done.

FDE work is generative. On any given engagement I am writing real systems — a WebRTC voice pipeline, an eval harness over the customer's actual tickets, an MCP server exposing their internal APIs to an agent, a NestJS service that has to survive their traffic. At VoiceQube the "field work" produced three production AI products and a backend serving real-time interactions across tens of thousands of locations. That is not a support queue. That's a build role with a customer in the room.

The tell in a job description: if the role owns deployments and is measured on customer outcomes in production, it's a real FDE role. If it owns tickets and is measured on response time, it's support wearing the badge.

Why AI collapsed these roles together

Five years ago the four-role split worked because enterprise software was configurable rather than buildable — an SE could demo it, an admin could configure it, support could maintain it.

AI products broke that. An agent platform or LLM stack isn't configured into usefulness; it's engineered into usefulness, per customer, against messy data and messier workflows. The demo requires build skills. The deployment requires build skills. The advisory conversation ("should this be an agent at all?") requires having built agents. So the market invented a role that fuses all three around a single engineer — and that fusion only holds if the person can genuinely do the production engineering at the center of it.

That's also the honest career pitch. As an FDE you keep the engineering muscle of a product SWE, gain the customer instincts of an SE, and get the variety of a consultant — while building things that stay alive after you leave the room.

Choosing your seat

If you're deciding between these roles, the questions that actually predict fit:

Do you want to go deep on one codebase or broad across many environments? Deep → product SWE. Broad → the other three.
Do you need to see your work running in production to feel done? If yes, SE will frustrate you and consulting will half-satisfy you. FDE is the seat.
Does ambiguity energize you or exhaust you? FDE engagements start with "the customer wants AI" and no spec. If you need the spec handed to you, stay product-side.
Can you be the bad-news messenger? FDEs regularly tell customers their favorite idea shouldn't be built. If you can't say no and keep the relationship, the role will eat you.

The takeaway

Same meeting, four jobs: the product SWE built the engine, the SE proved the engine could win, the consultant would advise on engines generally, and the FDE is the one who drives it into the customer's terrain and keeps it running. If the artifact you want your career to produce is working systems that changed how a customer operates, there's only one seat at that table — and right now, every serious AI company is trying to fill it.

Related reading