Core Platform: Defining the Shared Services Layer for Three Enterprise Products

I joined as Lead Product Manager, owning the shared platform underneath three enterprise products. I was there around eight months.

Three products were being built and all three needed the same things underneath: signing in, working out what each person is allowed to do, knowing which team and part of the business they belong to, moving work through approval steps, checking business rules, storing records so they can be found, audited and recovered, notifying people and talking to other systems. Nobody wants to build that three times, and if it is wrong once, all three products inherit the problem. That layer was mine.

I came in at the start of the platform work but not the start of everything. The domain discovery had already been done, so I wasn't working out what the industry needed. My job was turning it into a product: what the shared layer actually was, where its edges sat and what had to exist before anything could be sold. Three product managers covered four product lines. One colleague owned two of the products, another owned the third, and I owned the platform beneath all of them.

Why it had to be a product, not plumbing. A customer might buy one product, two or all three. That sounds like a commercial detail but it decides the architecture. If the shared layer is plumbing bolted onto whichever product ships first, it carries that product's assumptions. The second product either bends to fit or quietly builds its own version, and do that twice and you have three foundations pretending to be one.

The hard part was deciding what deserved to be a product. Breaking a system into modules only helps if the lines are in sensible places. Draw them badly and you get the same tangle as before, with more interfaces to maintain and more meetings to hold. The questions that kept coming up were about ownership, not features. Which capability owns a piece of data, which can change it and which can only look at it. And when a screen shows information, does it own that information or is it just a view onto someone else's?

The operating environment made it harder. This is a safety-critical industry that runs around the clock. A live operational view isn't an office application where a few minutes of downtime is an inconvenience. The system had to stay partly usable when parts of it failed, changes had to be auditable, rules had to give the same answer every time, and people had to work on the same records at once without overwriting each other. None of that can be added at the end, and several of those constraints change what the data model has to look like.

Working out what deserved to be a product. The first capability map was more fragmented than it needed to be. Several things had been proposed as separate products when they were really the same job. My test was simple. If the only real difference between two things is the shape of the data, that isn't two products. Take two capabilities that both store records, validate them, keep history and answer queries, and only differ in what the records contain. That is one capability with two record types. One team owns the behaviour once and the database handles the difference. Separation earns its place when something needs its own ownership, its own behaviour or its own ability to scale, not when it just has its own columns.

The decision I would most want to be asked about. Every existing product used one familiar industry term that every user would recognise. It named something real, but it had also quietly become the way the system divided up people, resources, permissions and operational data all at once. Inside any one product that made sense. Looked at across all four together, it didn't. The same real-world grouping existed four times, in four databases, maintained separately with nothing stopping them drifting apart.

So I stopped treating the familiar word as the structure. The underlying thing, a group of people or resources that work is organised around, became a generic construct any product could use, and the familiar term became one type of it. Users keep the language they know and the platform stops assuming everything is that one shape. It also fixed a problem nobody had linked to it. Without a shared way of saying where someone's responsibilities apply, you end up creating a separate role for every location. Three sites means three near-identical roles that drift apart. One role applied to three scopes holds the same information once. The fair objection was that this adds complexity. My answer was that the complexity was already there, and the choice was between holding it in one place on purpose or in four places by accident.

Settling ownership before anyone built anything. Every important business concept has exactly one owner and everything else points at it. A profile screen might show someone's team, role, skills and recent work without owning any of it. It is a view. Let it become a second copy and you have two answers to the same question and no way to tell which is right. Settling this at requirements stage is far cheaper than finding out after engineering has built it twice from two documents that disagree.

Writing the platform rules once. If every capability document repeats the rules for access, APIs, events, identifiers, audit and security, you write the same page many times and the copies slowly stop agreeing. So I wrote the platform-wide rules once and let each document cover only where it differed. That became governance rather than paperwork. Anyone picking up a new capability inherited a contract instead of a blank page, which stops a well-meaning team inventing a second permission model because nothing told them one already existed.

Prioritising by dependency, not effort. The first release question was never what is quickest to build. It was whether, if we ship only this, it can do its job and everything depending on it still works. A capability that stores records but can't let the product above search them isn't a smaller version of the product. It looks finished and blocks everyone. So the minimum had to include the unglamorous parts. What gets cut is sophistication, bulk administration and optimisation, not foundations.

Cutting scope across four product lines at once. Budget and timeline changed and this became the hardest part of the job. Phasing couldn't be decided product by product because everything sat on the shared layer, so it was really one decision made four times. What went into the first release of the platform determined what the products above it could include. That meant the other two product managers had to cut their own scope against a line I had drawn, which is a different conversation from prioritising your own backlog. You are asking people to give up things they believe in because of a constraint you defined. It works when the reasoning is visible and holds up, and it doesn't work at all if people think the line is arbitrary. Shortly before I left, a further rescope moved several capabilities to the platform team and merged others, which took the platform down by roughly a third. A capability count that only ever goes up means nobody is checking whether the boundaries still make sense.

From requirements to something a team can estimate. A requirements document isn't a handover. The specification layer is the one people skip and the one that matters. A requirements document can say the platform must support access that varies by area. The specification has to say what that means: default roles, how they are assigned, where scope comes from, how a capability registers what its permissions mean, how the allow or deny decision is made and how changes are audited. The two most useful columns were what is included and what success looks like, because a feature title is almost never enough to estimate from. "Search" could mean typing an identifier into a box or a whole search product, and nobody can size a word. Scenarios did a second job I hadn't expected, which was to break the specification. What happens when someone has edit rights in one area and read-only in another, or when a parent group and a child group both set the same value. Several of those sent a capability boundary back for another look.

The requirements nobody had written. There was no baseline for how well any of this had to work. As I started filling that gap I realised I was writing requirements that applied well beyond my own area. The obvious move was asking each area to write their own, but that stalled and waiting would have cost months. So I flipped it. I wrote a first pass and asked each area to react to it, which is a far smaller ask than originating something from a blank page. It came to 171 requirements, validated in group sessions with only minor changes. I used AI assistance heavily to produce them, so I wouldn't claim every line as my own writing. What was mine was the direction. Generated text will give you a generic availability requirement all day. Deciding that published operational information must stay readable when part of the system is down, and that this is a product behaviour rather than something infrastructure quietly sorts out, is a different kind of call. Several of these changed the design rather than sitting in a document.

Asking what hadn't been asked. Some of the most useful things I did weren't artefacts. Nobody had addressed how existing customers would move onto a platform replacing products they already ran, in an industry where changing a single workflow can take months. Nobody had set out what levels of recovery different parts of a safety-critical platform needed. And nobody had asked whether building on a single cloud provider meant we were choosing to be unable to leave. For a platform aimed at several regions with different rules about where data can live, that is a commercial question rather than a technical preference. I pushed to keep the option open and proposed a deployment approach for markets that require data to stay in country.

47 artefacts in four months.

• Capability requirements documents covering purpose, users, outcomes, ownership, dependencies, risks and scope boundaries
• Feature matrices scoping each capability against MoSCoW for the first release, with identifiers, priorities, inclusions, success criteria and dependencies
• Full product specifications for the identity and access layer, deep enough for engineering to estimate from
• A further requirements document and specification produced when the access model was rewritten during the rescope, against an updated template
• A non-functional baseline spanning every product line, the platform and development, 171 requirements, where none had existed before
• Common platform requirements and principles, so each document only had to cover its own exceptions
• Capability rationalisation model, consolidating a fragmented map and splitting one broad concept by responsibility rather than by data type
• The reusable grouping construct that replaced the overloaded domain term, plus the permission scoping built on top of it
• Dependency mapping, used to work out the minimum shared foundation the first product needed
• Phasing decisions across four product lines under budget constraint, with what was kept and what was deferred for each capability
• Cross-product journey and design work with the other two product managers and the product designer

• Where it stood when I left: the shared model was defined, the non-functional baseline validated in group sessions, the phasing agreed and several specifications detailed enough for engineering to estimate from
• The second rescope was in progress and the deployment architecture was still an open decision
• The capability count came down twice rather than only ever going up, which is the sign the boundaries were being checked
• Several of the 171 non-functional requirements changed the design instead of sitting in a document as acceptance criteria
• Customer migration, resilience levels and cloud portability were named early enough that fixing them was still cheap
• The design work that mattered crossed products rather than staying inside one, because what looked like interface questions were usually ownership questions in disguise

This is product definition rather than production performance. The non-functional targets are what the platform was designed to meet, not results achieved. It is a transformation programme rather than a single application, so it can't honestly be called shipped or not shipped.

On the absence of a deep dive. Every other entry links to a long technical write-up and this one doesn't, deliberately. The detail that would make it a good technical read, the capability map, the architectural decisions, the delivery sequencing and the contents of the baseline, sits inside a live programme building a product that hasn't been released. My other entries describe work that has since been retired, restructured or overtaken, which is why they can be written openly. This one hasn't, so the specifics stay unpublished and I am happy to talk through the thinking in person.