Designing Platform Features From Customer Patterns
FDEs and product engineers have different incentives: FDEs ship customer-specific solutions, while product engineers build generalized platform features.
Why a Single Pass Looks Efficient
Organizations that deploy software to many customers often face the same question: once an engineer has built something for one customer, should that same engineer generalize it for the whole platform? A common answer is yes. The reasoning is that one person already understands the problem, so one pass through the work should produce both a working customer solution and a reusable feature. On paper this is one person, one pass, one result.
What do you think happens?
Before reading on: if one engineer is asked to build the customer solution and then generalize it in the same workflow, what do you think happens to customer engagement?
Reveal answer
It slows down, and the people involved become frustrated.
The source material argues that this instinct is a managerial error. Forcing one person to do both jobs in the same workflow slows customer engagement and frustrates the people involved. The efficiency is only apparent on paper.
The Single-Workflow Instinct
The single-workflow instinct treats generalization as a natural next step after customer delivery. The thinking goes that if an engineer has already built a feature for one customer, they should simply make it general enough for the whole platform before moving on. The problem is that two very different kinds of work are being scheduled into one sequence, and each one competes for the same person's time.
Customer deadlines are immediate and visible. Generalization work is slower and mostly invisible to the customer waiting for delivery. When both land on the same person in the same workflow, the customer deadline tends to win, and the generalization step either gets rushed or quietly drops away. The source's point is structural: the workflow itself makes the conflict, so better effort from the individual does not remove it.
Two Goals, Two Roles
Field Deployment Engineers (FDEs) and product engineers both write code that ends up in front of customers, so it is easy to assume they do the same work at different points in time. The source separates them by what each is trying to achieve. The FDE works close to the customer and is measured by whether a customer-specific solution gets shipped. The product engineer sits with the platform team and is measured by whether generalized features that serve the whole product get built.
The source uses a gravel road and highway comparison to capture this difference. A gravel road opens a specific destination quickly and is good enough for the traffic it has. A highway is built for broad, sustained use by everyone and takes longer to construct. The metaphor is about purpose, not skill. An FDE building a gravel road is not a weaker engineer than one building a highway. Asking the same person to finish the highway before opening the road for today's traffic delays the customer they are there to serve.
This is why the two roles should be judged by different finish lines. An FDE is done when the customer solution ships. A product engineer is done when the generalized feature exists for the whole product. Judging an FDE by the second standard, or a product engineer by the first, misreads what each role is for.
How Customer Work Reaches the Platform
If the FDE does not build the generalized version, the platform still needs to benefit from what the FDE learns. The source resolves this with two separate paths. The FDE stays focused on shipping the customer-specific solution. A distinct process, owned by the product organization, takes the FDE's work and pulls it into the platform on a slower cadence. The link between these two paths is documentation.
Read the diagram from left to right and notice where the FDE's responsibility stops. The FDE's output ends at the written record. Everything after that point, including reading the records, finding patterns, and building the generalized version, belongs to the product process, which runs on its own schedule. The FDE is not responsible for the arrow that leads into the platform.
From One-Off Fix to Platform Feature
The clearest way to see the handoff is to follow one pattern across customers. The example below is an invented scenario used for illustration; it is not taken from the source.
Three customers, one recurring problem
An FDE working with a first customer needs to export platform data in a format that customer's internal system can read. The FDE builds a custom export and documents it. Later, two more customers ask for something similar. How does the platform benefit?
- 1The first customer gets a shipped solution
The FDE builds the custom export on site and ships it. The FDE's success is measured by this shipment, so the customer is served without waiting for a platform-wide design.
- 2The FDE writes down what was built
The FDE records the custom work. This written record is the FDE's contribution to the platform, and it is what the product team will later read.
- 3The second and third customers repeat the request
The FDEs working with these customers also ship on-site solutions and also document them. Each record describes a similar problem from a different customer.
- 4The product team notices the pattern
Reading the records together, the product team sees that the same problem keeps recurring across customers. This is the kind of recurrence the source says the product team looks for.
- 5One generalized feature replaces the one-off fixes
The product team builds one generalized export capability that serves the whole product, replacing the separate custom fixes. The platform now gains a feature that no single FDE was asked to design.
Three customers were served quickly, and the platform gained one shared feature built from the pattern in their documentation.
Before generalization, the platform holds several separate fixes, each tied to one customer. After generalization, one feature serves all of them. The change is not that the FDE's code was rewritten for the platform. The change is that the product team, working from the FDE's records, built one reusable version.
Mistakes a Manager Can Make
The source's argument implies several concrete ways a manager can get FDE and product assignments wrong. Each one is shown below with an example from a hypothetical team, which is generated for illustration.
Common mistake Keeping one workflow for everything
What it looks likeA manager tells an FDE to ship the customer solution and then generalize it before moving to the next customer.
Why it failsCustomer delivery and generalization compete for the same person. The source notes this slows customer engagement and frustrates the people involved.
Do this insteadKeep the FDE on the customer solution and give generalization to a separate product-owned process.
Common mistake Treating documentation as optional
What it looks likeAn FDE ships a fix but writes only a sentence, or nothing, about what was built on the ground.
Why it failsThe source identifies the written record as the FDE's real contribution to the platform. Without it, the product team has no pattern to find.
Do this insteadTreat the written record as a required input to the product process.
Common mistake Measuring the FDE by platform output
What it looks likeA manager judges an FDE's quarter by how many generalized features they produced.
Why it failsThe source says the FDE is measured by whether a customer-specific solution gets shipped. Generalized features are the product engineer's measure.
Do this insteadMeasure the FDE by shipped customer solutions and the quality of their documentation, and measure product engineers by generalized features built.
Common mistake Having the FDE own what happens after the handoff
What it looks likeA manager asks the FDE to decide whether a pattern becomes a platform feature and to schedule its build.
Why it failsThe source places everything downstream of the documentation node inside the product process, which runs on its own schedule.
Do this insteadRoute pattern decisions and build scheduling through the product-owned process.
Common mistake Reading the gravel road and highway difference as a skill gap
What it looks likeA manager concludes that FDEs are less capable engineers because their work is not built for the whole platform.
Why it failsThe source frames the difference as one of purpose, not skill. A gravel road is built for a different job than a highway.
Do this insteadAssign each role work that fits its purpose and judge each against its own finish line.
Checking Your Understanding of Ownership
A team deploys a platform to many customers. An FDE builds a custom integration for one customer and ships it. Using the two-path structure from this article, decide which steps belong to the FDE and which belong to the product-owned process, and explain where the link between them lies.
Hints
- Look for the step where the FDE's output ends.
- Think about what the product team needs in order to notice a pattern across customers.
Key Takeaways
- Asking one person to both ship customer-specific work and generalize it in one workflow looks efficient but tends to slow customer engagement and frustrate the people involved.
- FDEs are measured by whether customer-specific solutions ship, while product engineers are measured by whether generalized platform features get built.
- The FDE's contribution to the platform is documentation of custom work, which the product team reads to find recurring patterns.
- A separate, product-owned process takes that documentation and pulls the work into the platform on a slower cadence, so the FDE is not responsible for what happens downstream.
- Managers avoid errors by keeping the two workflows separate, valuing documentation, and judging each role against its own purpose.