Platform PM

Login, permission checks, notification delivery — the pieces every team needs went without an owner for a long time. A product team building its own screens would hit one of them and write it on the spot, because shipping that screen was what the team was measured on.

Pagedeck ended up with three copies of the code that sends notifications. The document team, the search team and the mobile team each wrote their own, so editing one document fired the same alert three times. When Theo went to fix it there were three places to change, and the work sat on no team's plan. Nobody could say which of the three was the real one, so each team patched its own copy and they drifted further apart. It ran that way for half a year.

A platform PM exists to treat that foundation as a platform — the base layer other things run on top of — instead of leftover plumbing. The users are colleagues rather than paying customers, and the rest of the job holds: collect requests, decide the order, announce what changed.

The day starts by checking whether anything in the foundation went down overnight and ends by deciding which incoming request becomes a shared capability. The starting point is a pile of requests from other teams rather than a feature list, which is where the job splits from a product manager role in general.

Five steps repeat.

1. Read the outage log. When login processing stalls for five minutes, screens belonging to ten teams stall with it, so one failure spreads into a company-wide one. Reading the log is also how you learn which part of the foundation is thinnest, because the same component tends to break twice.
2. Collect the requests and count how many teams asked for the same thing. Three teams saying the same sentence is grounds for pulling the work into the shared layer; if only one team needs it, that team builds it faster alone.
3. Group requests that are worded differently. The search team's "permission checks are slow" and the mobile team's "let me fetch permissions in one call" describe the same doorway.
4. Write the spec. With no screen to look at, the contract for an API — an agreed doorway programs use to talk to each other — stands in for the interface. Rename one field and every team using it has to edit code.
5. Plan the migration. Building the new doorway takes two weeks; getting three existing teams to drop their old code and move over takes two months. Winning a slot on each team's plan for that work is part of the job.

A piece of work ends when the old path is switched off. You check that calls have dropped to zero, then delete it. Stop before that and two doorways keep doing the same thing, and a pile of those pairs is what technical debt looks like.

The people you work with are also your users. Whoever files a request is the colleague who has to live with the answer, so complaints arrive from the next desk rather than through a survey. Much of the week goes to teams that do not report to you, which leaves persuasion as the main instrument.

• Product managers on other teams — requesters and customers at once. At the start of a quarter you collect their plans and line up which piece of the foundation is needed by when.
• The engineers building the foundation — you write the spec together. With no screen to look at, what counts as finished has to be defined jointly.
• Infrastructure owners — the people running the servers and networks underneath. How rarely things break gets pinned down as an SLO, a service quality target the team commits to, and you both watch that number.
• Design system owners — the design system, the shared set of buttons and inputs screens are assembled from, is internal foundation too. You keep the front-end shared layer and the server-side one from drifting apart.
• Security owners — features like single sign-on (SSO), where convenience and exposure grow together, need their scope of access agreed jointly.
• The CEO — the person who asks why six engineers are spending a quarter on work nobody can see. Grace hears it as saved effort: three copies of notification code become one, so notification work drops to a third of what it was.

"I'll put that on the platform roadmap. Right now only the search team works that way, so pulling it into the shared layer needs two more teams."

Not a rejection — the case for making it shared isn't there yet.

"Nothing I do this quarter shows up on a screen. What you get instead is notification code in one place rather than three."

Saying up front that no visible feature is coming, and putting a number on what arrives instead.

"Calls to the old permission lookup hit zero last week, so we delete it next week."

A declaration that the migration is done, and a warning to speak now if any code still leans on that path.

At Pagedeck, Mia's first quarter in this role went into collapsing permission checks into one doorway. Four places did the same job, and asking about a single document's sharing scope from three screens produced three answers. Before building anything she met the four teams separately and wrote down what each of them actually asked for.

The spec took three weeks and the migration took two months. What the quarter produced was not a screen but a record: permission questions went from four places to one, and the same question started returning the same answer.

The most common mistake is assuming internal tools need less product sense than customer-facing ones, since users who sit nearby look easy to convince. Internal users always have another option, though. If the shared doorway doesn't fit their case they simply build their own again. The shared version has to be good enough that writing one themselves looks like the slower path. Miss that and the doorway you spent two months on goes unused, and the four copies you meant to remove become five.

A second reading treats the role as an intake desk that accepts everything. Turning down a colleague feels hard to justify. But a request only one team needs, once it lands in the shared layer, gets carried by every team that arrives after. A doorway with twenty options bolted onto it is one that a new team gives up on reading and rewrites for itself.