Adoption is earned, not mandated: winning consumers for a shared platform

Most shared platforms don't fail on technology. They fail because nobody chooses to use them.

I've delivered shared platforms in insurance and in payments, and I've seen both outcomes: platforms that teams queued up to join, and platforms they quietly worked around. The difference was rarely the code. It was whether the people who were meant to use the platform believed it would make their lives easier.

What is a shared platform?

In my view, a shared platform is the data, capabilities and services a consumer needs, but doesn't necessarily own. The consumer is the product or project team building something for customers. The platform gives them the pieces every team needs, built once and run well, so they can spend their time on what makes their own product different.

• Data: a trusted customer record, reference data and the definitions everyone agrees on.
• Capabilities: identity and single sign-on, partner onboarding, matching, payments validation.
• Services: APIs, observability, automated build and release, security controls.

Why consumers hesitate

Resistance to a shared platform is usually rational. Before trying to win anyone over, it helps to see the platform from the consumer's side of the table.

• Timelines: "My delivery date now depends on someone else's roadmap."
• Bottlenecks: "Every change I need becomes a ticket in another team's queue."
• Losing authority: "I'm accountable for the outcome, but I no longer control the parts."
• Fit: "Will it really handle my edge cases, or will I end up building around it anyway?"

What a shared platform can really do for them

Each of those worries has an honest answer, and a good platform is designed around them. In my experience, the answers that persuade are concrete, not architectural.

Seven ways to earn their choice

1. Start with their problem, not your platform

Nobody wakes up wanting a shared platform. They want to ship their project on time, without rebuilding customer matching, authentication or onboarding for the third time. On one programme, I invited the consuming projects into architecture workshops before asking for any commitment. We shared our scope openly and worked through their roadmap with them: what they would no longer need to build, how much sooner they could deliver, and what risk they could hand to us. Six projects adopted the platform, and the steering committee named it one of the key reasons the programme succeeded.

Ask every consumer: what would you stop building, and what would you ship sooner, if this worked for you?

2. Win one team, then make them the hero

The first adopter carries all the risk, so treat them like a partner, not a customer. Give them your best people, fix their blockers first and celebrate their success loudly. A peer saying "it saved us three months" persuades more teams than any architecture deck, and it answers the fit question better than any promise.

3. Make the easy path the right path

If using the platform is harder than building around it, teams will build around it. Self-service onboarding, clear documentation, templates and working examples matter as much as the core services. On a partner platform I led, onboarding took 73 days, with manual steps, including testing, along the way. Consolidating duplicated platforms with reusable APIs and workflow automation brought it down to 5–7 days and scaled capacity from 100 to 1,000 requests a day. Speed is the best sales pitch a platform has.

4. Contracts, not tickets

A platform that makes every consumer raise a ticket and wait becomes the bottleneck it was meant to remove. Publish versioned APIs and data contracts, keep them backward compatible, and give notice before anything is retired. Consumers should be able to build on you without asking permission.

5. Measure their outcomes, not your output

"We shipped twelve features" means nothing to a consumer. Track what matters to them: how long onboarding takes, how much they no longer build, the availability they can rely on. We made service health visible on SLO dashboards everyone could see. Open numbers give consumers back some of the authority they feel they've lost: they can hold the platform to account.

6. Use mandates as a backstop, not a strategy

Mandates get compliance; a better path gets adoption. Programme mandates and a reuse roadmap did help me, but only to make commitments concrete once teams had already seen the value. A mandate without value creates teams that comply on paper and work around you in practice.

7. Retire duplicates with evidence, not deadlines

Consolidation is where platforms win or lose their credibility. When I secured approval for a £40M convergence across 144 applications, the case rested on evidence about duplication, cost and risk.

The same discipline cuts the other way. One application was due to move to our in-house platform within 120 days, before its licence renewal. There were no requirements documents. My team reverse-engineered them and found more than 15 functional gaps and a compliance risk, so we stopped the move. Forcing a consumer onto a platform that can't serve them yet costs more trust than it saves money.

The short version

• Define the platform by what consumers need, not by what you own.
• Take their worries seriously: timelines, bottlenecks, authority and fit.
• Sell their outcome, not your platform, and make the first adopter a hero.
• Make the right path the easy path, and publish contracts, not ticket queues.
• Measure adoption and their results in the open.
• Mandate last, and move teams only when the platform is ready for them.

A shared platform is a product. Its customers are your colleagues, and like any customers, they choose. Earn the choice.