Platform services — Giorgio Ratti

One shared layer, several products on top of it. Every decision below the line is a decision for all of them at once.

A product whose users are other teams

At TeamSystem I'm Product Owner on shared platform services: capabilities that several products depend on rather than products of their own. Two areas — the company registry domain, which answers who a customer legally is and who is entitled to act on its behalf, and activation, entitlement and metering, which cover what a product offers, what a given customer has active, and what they consume — including consumption that's counted in credits rather than in simple on/off features, as AI-based capabilities become part of the offering.

The thing that makes this different from every product role I've had before is who sits on the other side. There is no end user to interview. The people who depend on my service are other product teams and the business units behind them: they have their own customers, their own roadmaps and their own release dates, and my service is a dependency inside their plan.

Which means the two normal questions of product work — what should we build, and when — arrive already entangled with somebody else's answer to them.

Chapter 01

The company registry

Who the customer is · Who is entitled to act on its behalf

The same company shows up in more than one product, and it doesn't always show up the same way: the same fiscal identifier can arrive with conflicting registration details from different sources, a company can merge, split, or wind down, and the party operating on a company's behalf isn't always the company itself — a professional firm can act for several clients at once. A shared registry is the decision to have one durable identity for a company and one clear answer to who is actually entitled to act for it, instead of each product working that out on its own.

Most of the product work here isn't a screen, it's the model itself: what makes two records the same company, what happens to that identity when the company behind it changes legal form or ownership, and where the boundary sits between a company's permanent identity and the party operating on its behalf. Other teams build on top of those definitions and can't unilaterally change them later, so getting them right — and extending them as the model expands to new markets — is most of the job.

It's also increasingly an internationalisation problem: the same distinctions have to hold in markets with different company registers and different rules, without forcing every country into one rigid shape.

Chapter 02

Activation, entitlement and metering

What a product offers · What's active · What's consumed

This side of the work covers a chain rather than a single capability. A product declares what it can offer, packaged into groups of features that get switched on or off together. A customer ends up with some of it active and some of it not. Whatever is active gets used, and increasingly some of that use is metered by consumption rather than by a simple switch — credits spent on an AI-based capability, for instance, rather than a feature that's simply on or off.

Activation is the point where a commercial agreement stops being a document and starts being something the software does. Entitlement is the state that results — what a customer is allowed to reach right now. Metering is what actually happened, for the things that are counted rather than simply switched on. A recurring source of confusion for anyone new to the model: an upgrade to an existing subscription and a brand-new one look almost identical from the commercial side, but need to be treated very differently — getting that distinction wrong is a common failure mode I actively guard against.

The model also has to hold while it changes underneath. Right now it's mid-migration: an older model built around a fixed catalogue of services is being replaced by a more general one built around capabilities, features and actions — richer, but only usable if what's already integrated keeps working while the new model is rolled out underneath it, which means the old interfaces stay alive, quietly pointed at the new data.

It also widens the stakeholder map. A change here is a product decision, an engineering decision and a commercial decision at once, and it's visible to a customer in the least forgiving way: something they paid for that isn't there, or something counted differently from what they expected.

My role

Product ownership between the consuming product lines, engineering and the commercial side. Concretely:

Direction

Collecting needs from the product lines and business units that consume the services
Deciding what belongs in the shared model and what stays local to a product
A roadmap that has to fit inside other roadmaps

Definition

Turning needs from several products into a single specification and a consistent naming convention
Defining behaviour other teams will build against — API contracts, event payloads, lifecycle rules
Working through the cases only one consumer has, without letting them leak into the shared model

Delivery

Working with engineering and architecture on sequencing and dependencies
Managing an intake channel so requests reach the team in a form the team can actually act on
Releasing without breaking what already integrates, including during an in-flight migration to a new model

Alignment

Product, engineering, architecture and commercial stakeholders across several business units and markets
Owning the documentation that other teams rely on to self-serve instead of asking
Saying no in a way that leaves the other team a path forward

What makes it hard

The difficulty of platform work isn't technical depth — it's that the usual product instruments stop working the way they're supposed to.

There is no single customer to ask. Several teams and business units answer the same question, and each answer is legitimate from where they stand.
Almost every request arrives as an exception to the shared model. Granting one is cheap; granting three turns the model into a collection of special cases — so the default has to be proposing a solution that fits the existing model, not opening the question back up.
Many requesters don't have the technical background the model requires. Part of the job is telling apart a decision the platform team should simply make and communicate, a business question dressed up in technical language, and a genuine yes/no confirmation — and not pushing an open-ended technical question back to someone who can't answer it.
Prioritisation is not by value alone. A small piece of work that unblocks a team with a real external deadline beats a larger one that nobody is waiting on — and telling a real deadline apart from an internal planning date is most of the work.
A shared service can't change on its own schedule. Whatever ships has to keep working for everything already integrated with it, which is exactly what makes an in-flight migration to a new model slow by necessity.
Done well, the work is invisible. A platform service is noticed when it's missing, when it's late, or when it breaks — never when it simply holds.

A platform team's roadmap is the intersection of other people's roadmaps.

Three questions I keep coming back to

Shared, or local?

The recurring decision. Putting something in the shared model makes it consistent everywhere and expensive to change; leaving it local keeps a team fast today and guarantees a divergence to reconcile later. The honest test I use is whether a second product would need the same thing for the same reason — not whether it could be generalised, because almost anything can.

In practice, the sharpest version of this test is: how many independently switchable capabilities does a product actually have? That's the right question to ask, rather than how many structural groupings it thinks it needs — teams reach for a new structural layer when what they actually need is another entry in an existing one, and the honest answer usually costs them nothing.

Whose deadline is real?

Every consuming team arrives with a date. Some are commitments to a customer, some are internal planning. Telling the two apart is most of prioritisation here, and getting it wrong costs credibility in both directions — with the team that waited for nothing, and with the one that was made to wait.

In practice this is also why the intake channel matters as much as the roadmap itself: a request that could be answered from existing documentation shouldn't compete for attention with one that genuinely needs the team's judgement. Making self-service the default before a request reaches a person is what keeps the real deadlines visible.

What has to be decided now, and what can stay open?

In a shared model some definitions are effectively permanent, because other teams build on them and won't be able to move afterwards. Others can be left deliberately unresolved. Knowing which is which — and resisting the pressure to settle everything early — is what keeps the model usable a year later.

The migration to the new model is a live version of this: the old interfaces had to be decided immediately, because too much already depended on them, so they were kept running by quietly repointing them at the new data underneath. What could stay open was almost everything about the new model's internals — as long as the surface other teams touch didn't move under them.

Where it is now

This is current work, not a finished story. It's also the part of my work I can say the least about publicly: the interesting material is internal, and the numbers that would make the page more convincing are not mine to publish.

So the page describes the shape of the problem rather than the results. What I can say is that this is the first product role where the hardest part is not deciding what to build, but agreeing on what things mean — and getting several teams, across several markets, to depend on that agreement.

One honest thing I'd flag: even the tooling meant to reduce load on the team can quietly work against its own goal if it isn't tuned carefully — a first-line automation that answers with the wrong voice, or engages when it shouldn't, erodes trust faster than having no automation at all. Getting the small mechanics right turned out to matter as much as getting the model right.