Key Takeaways

  • Mati Staniszewski organized ElevenLabs without executive titles, running autonomous units of fewer than 10 people who make direct decisions for the customer.
  • ElevenLabs embeds Forward Deployed Engineers (FDEs) directly inside the product division rather than in sales or professional services, keeping custom work tied to the platform roadmap.
  • Non-technical internal groups like legal, talent, and operations have dedicated software engineers assigned to automate their manual workflows.
  • Bespoke enterprise integrations are treated as customer-funded research, with custom code abstracted back into the shared codebase for all future users.
  • The entire deployment model runs on the Palantir-Style Forward Deployed Engineer (FDE) Product Feedback Loop.

The Palantir-Style Forward Deployed Engineer (FDE) Product Feedback Loop

Step 1: On-Site Domain Immersion

Deploy forward deployed engineers directly into the customer's offices on the front line to understand domain bottlenecks and workflows side by side with end users.

Step 2: Custom Enterprise Integration & Simulation

Build necessary integrations (e.g., CRM, telephony SIP trunking) and simulate real-world behavior to test agent flows and safety parameters at a small scale.

Step 3: Embedded Product Learning

Keep FDEs structured under the core product team rather than go-to-market, ensuring integration findings and technical friction points are surfaced directly to platform roadmaps.

Step 4: Platform Abstraction

Extract reusable components, workflows, and integrations developed for one client into the centralized platform so that all subsequent enterprise customers benefit without custom service work.

Step 5: Ongoing Monitoring and Proactive Optimization

Continuously evaluate production telemetry, replacing reactive user feedback with proactive AI summaries that inform engineering where real-world systems fail.

When This Works (and When It Doesn't)

This framework works when enterprise accounts demand complex custom setups that off-the-shelf software cannot handle. When large clients ask for bespoke telephony plumbing or legacy database hooks, standard SaaS startups either reject the contract or build a separate professional services agency. Placing FDEs in the product team turns custom enterprise demands into core product R&D.

It fails if your product is a low-friction, high-velocity self-serve tool with small transaction sizes. If an account is worth $50 a month, sending an engineer on-site will destroy your unit economics. It also breaks down if management fails to enforce Step 4. If your engineers build custom features without abstracting them into the platform, your company morphs into an IT consultancy with high headcount and low gross margins.

What to Do With This

If you are selling an AI product to enterprise accounts this week, pull your most technical customer-facing engineer out of the sales org chart and move their reporting line to your head of product.

Next, take your largest active pilot and send that engineer to sit directly next to the client's operations staff for three days. Have them observe the exact moments where your software fails to connect with their legacy tools. When they build the custom glue code to close that pilot, require a pull request the following Monday that turns that specific connector into a configurable, general-purpose feature for all future customers.