Q&A：プラットフォームの境界と製品フィードバックループ

The focus of this question

This Q&A discusses where to draw the line between development for one customer and development of a platform that every customer can use. FDE (Forward-Deployed Engineering) works close to customers. However, that does not mean putting every customer request into the core product or leaving everything permanently customer-specific.

The speaker's decision rule

The speaker suggests the following boundary:

• What is unique to one company remains work for that customer.
• What seems useful to other customers is generalized on the platform over the long term.

Here, “generalizing” means redesigning a feature made only for a particular customer as a shared capability or shared primitive (a reusable basic building block) that other customers can also use. This decision is not simply about whether to accept a customer's request. It decides where to implement something by asking whether the same mechanism can be used in the future.

Example (for explanation)

If a special process is needed by only one customer, the FDE side may implement it for that customer. If the same kind of process becomes necessary for several customers, the team can consider whether it can become a shared primitive or product feature. This is an explanatory example; the speaker did not give a specific process or migration condition.

Why a boundary is necessary

If the same code or mechanism is built repeatedly for each customer, duplication grows. As a result, there is more to maintain, and FDE work can start to look like a development shop (dev shop). In contrast, putting a reusable capability into the platform lets one improvement benefit several customers. In other words, generalization reduces duplication and increases technical leverage.

However, this does not mean that every customer-specific piece of work should be moved to the shared platform. If something highly unique is forced into the product, it may introduce unnecessary complexity for that customer. The speaker says that what can be generalized should be generalized over the long term, but he does not give a criterion, owner, or deadline for deciding when to move it.

FDE also helps discover products, not only deliver them

In this model, FDE's work with customers is not merely delivery. By investigating what must be built in the customer's environment, the team can also see which capabilities are missing from the current platform. Customer work becomes “scouting”: finding products or services that may help other customers in the future.

The process can be organized as follows:

1. FDE builds a solution for the customer's problem on the current platform.
2. The team separates the parts needed only by one company from the parts that may also become necessary for other companies.
3. Over the long term, it develops the latter into shared primitives or products.
4. It serves the next customer using the stronger platform.

This cycle connects customer delivery with product discovery. FDE does not only build for customers; it is also a place to learn which capabilities are worth developing as products.

Does the platform need to be rich from the start?

According to the speaker, it is fine for an FDE team to have only a few shared primitives at the beginning. The team can handle customer projects, discover the capabilities it needs, and expand the platform along the way. Therefore, he is not saying that FDE cannot begin without a large, complete foundation.

On the other hand, permanently managing each customer-built piece separately leads to the maintenance burden described in the previous chapter. Starting with a small number of building blocks and returning what can be shared to the shared side over the long term are compatible.

Notes and limits of this Q&A

The audience question immediately before this answer is not fully preserved in the record. Therefore, we do not know specific examples of changes that should be assigned to the platform side or the customer side. The speaker also points toward generalizing what can be generalized over the long term, but does not explain a migration threshold or approval process.

Therefore, what this chapter supports is not a fixed operating procedure, but the principle of considering the boundary between customer-specific implementation and the shared platform by looking at uniqueness and reusability. Near the end, the speaker is checking the time while moving to the next question, so we cannot infer a new product policy from that moment.