Your AI platform is a product problem

Here's what makes AI platforms different from every other internal platform. Nobody defects from your payroll system. Nobody runs a shadow expenses tool. Your people are stuck with those, and the teams who run them have never once had to ask whether anyone actually wants to use them.

An enterprise AI platform is the first internal platform most organisations have built where the alternative is free, fast, very good, and already in your users' pockets.

Which makes it the first internal platform that has to win its users instead of assuming them.

That's a product job, and most companies aren't treating it like one.

You have segments, not a user base.

Someone handling client records has different tooling needs to someone drafting internal comms, different guardrails and different amounts of friction. One tier for everyone is easier to govern. It's also the quickest way to lose your best users to a browser tab you'll never see.

Segment your own people the way you'd segment customers. Work out which needs are shared and which genuinely differ, then build two or three tiers against that instead of one policy for everybody.

You have a roadmap, which means you say no.

Most AI programmes have a backlog made of everyone's favourite idea and no mechanism to kill any of it, because killing one feels like being against AI. Score them on impact, effort and risk. Publish the scores, and say no in the same forum the asks arrive in, so people can see the reasoning rather than assume politics.

And sequence it properly. The platform should fall out of use cases that already work, rather than arriving ahead of them. More on that in the second post.

AI platform Adoption is the metric, not deployment.

Rolling something out to 4,000 people is not adoption. It's a licence count disguised as a vanity metric. And a pretty expensive one at that.

Deployment is something you did. Adoption is something they did, repeatedly, when they had the option not to. A seat that gets opened twice and abandoned counts exactly the same as one someone has built their week around, which is why the headline number tells you nothing.

Run the lifecycle you'd run for a customer product:

• Activation. Did someone reach a first useful output, not just a first login.
• Habit. Weekly active use by role, and the share of a team's real work running through the platform.
• Retention. Who's still there at 90 days, and who quietly stopped.
• Depth. People moving from one workflow to several, or from chat into shared skills.
• Unit value. Cost per active user, set against the hours or the errors it takes out.

Each stage tells you what to fix next. Weak activation is an onboarding problem. Weak depth means you shipped one good use case and never found the second. Report these to your steering group and let the seat count sit in the appendix. Watch the leavers hardest. Churn on an internal platform is silent, and the people who go first are usually the ones who are getting the most out of it.

You need evidence, not enthusiasm.

Which means evals. Without a shared, boring, repeatable answer to "is this any good", you can't tell improvement from vibes and you can't put a number in a business case. We've written a practical guide to building AI evals, if you want the detail.

Build the eval set before you build the thing, with the people whose judgement you'd trust in a dispute. Start from first principles rather than a framework someone else wrote. A public benchmark tells you a model is good in general. It won't tell you whether this output is good for your business, which is the only question your steering group is actually asking.

Blend both kinds of signal in the loop. Scores and pass rates tell you whether something moved. The annotated failures, in the words of the people who caught them, tell you what to measure next. The qualitative half is the part most teams skip, and it's where the next version of your eval set comes from.

Keep the scoring itself boring and stable, or the number stops meaning anything in six months. The loop around it is where you get creative.

• Level 1 is individuals getting faster.
• Level 2 is teams redesigning how they work.
• Level 3 is where shared context, evals and governance stop being habits and become infrastructure.

Almost everyone stalls at three. I don't think that's a technology problem.

It's that Level 3 sits in the gap between IT, security and the business, and nobody has been handed the product mandate for it.

We've written separately about what the AI transformation levels above this start to look like, in our 3-part series on the Agentic Enterprise.

Plenty of organisations have staffed this with an architect or a head of data and treated adoption as an afterthought.

The technical questions here are hard, but they're answerable, and there are people who can answer them. The harder ones are product questions. Who is this actually for? What are we saying no to? And how will we know it worked?

It's the balance every good product team runs. Is it valuable, is it usable, is it feasible, is it viable for the business. AI platform programmes almost always have feasibility covered. The other three are where they come apart.

Nearly every organisation I speak to is standing one of these up right now, and most of them are going through the inevitable choice of whether to build or buy their platform.

The build side of that decision gets framed as a technical call almost every time. It isn't. If you build it, you've taken on a product with users who can walk, a roadmap you'll have to defend in front of people who all want their thing first, and a cost line that moves whether you touch it or not.

If you're in the middle of that call, I'd like to hear how you're framing it. And if it's more useful to see this than read about it, we've got demos and a fair bit of scar tissue to share.