Generalizing Customer-Specific Features
A Forward Deployed Engineer builds features for a specific customer while working in the field.
A Customer Asks for Something the Product Lacks
Imagine a team that sells software to several large organizations. One of those organizations asks for a capability that the standard product does not offer. The obvious response is to build it for that organization alone. The less obvious question is what happens next, when a second, third, or fourth organization turns out to have the same underlying need. This article follows that question and looks at how a feature that begins as a one-off piece of work for a single customer can become a capability that the whole platform offers.
Keep one idea in mind as you read: the customer-specific build is not the end of the story. It is the raw material for something larger. The sections below trace that journey step by step, and then examine why the parts of the feature that differ between customers are handled differently from the parts that are shared.
Why a One-Off Build Is Raw Material
The Forward Deployed Engineer, usually shortened to FDE, builds features for a specific customer while working in the field. Because the FDE works from the customer's side of the relationship, the work naturally reflects that customer's data, workflows, and constraints. That is useful for the customer, but it also means the first version is rarely ready to be handed to every other customer as it stands.
A customer-specific build is best understood as evidence. It shows that a need exists and gives a concrete picture of what that need looks like. It is not, by itself, a finished product to ship to everyone.
Forward Deployed Engineer (FDE): an engineer who builds features for a specific customer while working in the field, close to that customer's own environment and needs.
Who Sends What to Whom
Three parties are involved when a feature moves from one customer toward the platform: the customer, the FDE who works with that customer, and the central product team. The product team is based in Palo Alto in the account the source describes. The FDE is the link between the customer's side and the product side, and the feature passes through that link in a fixed order. The diagram below shows the exchanges in the order they happen.
Read the diagram as a conversation over time rather than a single transfer. The customer and the FDE exchange the requirement and the first build. The FDE then passes that build to the product team for review. The product team does not stop at that review; it looks outward to other customers, and the FDEs who work with those customers join the design discussion.
From One Build to a Platform Feature
The source describes a sequence of steps that a customer-specific feature passes through before it becomes a standard platform capability. Each step changes what the team knows and what it does next. Follow the pipeline below from left to right, and notice that the last stage is where the feature is built once, in the central product, instead of being rebuilt separately for each customer.
- 1Review: once an FDE has built a feature for one customer, the product team reviews it and asks whether a more general version of the same feature belongs in the platform. The build is treated as evidence that a pattern exists.
- 2Find other candidates: the team looks for other customers where the same pattern might also show up. The source describes three or four such customers as the typical group.
- 3Design together: the FDEs working with those candidate customers are brought into a design discussion. The aim is to agree on a single design that would work at every candidate site, rather than adapting the original build case by case.
- 4Build once: the generalized feature is built a single time, in the central product, so that every customer receives the same underlying capability.
- 5Deploy locally: each FDE deploys the generalized feature for their own customer.
Tracing One Feature Through Its Stages
A Scheduling Feature Moves Toward the Platform
A hospital network asks its FDE for a shift-handoff summary that the standard product does not provide. Trace how this one-off request could become a platform feature, using only the stages described in the source. This scenario is illustrative and invented for teaching purposes; the source does not describe this particular customer.
- 1Stage 1: the customer-specific build
The FDE builds the summary for the hospital network. It reflects that network's shift structure, its reporting rules, and its data. At this point the feature is specific to one customer.
- 2Stage 2: the product team reviews it
The build goes to the central product team, which asks whether a more general version belongs in the platform. The team treats the build as evidence of a need, not as a finished product.
- 3Stage 3: other customers with the same pattern are found
The team looks for other customers whose work involves the same handoff need. Suppose three other organizations turn out to have it too. Their FDEs are brought in.
- 4Stage 4: one shared design is agreed
The four FDEs meet in a joint design session. Their goal is one design that works at all four sites, not four separate adaptations of the first build.
- 5Stage 5: the feature is built once and deployed
The shared feature is built in the central product. Each FDE deploys it for their own customer, and the details that differ between sites are handled in the customizable layer, discussed next.
The feature started as one customer's need, passed through review and joint design, and ended as a single platform capability that each customer's FDE deploys. The original customer's details did not have to be written into the shared core.
Why Customer Details Live in a Customizable Layer
The source is specific about what happens to the details that differ from customer to customer. Those details are not written into the shared core. They are left in a customizable layer. The shared feature supplies the common behavior, and the customizable layer carries the parts that vary. The diagram shows how these pieces relate to one another.
The reason for this separation follows from what the generalized feature is for. The feature is built once and shared, so anything written into the shared core is effectively imposed on every customer who uses it. Details that belong to one customer's data, workflows, or constraints would therefore be a poor fit for the core. Keeping them in the customizable layer lets the shared part stay common while each customer's variation stays visible and separate.
Mistakes Learners Make About Generalization
Common mistake Assuming the first customer build is ready to ship to everyone
Why it failsThe FDE works from the customer's side, so the build reflects that customer's data, workflows, and constraints. The source notes the first version is rarely ready to hand to every other customer as it stands.
Do this insteadTreat the first build as evidence of a pattern, then review it and check whether other customers share the need.
Common mistake Generalizing as soon as one other customer asks for something similar
Why it failsThe source describes looking for other customers with the same pattern, typically three or four, and bringing their FDEs into a joint design session. The point is to find a shared pattern, not to copy the build.
Do this insteadIdentify the group of customers with the same underlying need, then design one version that works at all of their sites.
Common mistake Writing each customer's variation directly into the shared core
Why it failsThe source states that the details that differ from customer to customer are kept in a customizable layer, not in the shared core.
Do this insteadKeep the common behavior in the core and place the varying parts in the customizable layer.
Common mistake Believing each FDE should rebuild the feature separately for their customer
Customer-Specific Feature Versus Platform Feature
| Aspect | Customer-specific feature | Generalized platform feature |
|---|---|---|
| Who builds it | An FDE, working for one customer in the field | Built once, in the central product |
| Whose needs it reflects | That customer's data, workflows, and constraints | The common behavior shared across the candidate customers |
| Where varying details sit | Within the single customer build | In a customizable layer, separate from the shared core |
| How it reaches others | Reviewed by the product team as evidence of a pattern | Deployed by each FDE for their own customer |
Contrasting a one-off build with a generalized platform feature, based on the stages and layers described in the source
The comparison makes clear that the two forms are not rivals. The customer-specific build is the starting point, and the generalized feature is what that starting point becomes once the product team has checked for a shared pattern and designed for it.
Practice Deciding Where a Detail Belongs
A generalized reporting feature is built once in the central product. Three customers use it. Two of them want the report to show totals in their own currency, and all three want the report to include a shared set of summary rows. Which part belongs in the core product, and which part belongs in the customizable layer? Explain your reasoning using the idea of common behavior versus varying details.
Hints
- Ask which parts all three customers share, since shared behavior is what the core carries.
- Ask which parts differ between customers, since those are the details the source says are kept in the customizable layer.
- The source does not describe currency handling specifically, so reason from the general principle rather than from a rule about currency.
Key Takeaways
- A Forward Deployed Engineer builds features for a specific customer while working in the field, and that first build reflects the customer's data, workflows, and constraints.
- The product team treats a customer build as evidence of a pattern, reviews it, looks for other customers with the same pattern, and brings their FDEs into a joint design session.
- The generalized feature is built once in the central product, and each FDE deploys it for their own customer.
- Details that differ from customer to customer are kept in a customizable layer, so the core carries the common behavior and the layer carries what varies.