Solutions Engineers help customers buy; Forward Deployed Engineers help your product actually work in production.
01 THE PROBLEM
Forward deployed engineering is the operating model where product engineers work inside the customer’s real environment long enough to close the gap between “the platform can do this” and “the customer got the outcome.”
That gap is where a surprising number of product teams fail.
The product demos cleanly.
The proof of concept passes.
The contract closes.
Then 90 days later, the customer still has no production workflow, no reliable data path, no internal adoption, and no measurable business result. What looked like a sales or onboarding problem is usually a product reality problem.
This shows up most painfully in AI, data infrastructure, security, developer platforms, and workflow products sold into enterprises. The software works in the abstract. It fails at the edge conditions that matter: bad source data, identity mismatches, brittle APIs, approval chains, compliance rules, unowned integration surfaces, and internal customer politics disguised as “technical blockers.”
The consequence is not just slower implementation.
It is a compounding business failure:
- revenue recognized before value is realized
- support costs rising quarter over quarter
- roadmap decisions made from secondhand customer feedback
- engineering building generic features while enterprise deals depend on bespoke glue code
- sales promising “configurable” when the truth is “possible with an engineer in the loop”
In a Series A–C startup, you usually feel this within one or two quarters.
A handful of large customers start consuming a disproportionate share of your senior engineers. Your Solutions Engineers become pseudo-implementation leads. Product managers get requirements through Slack screenshots and post-sales escalations. The CTO starts hearing the same phrase every week: “This is technically feasible, but the customer environment is complicated.”
That sentence is often a sign your org has misclassified the work.
This is not just pre-sales enablement.
This is product development happening in the customer’s production context.
And when you treat that work as a Solutions Engineering function instead of a Forward Deployed Engineering function, you create a structural blind spot. The team closest to customer reality lacks the mandate, code ownership, and product leverage to change the product fast enough.
The result is predictable: every deal feels custom, but none of the custom work compounds.
02 WHY IT HAPPENS
This happens because most product orgs separate product learning from customer implementation.
Solutions Engineers, Sales Engineers, and Solutions Architects are usually measured on deal support, technical validation, and customer confidence. That is a legitimate function. But their incentives are rarely tied to codebase evolution, product simplification, or reducing the marginal cost of the next deployment.
Engineering, meanwhile, is measured on roadmap delivery, platform stability, incident load, and shipping velocity. Also legitimate. But that pushes teams toward reusable abstractions and away from the customer-specific mess where the product’s actual constraints are exposed.
The gap between those two functions is where forward deployed work belongs.
Marty Cagan at SVPG describes the core of the Forward Deployed Engineer model as learning the problem and solution space directly so the team can discover a solution that achieves the needed outcome. That distinction matters. An FDE is not there just to configure software. They are there to learn by building in situ.
Palantir is the canonical reference because it operationalized this model early and aggressively. Gergely Orosz, in The Pragmatic Engineer, described why the model worked for Palantir in large enterprises: empowered engineers operated directly in customer environments, bypassed internal customer bureaucracy, and integrated software in a way that produced value faster than the customer could on their own. The deeper point is not “Palantir sends smart people onsite.” The point is that Palantir turned customer implementation into a product-learning engine.
That pattern now shows up across modern AI companies.
PostHog’s write-up on forward deployed engineering points out two realities that make the role especially relevant in AI. First, the work often requires direct access to production data and systems, not just abstract integration advice. Second, the contract sizes can justify deeply embedded engineering. Those are not side conditions. They are why the old split between product engineering and solutions engineering breaks down.
There is also an architectural reason.
Enterprise software rarely fails in the core algorithm. It fails at the seams:
- auth and identity propagation
- data ingestion and normalization
- workflow fit inside an existing system of record
- observability of customer-side failures
- permissioning across teams and environments
- latency and reliability under real production traffic
Those seams are invisible in your staging environment.
Stripe’s engineering culture has long emphasized reducing integration complexity because every extra step in adoption lowers the odds of successful implementation. You can see this in product decisions across Stripe’s docs, APIs, idempotency design, and developer experience. The principle generalizes: if customer value depends on stitching five systems together, then the real product includes that stitching.
Most startups know this intellectually.
They still organize as if implementation is downstream of product.
That is the root mistake.
The structural reason FDEs are needed is that in complex products, implementation is one of the highest-fidelity forms of product discovery. It reveals which assumptions survive contact with customer systems and which ones collapse.
And if that learning does not sit with engineers who can modify the product, your organization accumulates friction instead of insight.
03 WHAT MOST GET WRONG
Most teams make one of three bad moves.
The first is treating the problem as “we need better Solutions Engineers.”
That usually means hiring stronger demos, more technical pre-sales talent, or a Solutions Architect who can produce cleaner diagrams. Useful, but insufficient. If the bottleneck is that the customer needs a new data model, a new connector, a different retry strategy, or tenant-specific control-plane behavior, no amount of polished pre-sales work changes the product.
The second mistake is swinging too far the other way and letting random product engineers do customer work ad hoc.
This feels efficient at first. Your best backend engineer jumps on the customer Slack. A staff engineer writes a one-off script. Someone adds a hidden feature flag to make one enterprise deployment work. Revenue gets saved.
Then six months later:
- nobody knows which customer-specific code paths are safe to touch
- roadmap work gets interrupted by escalations
- customer knowledge lives in DMs and Zoom calls
- supportability collapses because implementation logic never became a first-class product surface
This is how bespoke work metastasizes into permanent complexity.
The third mistake is assuming professional services can absorb the problem.
Professional services teams are valuable when the product is already well-bounded and the work is mostly implementation, migration, training, or change management. They are the wrong tool when the product itself is still being discovered at the integration layer.
The cost of this misdiagnosis is easiest to see in cloud migrations and internal platform rollouts.
Netflix’s public engineering writing repeatedly shows a strong bias toward paved roads, abstractions, and platform leverage because ad hoc, team-by-team custom implementation does not scale. The lesson is not “be like Netflix.” The lesson is that if every deployment requires heroic local adaptation, you do not have a scalable product surface yet.
A concrete failure pattern showed up in the broader industry during early enterprise AI rollouts in 2023 and 2024. Startups sold copilots and workflow assistants into large companies before fully solving permissioning, source-system accuracy, evaluation, and human review loops. The result was a wave of pilots that looked impressive in controlled settings but stalled in production because the last 20% of operational fit required product changes, not just onboarding. PostHog’s framing captures why companies are hiring FDEs now: the critical work happens where product capability, data access, and customer context meet.
The common misdiagnosis is thinking this is a staffing issue in post-sales.
It is not.
It is an organizational design issue around where product truth is discovered and who has the authority to act on it.
A Solutions Engineer can explain what the product should do.
A Forward Deployed Engineer can prove what the product must become.
That difference is expensive.
If you classify FDE work as sales support, you get near-term responsiveness but no compounding product advantage.
If you classify it as pure engineering without structure, you get custom code and roadmap chaos.
Either way, the company keeps paying implementation tax on every new enterprise logo.
04 THE FRAMEWORK
The workable model is simple to describe and hard to run: use Forward Deployed Engineers as a product-learning layer attached to revenue, but governed like engineering.
That means five things.
1. Define the role by mandate, not by customer proximity
An FDE is not “an engineer who talks to customers.”
That describes half of any decent startup.
The mandate is narrower and more useful:
- own technical delivery for strategically important customer deployments
- modify product or platform code when needed
- convert one-off implementation pain into reusable product capability
- feed product strategy with direct evidence from production use
- reduce the implementation cost of the next customer, not just the current one
If your role definition stops at “help customers deploy,” you are hiring Solutions Engineers with coding ability.
That can work for mature products.
It fails for products still discovering the true boundary between configurable and custom.
A practical test: can this person merge production code into the main product, and are they expected to do so?
If not, you probably do not have an FDE model. You have technical implementation support.
2. Put FDEs on the engineering org chart, not in a services silo
This is the single most important design choice.
If FDEs report into sales or services, the local optimization becomes customer satisfaction for the current deal. That sounds good until you realize it creates a steady incentive to patch around product gaps instead of eliminating them.
FDEs need product and engineering management because they are making code and architecture decisions that affect maintainability, reliability, and roadmap shape.
They should still work in close partnership with go-to-market.
But their career ladder, code review path, and technical standards should sit with engineering.
This is consistent with the logic behind high-performing engineering organizations documented in Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim: performance improves when teams reduce handoffs and create fast feedback loops between work and outcomes. Forward deployed engineering is one way to remove the handoff between customer implementation and product evolution.
A useful structural model for a 50–200 person startup is:
- FDEs report to an engineering leader
- they have dotted-line alignment with sales or customer success for prioritization
- they share code ownership with core platform teams
- they are measured partly on productization outcomes, not just delivery completion
That last point matters.
If all your metrics are customer-facing, the organization will naturally drift toward custom work.
3. Create explicit productization thresholds
Without thresholds, every special case gets justified.
You need rules for when customer work becomes product work.
A practical set of thresholds:
- If two customers require the same workaround within 90 days, open a productization track.
- If a customer-specific integration requires more than two weeks of engineering effort, the owning team must decide whether it becomes a supported product surface.
- If more than 20% of one FDE’s time in a quarter goes to maintaining one-off code, that code path needs review for deprecation, ownership transfer, or productization.
- If a deployment depends on undocumented runbooks or tribal knowledge, it is not done.
These are not universal numbers. They are operating guardrails.
The point is to force explicit decisions.
Stripe is a good reference here, not because it publicly documents “FDE thresholds,” but because much of Stripe’s platform strength comes from repeatedly converting integration friction into product primitives: idempotency keys, webhooks, API versioning, Connect abstractions, and clear operational guides. Those are examples of productized lessons from real implementation pain.
That is the right mental model.
Your FDE team should not celebrate heroic custom delivery.
It should celebrate deleting the need for heroics on the next deployment.
4. Instrument deployment like a product funnel
Most startups track sales funnel and product usage funnel.
They do not track implementation funnel with enough rigor.
You should know, for every strategic account:
- days from contract signature to first production data flowing
- days from first data flowing to first end-user action
- days from first end-user action to measurable business output
- number of systems integrated
- number of product gaps found
- percent of gaps resolved by configuration vs code vs customer process change
- weekly FDE hours per account after go-live
These metrics tell you whether your product is getting easier to deploy or whether you are just getting better at compensating for its weaknesses.
Use DORA-style thinking here, even if the DORA metrics themselves are engineering-wide. The DORA program, now part of Google Cloud research, established four widely used indicators: deployment frequency, lead time for changes, change failure rate, and time to restore service. You can adapt that discipline to deployments: faster lead time from signed deal to customer value is a better indicator than number of successful pilots.
A healthy benchmark for an enterprise-facing infrastructure or AI product is not “we signed the deal quickly.” It is “we can get a well-scoped customer to first production value inside 30–60 days without executive escalation.” If your average is 90–180 days and every deployment still depends on your top engineers, your product surface is not mature enough for efficient scaling.
5. Give FDEs product authority, but limit the blast radius
This is where many teams overcorrect.
FDEs need the authority to change code, shape integrations, and influence roadmap. They do not need unconstrained permission to fork the architecture for every large logo.
You need clear boundaries:
- customer-specific code must be feature-flagged or isolated where possible
- changes to shared product surfaces follow normal design and review standards
- reliability-sensitive paths need ownership from the relevant platform team
- security and compliance reviews are mandatory for customer-environment access
The Google SRE book is useful here as a reminder that reliability is an organizational property, not a heroic behavior. If your FDEs are shipping code under pressure directly into paths that affect all customers, without clear ownership and rollback mechanisms, you are borrowing speed from future stability.
Cloudflare provides a helpful reference point in public engineering writing: infrastructure that operates near the customer edge still requires disciplined rollout, isolation, and observability. Forward deployed work should feel similarly constrained. Close to customer context, yes. Undisciplined, no.
6. Staff for builders with product sense, not just domain experts
The best FDEs are rare because they combine three skills that are usually hired separately:
- strong software engineering judgment
- comfort in ambiguous customer environments
- product instinct about what should become reusable
The failure mode is over-indexing on one dimension.
A pure enterprise operator without coding depth becomes a high-end Solutions Architect.
A strong engineer without customer judgment builds elegant abstractions no customer actually needs.
A domain expert without product discipline accretes expensive special cases.
Will Larson’s writing on staff engineering is relevant here: senior technical leverage often comes from operating across ambiguity, architecture, and organizational boundaries. FDEs need a version of that profile, even if they are not all Staff+.
At a startup between 20 and 200 people, a good initial ratio is often 1 FDE for every 5–10 strategic implementations running concurrently, assuming the core platform team is responsive and the product is not radically underbuilt. If one FDE can only manage one customer at a time for more than a quarter, you are not yet scaling a model. You are staffing custom delivery.
7. Make the handoff back into the product explicit
The hardest part of the FDE model is not customer embedding.
It is extracting reusable learning.
Every customer engagement should produce four outputs:
- A deployment architecture record
- A product gap log
- A supportability assessment
- A productization recommendation
Without this ritual, FDE work becomes folklore.
Linear is a good company to study for the opposite instinct: ruthless product boundary discipline. Linear has repeatedly talked about shipping deliberately, avoiding unnecessary complexity, and keeping the product coherent. The lesson for FDE teams is not that every request should become a feature. It is that productization requires taste. Some customer pain should become product. Some should become docs. Some should remain unsupported.
That tradeoff is the job.
8. Choose where not to deploy FDEs
Not every product needs this model.
Do not build an FDE motion if:
- your product is self-serve and succeeds without deep integration
- your average contract value cannot support embedded engineering economics
- your product surface is mature and implementation work is mostly repeatable
- your main problem is poor onboarding, not product-customer mismatch
In those cases, Solutions Engineering, support, docs, and developer experience work are likely better investments.
Vercel is a useful contrast. Vercel’s model relies heavily on product-led adoption, strong docs, framework alignment, and a platform designed to minimize implementation burden. That does not eliminate enterprise support work, but it changes the economics. If your product can be adopted like Vercel by most customers, forcing an FDE model on top is likely wasteful.
Forward deployed engineering is appropriate when customer value depends on navigating production complexity that your product has not fully abstracted yet.
That is common in AI, data, infra, and security.
It is not universal.
05 STRATEGIC TAKEAWAY
Forward deployed engineering is a product strategy, not a customer support tactic. If you run it well, your implementation effort compounds into a stronger product, faster time-to-value, and lower marginal deployment cost within two to four quarters. If you do not, your senior engineers become an invisible services layer, enterprise deals stay expensive to onboard, and your roadmap gets driven by escalation rather than evidence. For a CTO deciding this quarter whether to hire three more Solutions Engineers or stand up a small FDE function, the real question is simple: do we need better explanations of the product, or do we need the product to survive real customer environments faster?
06 IMPLEMENTATION ANGLE
Start small. Pick two or three strategic accounts where the gap between signed revenue and realized value is painfully obvious. Assign one strong engineer with product instincts, one PM or engineering manager who can force productization decisions, and one clear success metric: days to first production value.
Do not launch an FDE team without instrumentation and boundaries. Give the team access to customer systems, but require architecture records, code review through the main engineering process, and a monthly review of bespoke work that should become roadmap. If you cannot answer which customer-specific changes became reusable features in the last 90 days, the function is becoming services.
A practical stack today usually includes customer-safe observability, feature flags, and deployment templates. Datadog or OpenTelemetry-based tracing can expose where integrations fail. LaunchDarkly-style controls or internal flagging systems can isolate customer-specific paths while they are being validated. Terraform modules, internal templates, and reference architectures reduce repeated setup work. related topic If you are scaling the broader engineering org around this motion, Amplify can help engineering teams scale the hiring side of that equation, but the org design has to be right first.
