The adoption checklist: need a special motion, and have a platform

Video segment: 9:20–11:30

Forward-deployed engineering (FDE) is not a default way to grow a software company. In this segment, Kevin Bai offers a deliberately restrictive test: adopt the model only when you need its special delivery motion and when you have, or will invest in, a platform that makes the work reusable.

The two questions work together:

1. Is there a customer problem that needs FDE?
2. Can the company deliver that help on shared platform primitives?

The first question explains why customer-facing engineers might be necessary. The second explains whether their work can scale without turning into an expensive custom-development business.

1. Diagnose the need, not the trend

The speaker's first test comes from the earlier product-and-buyer framework: FDE is a fit when a company sells something technically complicated to a nontechnical buyer. The customer may care deeply about the business result, but may not have the software and data skills needed to turn a powerful, customizable platform into that result.

That creates an implementation gap:

Complex platform can do valuable work
                 +
Customer cannot readily build the needed solution
                 =
Customer-facing engineering may be needed

An FDE can close that gap by understanding the customer's context and building a solution on the vendor's platform. This is different from adding engineers simply because FDE is popular or because engineers can participate in revenue.

Need versus want

The important distinction is causal:

A reason to investigate FDE	Not enough by itself
Customers need expert technical help to realize value from a complex platform.	The company wants a prestigious enterprise-sales motion.
The buyer/product combination leaves a real implementation gap.	AI makes it possible to build software faster.
A customer outcome depends on vendor engineers building with the platform.	The company wants engineers closer to customers.

The right question is not, “Could an FDE team help?” Almost any team might help a customer. It is, “Does this product and customer relationship require this kind of help to deliver the promised outcome?”

2. Choose the motion that matches the product

The speaker explicitly names other good options. Rejecting FDE is not a failure; it can be the correct go-to-market choice.

• Developer engagement (often called DevRel) helps developers learn, trust, and adopt a product. It fits products whose users are developers and can build with the product themselves.
• A sales-led SaaS motion uses sales to sell a software product, then relies more on the product's normal configuration, onboarding, and customer process. It can fit configurable software that does not require the vendor to build a custom application for each buyer.
• FDE fits the more specific case where vendor engineers must work closely with a customer to turn a technically deep platform into a customer-specific outcome.

These motions can coexist in a company. But they solve different constraints. DevRel helps a technical audience succeed independently. Sales-led SaaS helps a buyer purchase and adopt a product. FDE supplies engineering capacity where customer implementation is itself the bottleneck.

3. Test the platform prerequisite

The second question is just as important: Do the engineers have a platform to build on? The speaker says a company must have one, or be willing to invest in building one.

A platform here is not merely a product name or a shared code repository. In the talk's framing, it provides shared primitives: reusable building blocks from which engineers can assemble customer solutions. The exact form of those primitives is not specified in this segment.

Why does this matter? Without reusable foundations, each customer request can become a separate from-scratch implementation:

No shared primitives
→ repeated custom code for each customer
→ many separate things to maintain
→ growing maintenance burden
→ FDE work becomes hard to scale

With a platform, an engineer can still customize a solution, but starts from capabilities that can be reused across customers. The platform does not remove all work. The speaker stresses that even a robust platform creates work. Its value is that it prevents every engagement from creating an entirely new technical base.

An illustrative decision walk-through

Consider a fictional company that sells a highly customizable operations platform to manufacturers. Its buyers understand factory operations, but do not have a team that can model data and build the applications needed for a particular workflow.

1. The product is technically deep and meant to be built upon.
2. The buyer has a real implementation gap.
3. Customer-facing engineers could plausibly create value by building the workflow with the customer.
4. The company then asks whether those engineers can use shared data models, workflow components, and other reusable primitives.

If the answer to step 4 is no, hiring FDEs may only create a queue of one-off projects. The company may need to invest in the platform first. If the product instead is straightforward for customers to configure on their own, a sales-led motion may be sufficient. If the customers are developers who can self-serve, developer engagement may be a better fit.

This is a teaching example, not a claim about a company in the video.

The combined rule

The speaker's FDE 101 checklist can be expressed as a gate:

Need a special motion?
  Complex technical product + nontechnical buyer with an implementation gap
                         AND
Have a scalable foundation?
  A platform with shared primitives, or a commitment to invest in one
                         ↓
                  Consider FDE

If either condition is missing, the case is weak. A platform without the buyer/product problem may not need forward-deployed engineers. A serious customer problem without reusable foundations can produce the maintenance burden of a dev shop.

That is the chapter's central discipline: treat FDE as a response to a specific delivery problem, backed by an architectural investment—not as a fashionable job title or a universal AI-era playbook.