Standardisation vs Customisation

Every request for customisation feels like revenue. In a service business under financial pressure, saying yes to bespoke work keeps the lights on. But each customisation adds variety the system must absorb — variety that consumes the constraint, creates unpredictable delivery, generates disproportionate support demand, and makes it impossible to scale. Standardisation is not about turning customers away. It is about designing a product that delivers genuine value without requiring bespoke effort every time.

The customisation trap

The customisation trap is a specific pattern that affects service businesses, software companies, professional services firms, and any organisation that delivers value through expert people rather than manufactured products. It works like this:

1. A customer requests a variation from the standard offering. The request is reasonable. The commercial pressure to say yes is high.
2. The organisation says yes. The work is done. The customer is satisfied. Revenue is recorded.
3. The customisation creates a new support obligation. The bespoke configuration must be maintained, upgraded, and troubleshot separately from the standard product.
4. The next customer requests a different customisation. Yes again. Another variant in the installed base.
5. Over time, the installed base contains dozens or hundreds of variants. Each is subtly different. Each requires specialist knowledge to support. The total support burden grows faster than the customer base.
6. Developer time is consumed maintaining variants rather than improving the core product. New sales require the same bespoke work as old sales. The organisation cannot scale because every sale is effectively a new project.

Variety and the constraint

From a Theory of Constraints perspective, customisation is a constraint multiplier. Each additional variant in the installed base:

• Increases the knowledge required to support the base (constraint on Goalie effectiveness)
• Increases the scope of regression testing for upgrades (constraint on Toolmaker throughput)
• Increases the time required to scope new projects accurately (constraint on sales conversion)
• Creates hidden implementation complexity that only becomes visible mid-project (constraint on delivery)

The last point is the most damaging. Customisation requests that appear simple at the scoping stage frequently reveal hidden complexity during implementation — integration requirements that were not anticipated, configuration conflicts, data migration issues. The project expands. The developer is locked into delivery. New sales wait. The constraint is consumed by complexity that was accepted for a fraction of its true cost.

The Innovator’s Solution — Christensen

Clayton Christensen, in The Innovator’s Solution (2003), identifies the pattern by which successful disruptors enter markets. The insight relevant to standardisation decisions is this: the disruptive new product is not a stripped-down, cheaper version of the incumbent’s premium offering. It is a simpler, more focused product that does fewer things — but does the most important thing reliably, affordably, and without requiring specialist expertise to implement or maintain.

The incumbent’s response to the disruptor is almost always to add features, increase customisation, and move further upmarket toward the most demanding customers. This is rational for the incumbent’s existing customer base — and it is the mechanism by which the disruptor takes the mainstream market while the incumbent retreats to an ever-smaller segment of high-complexity, high-cost bespoke work.

The standardisation decision — deliberately simplifying the offer, defining a fixed scope, and delivering it repeatably — is the Innovator’s Solution applied to the organisation itself. It sacrifices the most complex and demanding work (which is also the most constraint-intensive) to capture the larger, simpler, faster-growing market segment that the current offer is too expensive and too slow to serve.

Lead users — von Hippel

Eric von Hippel’s lead user research identifies a paradox in product development: the most valuable insights for mainstream product design come from users at the extreme end of the adoption curve — users who are ahead of market trends and have already found workarounds to problems that mainstream users have not yet encountered.

In a B2B software context, the lead users are the customers who are getting exceptional results from the product — the Bright Spots in the customer base. They have typically adapted the product in specific ways, developed their own processes around it, and found use cases that the developer did not anticipate. They are the early evidence of where the mainstream market will be in two to three years.

Von Hippel’s corrected insight for the standardisation decision: lead user behaviour is the source of the standardised product hypothesis, not the source of the next bespoke feature request. The question is not “what does this lead user want us to build for them?” but “what are they doing that we could pre-configure for everyone?” Their bespoke adaptation becomes the next standard configuration option. Their workaround becomes the next built-in feature. Their exceptional results become the standard outcome.

From Bright Spot to Blueprint

The path from customisation trap to standardised offer follows a specific discovery sequence:

The Blueprint is not invented from theory. It is discovered from the installed base by asking: which customers are achieving the best outcomes, with the least implementation complexity, at the lowest ongoing support cost? What do they have in common? What configuration choices did they make? What business process did they bring to the implementation? The answers to these questions define the Blueprint — the standardised offer that delivers the best-case outcome for the easiest-to-serve segment of the market.

This is Bright Spots applied to the customer base rather than to internal operations. The Bootstrap CUSUM question: which customers have shown a structural upward change point in their key outcome metrics since adopting the product? Those are the Bright Spots. Their configuration and their process are the Blueprint hypothesis.

Writing a portfolio policy

A portfolio policy makes the standardisation decision explicit, written, and enforced at the scoping stage rather than the delivery stage. It answers three questions:

• What we deliver: a specific description of the standardised offer — what is included, what configuration options exist, what is out of scope.
• What we do not deliver: an explicit list of the customisation types that are no longer accepted, with a brief rationale. This is the Kill list from the PICK model applied at the product level.
• How we handle requests outside scope: a clear process for declining or redirecting out-of-scope requests without losing the customer relationship. This might include a referral to a partner, a scoped custom engagement at premium pricing, or a roadmap commitment for future inclusion.

Bootstrap CUSUM and the standardisation shift

The standardisation shift produces a specific signature across multiple Bootstrap CUSUM series:

• Implementation time per project — downward change point as Blueprint deliveries replace bespoke projects
• Support cases per customer — downward change point as predictable, well-documented configurations replace one-off solutions
• Sales cycle length — downward change point as fixed-scope offers reduce buyer risk and accelerate decisions
• New contract value — upward change point as faster, lower-cost deliveries increase throughput

The four change points together, coinciding with the portfolio policy implementation, are the statistical confirmation that the standardisation decision produced the structural shift. Pre-specify all four predictions before implementing the policy. The Study step of the PDSA cycle is not “does it feel like things are better?” It is: which of the four change points have appeared, and in which order?

Related concepts