Platform Bypass Signal

When product teams build their own version of something the platform provides, the platform is slower, harder or less capable than the alternative for their case. That is information about the platform.

Responding with a mandate suppresses the signal and leaves the gap in place, which produces a platform that is used under duress and diverges further from need over time.

Why it matters

Adoption is the only honest measure of an internal platform's value, and it is only meaningful if it is voluntary. A platform with a mandate and no measurement has removed its own feedback loop, and there is then no mechanism by which it improves.

Implementation patterns

• Measure voluntary adoption and treat a decline as a defect report.
• Interview the teams that bypassed, since they have already done the analysis of why the platform did not fit.
• Make the paved road genuinely faster than the alternative. This is the entire mechanism: the compliant path must be the path of least resistance, or compliance depends on enforcement.
• Support escape hatches. A team needing one thing the platform does not provide should be able to opt out of that piece without abandoning the rest — otherwise every unusual requirement becomes a total defection.
• Manage compatibility and deprecation like an external API, because internal customers have the same migration costs and less patience.
• Fund the team as a product rather than a cost centre, since cost centres optimise for cost and product teams optimise for adoption — and that determines whether documentation, onboarding, support and developer experience get built.

Industry example

Multi-product SaaS organisations such as Freshworks, where several product lines share infrastructure, hit this predictably: the platform is built for the largest or oldest product, the newer ones find it a poor fit, and the response determines whether the organisation ends with one platform or several.

The pattern that works is the platform competing rather than mandating, with the small genuinely-mandatory set — security, audit, residency — mandated at the outcome level while the platform competes to be the easiest way to satisfy it.

Failure scenarios

• A mandate without measurement, so the platform drifts and nobody knows.
• No escape hatch, converting a single missing capability into a total defection.
• A platform solving the platform team's problem rather than the consumer's.
• Onboarding requiring a conversation, which caps adoption at the platform team's availability.
• Breaking changes without migration support, which destroys the trust that voluntary adoption depends on.

Trade-offs

Voluntary adoption means accepting duplication and inconsistency in the interim, and it means the platform team cannot guarantee coverage — which is uncomfortable for security and compliance functions who need to know that every service does a given thing.

The resolution is to separate the mandatory outcome from the optional mechanism: every service must have an audit trail and the platform provides the easiest way, with an alternative permitted if it meets the same bar. That preserves the guarantee without removing the competitive pressure that makes the platform good.

Interview question

"Three teams have built their own version of something your platform provides. What do you do first, and under what circumstances would a mandate be the right answer?"