Customizable Features

Imagine a product that serves many organizations, each with its own needs. Often the first working version of a capability does not start in a central product team. It starts with an engineer working directly with one customer, solving that customer's problem in the field. The solution may work very well, but it lives in that one customer's context.

This article follows what happens next. The question is how a solution built for one customer becomes something the whole platform can offer, so that later customers do not have to start from scratch.

The source describes a sequence that moves a feature from a single customer's engagement into the central product. The easiest way to follow it is as a trace of who does what and in what order. The field build is the starting observation. The generalized feature is the product of a design conversation. The deployment to other customers is what finally pays off the effort.

The starting point for generalization is recognizing that a feature built for one customer resembles a need elsewhere. Answering the product question requires looking past the specifics of the first customer and finding the underlying pattern. A feature is worth generalizing when that pattern is real and not just a quirk of one organization.

The search is deliberately small. The team looks at three or four other customers where the same pattern might apply. That number is enough to test whether the pattern holds across different settings, without turning the design effort into a survey of the whole customer base.

The idea of two layers is what makes the approach workable. The core is the part that gets built once, in the central product. The customizable layer is where customer-specific details live. Because those details are kept out of the core, the core stays the same for every customer while still fitting each one's situation.

The diagram shows one core with a separate layer for each customer. Every customer's layer attaches to the same core. The core does not change to suit one customer, because the things that differ live in the layers.

Once the central feature exists, it reaches customers through deployment. The feature is built once, and then each field engineer deploys that same feature for their own customer. The state of the work changes from several parallel builds to one implementation that many customers configure and use.

The source's example describes four engineers deploying one feature across four customers, instead of each engineer building a separate version. The effort of designing the feature is paid once, and the payoff comes from each later deployment. Avoiding duplicate builds is the reason the mechanism exists.