Deep Dive — Platform PM Strategy & Operating Model

The platform strategy doc — what it is and why it matters

The strategy doc is the artifact that distinguishes a Platform PM from a project manager with a roadmap. It's a 6-12 page document, signed off by VP-Product, VP-Engineering, and at least one cross-functional leader (Compliance, in this role). It commits the org to a direction for the next 2-4 quarters and gives downstream teams the predictability they need to plan around you.

Typical shape, in the order interviewers expect you to write it:

1. Context — where the business is, what changed, why this matters now (1 page).
2. Current state — what the platform / non-platform looks like today, with concrete pain (1-2 pages).
3. Thesis — one paragraph. The bet you're making. Why this approach wins.
4. Target state — what good looks like in 12 months, with a diagram.
5. Migration / sequencing — how we get from here to there, in 90-day waves, with named unlocks per wave.
6. Non-goals — the things this strategy explicitly is not solving (this is where you de-scope).
7. Metrics — leading + lagging, with targets.
8. Risks & mitigations.
9. Resource ask — what you need, by team and quarter.
10. Open questions — what's not yet decided, what reviewers should weigh in on.

The platform thesis — why now

Every strategy doc rests on a thesis. For an onboarding platform rearchitecture, the thesis usually combines two clauses: a technical "the current shape doesn't scale" and a business "the cost of not doing this is rising fast."

Note the three clauses of "why now": product unlock, vendor leverage, regulatory ratchet. A thesis with one is weak; a thesis with three is hard to argue against.

Translating tech debt into business outcomes

This is the JD's most-quoted skill: "translate technical infrastructure work into business impact." The translation framework:

The rule: never say "tech debt." Always say the symptom and the business outcome. "We have to fork the codebase to launch a new market" lands harder than "we have tech debt."

The push-pull tension with feature teams

Feature teams want bespoke. They have ship dates. The platform wants generality. You have a strategy. This tension is permanent; managing it is the job.

Working principles:

• Default to no, escalate to yes. Don't accept every bespoke ask. Triage by counting: if N teams want similar, it's a primitive. If one team wants it, push back or partition.
• Accept the carve-out with an expiration date. Sometimes the right answer is "you can fork for 90 days; here's the merge plan." Documented carve-outs are fine; secret ones are how platforms die.
• Run a public intake. Every request gets a ticket, every ticket gets a public answer, every answer cites criteria. Removes the loudest-voice anti-pattern.
• Have a "shared roadmap" review monthly with the consumer-team PMs. Show what's coming, hear what's blocked.
• Embed when it matters. When Futures is launching in Germany, an embed of one platform eng for the launch window is cheaper than the alternative.

The internal-developer-experience scorecard

If your platform's customer is a team, you should measure their experience. The IDX scorecard, quarterly:

Publish it. Walk it through with the head of Engineering each quarter. It's the platform's report card.

PRD vs platform brief

Feature PMs write PRDs. Platform PMs write briefs — shorter, more API-shaped, less UX-shaped. The distinction:

A platform brief that reads like a feature PRD is a smell; reviewers ask "where's the API?" If you have a sample brief from your last role you can talk about, bring it.

Writing a strategy doc that gets signed off

The mechanical moves that turn a strategy doc from "interesting" to "approved":

1. Pre-wire the doc. Never share a strategy doc as a first read. Walk the top 3-5 stakeholders through it 1:1 first, capture their pushback, edit. The review meeting should have no surprises.
2. Write the non-goals before the goals. The fastest way to get approval is to make the doc obviously not-a-land-grab.
3. Make the migration plan as concrete as the target state. Senior reviewers care about the next 90 days more than the 12-month vision.
4. Name the dependencies you don't control and the date you need them by. Forces conversation upstream.
5. Include a "what if we do nothing" section. The strongest strategy docs make the do-nothing case visibly worse.
6. End with explicit asks. What headcount, what calendar time, which decisions you need from whom by when.

Influence without authority

Platform PMs have no one reporting to them and no one to fire. Influence is the whole job. Specific moves:

• Write more than you talk. The platform team that writes the best docs sets the agenda.
• Be specific about asks. "I need eng review by Tuesday" beats "I'd love your thoughts when you have time."
• Cite stakeholders by name. "Compliance signed off on this approach on Oct 4" makes the doc concrete and harder to relitigate.
• Run customer advisory boards informally. A standing 30-minute monthly with consumer-team PMs makes them feel ownership, which makes them defenders.
• Take meetings you can be ignored at. Show up at Compliance's weekly. Don't always present; just be there. Recognition compounds.
• Trade favors. Help a feature team land a launch on top of your platform; remember when you need their eng for a migration.

The operating cadence

A working Platform PM's calendar, in shape:

Worked example — a platform thesis for the company onboarding

If asked to articulate a thesis in the loop, this is a shape that works. Practice it aloud.

Notice the shape: current state, bet, sequencing with rationale, business outcomes, and a named risk with a mitigation. That's the template.