Q&A: platform boundary and the product feedback loop

Video segment: 16:12–16:56

Forward-deployed engineering (FDE) can build a solution that is specific to one customer. But an FDE organization also needs a shared platform that can serve many customers. This Q&A answer gives a practical boundary between those two kinds of work:

Keep work that is unique to one customer with that customer. In the long term, generalize work that can be reused on the platform.

This is not a rule that every customer request must become product work. It is a way to preserve both sides of the FDE model: tailored outcomes for a customer and reusable foundations for the company.

Two destinations for engineering work

The speaker separates changes by their likely reuse.

If a change is...	Its likely destination	Why
Bespoke: it solves a need unique to one customer	Customer-specific work	Other customers may not need it, so making it part of the common platform would add complexity without broad benefit.
Generalizable: it could help multiple customers or support a repeated pattern	The shared platform, in the long term	A common capability can be reused instead of rebuilt for each customer.

Here, bespoke means made for one particular customer. Generalizable means that the idea can be turned into something useful beyond that one account. A platform is the shared technical base on which FDEs assemble customer solutions. Its reusable building blocks were called primitives earlier in the talk.

The important word is eventually. The speaker does not say that an FDE must stop customer work and productize a useful discovery immediately. Nor does he provide a threshold, an owner, or a schedule for deciding when to do so. He only gives the long-term direction: reusable work should move toward the platform.

Why the boundary matters

Without this boundary, an FDE team can drift into a development shop. Each customer gets separate code and separate maintenance obligations. The company then repeats similar work, accumulates many one-off implementations, and depends on particular engineers to keep old work running.

The platform path creates leverage instead:

1. An FDE encounters a real customer problem.
2. The team determines whether the solution is likely to recur beyond that customer.
3. If it is reusable, the capability can be generalized on the shared platform over time.
4. Later FDEs can build from that capability instead of recreating it.
5. More of their effort can go toward the parts that truly need customer context.

In plain language, customer work can teach the company what its platform is missing. The platform can then make later customer work faster and less repetitive.

A concrete teaching example

Imagine that an FDE builds a special approval sequence for one customer's unusual internal policy. If no other customer has that policy, the sequence is likely bespoke work. Keeping it customer-specific avoids forcing every platform user to deal with an irrelevant feature.

Now imagine that several customers need to define approval steps, assign roles, and track the status of each step. The exact policies may differ, but the underlying capability is repeated. A shared workflow primitive could support that common pattern. FDEs could then configure the primitive for each customer rather than write the whole mechanism again.

This example explains the decision rule; it is not an example stated in the video. The video does not specify particular platform features or a formal review process.

FDE as a scouting function

The speaker adds an important second role for customer-facing work. FDEs do not only deliver the current solution. They can also scout for products or services that the company should build to make later customer work more successful.

That creates a feedback loop:

flowchart LR
  A[Customer-specific work] --> B[Learn a customer need]
  B --> C{Could this help more customers?}
  C -->|No or not yet| D[Keep it bespoke]
  C -->|Yes, over time| E[Generalize it on the platform]
  E --> F[Reuse it in later customer work]
  F --> A

The loop does not mean every observation becomes a platform feature. It means close customer delivery is a source of product discovery. A team can learn which missing capability prevents success, then make that capability reusable when it is appropriate.

Starting with few primitives is acceptable

Early in an FDE effort, the shared platform may have only a small number of primitives. The speaker says this is acceptable. The initial customer engagements can reveal which additional products or services are worth building.

This is a staged model, not a requirement to finish a complete platform before meeting customers:

1. Start with the primitives that exist.
2. Use customer work to learn where those primitives are insufficient.
3. Distinguish a one-customer exception from a repeatable gap.
4. Grow the platform around repeatable gaps over the long term.

The earlier warning still applies: a platform is what keeps FDE from becoming endless from-scratch custom development. Starting small is different from treating every customer implementation as permanently isolated.

The useful middle position

Two extreme interpretations are both wrong:

• “Put every customer request into the core product now.” This can make a shared platform cluttered with features that only one customer needs.
• “Keep all customer work bespoke forever.” This loses the reuse and maintenance advantages that the platform is meant to provide.

The speaker's answer is the middle position: deliver what a particular customer needs, while using repeated needs as signals for future platform investment.

What the source does and does not establish

In this brief answer, the speaker gives a direction for the platform boundary and describes FDE as a source of product and service ideas. The preceding audience question is incomplete in the transcript, so the exact examples that prompted the answer are unknown. The speaker also does not define a numerical reuse threshold, a governance process, or a timeline for promotion into the platform. Those decisions remain outside the source.