The Platform Engineering Playbook
A step-by-step guide to starting a platform that actually gets adopted: talk to users first, build a Minimum Viable Platform with the 3x3x3 method, harden it for production, and scale only once adoption is repeatable.
The Platform Engineering Playbook is a four-stage sequence for building internal platforms: (1) start small and run discovery interviews to find recurring friction, (2) build a Minimum Viable Platform, three paths, for one team, built by three people in one quarter, (3) run a Production Readiness Program to add identity, policy, and state, and (4) scale through a repeatable onboarding loop. It works the same whether your users are developers, sales reps, finance analysts, marketers, or legal counsel.
Section 01
Why most platform initiatives fail
Most platform initiatives fail the same way: they start too big, get funded like projects instead of products, build for too long without testing with users, and confuse renaming an infrastructure team with building a platform team. Instead, start small, learn fast and scale deliberately.
Platform initiatives rarely fail because people don't care or don't work hard. They fail because the initiative is structured in a way that makes learning too slow and adoption uncertain, with expectations detached from reality.
The recurring failure modes:
Starting too big. A grand platform for the whole organization before anyone has proven a single workflow improvement.
Optimizing for stakeholder narratives instead of user adoption. Impressive slides, indifferent users.
Project funding for a product problem. A one-year budget with optimistic KPIs attached before anyone has spoken to a user.
Building too long without testing. Months of prototyping on internal assumptions, then a late reveal and weak adoption.
Relabeling instead of rebuilding. An infrastructure or operations team renamed "platform team" without a product mindset.
Pulling users into new habits instead of meeting them inside existing workflows.
Solving internal irritation instead of meaningful user problems.
Most platform initiatives fail the same way: they start too big, get funded like projects instead of products, build for too long without testing with users, and confuse renaming an infrastructure team with building a platform team. Instead, start small, learn fast and scale deliberately.
Lead-in: The same structure fails the same way everywhere. In your world, it typically looks like this:
Reversing these mistakes gives you the outline of the playbook: start small and learn fast, then scale deliberately.
Section 02
The playbook at a glance
The playbook runs in three programs. The Minimum Viable Platform (MVP) proves value with three paths for one team. The Production Readiness Program (PRP) makes those paths dependable, adding identity, policy, and state, and develops a repeatable onboarding loop across three teams. The Platform Scaling Program (PSP) expands paths and teams with ROI proof, roll-out rhythms, and roadmaps built on the path lifecycle.
Figure 1: Playbook overview
Instead of launching a complete platform for the whole organization, you begin by working closely with users to identify a small number of high-value paths. You then make the case for a Minimum Viable Platform program using the 3x3x3 method: three platform engineers, building three paths, for three teams (starting with one). If that works, you don't scale immediately. You move into a Production Readiness Program to make the platform reliable and governable with a deliberately constrained user base. Only when users actively value the platform do you enter a Platform Scaling Program.
This sequence prevents the most common failure mode of platform work: large, slow, abstract investments without evidence that the platform solves meaningful problems in ways users will adopt. It tightens the learning loop, forces product thinking from day one, and lets the platform earn its growth instead of assuming it.
One practice stays central through all three stages: talk to users continuously.
Path
A reusable, governed way to get a recurring piece of work from a defined input to a guaranteed output, with the organization's constraints encoded inside it.
MVP (Minimum Viable Platform)
The smallest platform that proves demand: three paths, one team, no generalization, potentially throwaway.
PRP (Production Readiness Program)
The phase that adds identity, policy, and state so paths can be relied on daily, and produces a repeatable onboarding loop across the first three teams.
PSP (Platform Scaling Program)
The phase where you grow paths and teams deliberately, backed by ROI, a business case, and roll-out rhythms.
Section 03
Step 1: Start small
Start a platform initiative by improving the daily workflow of a single team of six to seven people, no budget request, no announcements, no KPIs, no big team. Build a Minimum Viable Platform of just three high-impact paths that users love enough to tell colleagues about.
The #1 recipe for success is counterintuitive: start smaller than feels comfortable. At this stage, don't ask for budget, don't announce anything, don't set KPIs, don't assemble a large team.
Why small wins:
01
You need to build the muscle
Interviewing users, prioritizing, designing, roadmapping: product work takes practice. There's a reason good product managers are scarce.
02
Unanchored expectations protect you
If you don't commit to KPIs you can't predict, you keep the element of positive surprise with almost no downside risk.
03
You avoid scaring users
If the rumor spreads that "a team has a mandate to change all our workflows," people go defensive and freeze. Platforms shift power dynamics; nobody moves while they're watching.
04
You need fans, not lukewarm users
Ten enthusiastic ambassadors beat ten thousand shrugs. Peers convince peers, the way real customer stories sell products better than a CEO on the homepage.
Borrow the startup mantra: do things that don't scale. Handhold onboarding. Give one-on-one support. It doesn't matter yet.
The running example (intro to the toggle): Throughout this page we follow one recurring workflow per vertical, from first interview note to production path. Switch the toggle to see your world.
Section 04
Step 2: Talk to users
Discovery interviews exist to answer three things: which three paths to build first, what impact removing that friction has, and which team to start with. Run at least five interviews with "most average" users, ground every conversation in a concrete recent example, and capture friction points and recurring intents, not feature requests.
Think of yourself as an explorer mapping an unknown shore: every flow and procedure in your organization that could one day be covered by a path. Early on you know nothing. As you interview, a map of value streams and paths surfaces. Log every session and every path centrally, spreadsheet, database, project tool, doesn't matter. That log becomes the most valuable thing your platform team owns.
The interview types you'll use over time
| Interview type | When | Purpose | Recurring? | ||
|---|---|---|---|---|---|
| Discovery (path discovery) | While prepping an initiative | Identify recurring intent and friction, select first paths, make the MVP case | No (per initiative) | ||
| Deep-dive (path understanding) | At the start of an initiative | Understand how selected intents are executed today | No (per path) | ||
| Path validation | During/after MVP build | Feedback on the current iteration | Yes (per iteration) | ||
| Adoption & experience | After paths are in use | Sustained value, workarounds, second-order effects | Yes (low frequency) | ||
| Roadmap discovery | After MVP shows value | Decide which paths come next | Yes | ||
| Edge/exception | At scale | Understand legitimate reasons to leave the path | Occasional |
How to set up discovery interviews
Script your opening. Why you're here (to understand how work happens today), who you are (a product manager exploring internal tooling, not evaluating performance), what you'll focus on, how long it takes.
Interview in pairs, one leads, one takes structured notes, or record with consent.
Pick "the most average" users. Not the loudest. Ask managers: "Which teams are the most representative of how work typically happens here?"
Five interviews minimum with the same persona across different teams. Fewer can't separate pattern from noise.
Ground everything in concrete recent examples. People are good at explaining what they'd like to happen and unreliable at predicting what would help.
Don't collect feature requests. Suggestions are clues about problems, not designs.
Listen beyond frustration. The most expensive frictions are often mentioned in passing: a wait, a context switch, a re-export.
Use silence. Pauses and hesitation point to unclear processes and brittle handoffs.
The four phases of a discovery interview
PHASE 01
Sketch the value stream
Ask the user to outline the broad lifecycle of their work in their own language, at low resolution. Then ask which phase hurts most, where friction shows up repeatedly, and narrow the rest of the interview to that phase. (Capture with Template B.)
PHASE 02
Locate friction points
Map where work slows, detours, or becomes awkward: points where progress depends on factors outside the team's control (external dependency) or on work that isn't their responsibility (internal non-core work). Naming and locating beats analyzing in depth. For every friction point, note who else is involved: reviewers, approvers, system owners. These actors define the real boundary of the path. (Capture with Template C.)
PHASE 03
Surface recurring intents
Behind each friction point, ask what the team is trying to get done each time, not how things should work. Intents are phrased in everyday language ("get approval so the campaign can go live") and describe what must be true for work to continue, never how. These intents are the raw material paths are made from. (Capture with Template D.1.)
PHASE 04
Assess the cost of the status quo
How often does this happen? How much time does it consume, for this team and for the teams they hand off to? These directional numbers become your baseline. It's hard to forecast the productivity gain of having something; it's much easier to record the cost of not having it. (Capture with Template D.3 + soft readiness signals.)
Across five conversations, a picture forms: certain intents repeat, certain frictions dominate, and a small number of path candidates stand out, not because you designed them, but because the organization revealed them.
A path candidate is interesting when five things are visible at once: a recurring intent, a clear start condition, a clear end condition, repeated friction, and a directional cost.
Section 05
Step 3: Capture what you learn, the templates
Four lightweight templates turn interviews into a shared memory: Template A anchors the conversation, Template B sketches the value stream, Template C logs friction points and intents, and Template D turns a selected candidate into a buildable path record. Below, each template is shown filled out, switch the vertical to see it in your domain.
These artefacts don't model reality perfectly, and they're not supposed to. Their purpose is a shared memory that lets patterns emerge across interviews.
Template A: Interview orientation sheet
Use this sheet to anchor every user conversation in a concrete example, interview type, and user context before moving into discovery or deep-dive questioning.
| Field | Notes |
|---|---|
| Team | Backend product team |
| Role (title only) | Senior software engineer |
| Type of work | New service launch |
| Concrete example | "Last typical go-live, the notifications service in April" |
| Interview type | Exploratory Deep dive |
Template B: Value stream sketch
Capture the broad flow of work in the user's own language. The goal is orientation: understand how work moves from initial intent to valued outcome before zooming into recurring friction.
| Step in the value stream | What typically happens | Who's involved? | Notes |
|---|---|---|---|
| 1. Design & scaffolding | Service is scoped; repo, pipeline, and environments are set up | Engineers, tech lead | Setup is repetitive but well understood |
| 2. Implementation | Features are built and tested in staging | Engineers | Core engineering work; not the main friction |
| 3. Go-live approval | Security review and architecture sign-off before production | Engineers, security team, architecture board | Repeated delays, evidence assembled manually, low engineering value |
| 4. Release | Service is deployed to production | Engineers, ops/SRE | Depends on explicit approval |
| 5. Operation | Service is monitored, patched, and evolved | Engineers, ops/SRE | Feeds future architecture decisions |
Template C: Friction & intent landscape
Use the value stream sketch to identify where work repeatedly slows down, detours, waits, or requires non-core coordination. These friction points are the raw material from which path candidates emerge.
| Step | Friction point: what blocks progress | Type of friction | Intent: what the team repeatedly needs to achieve |
|---|---|---|---|
| Quote approval | Waiting for deal desk to review the discount | External dependency Internal non-core | Get pricing approval so the quote can be sent |
| Quote approval | Waiting for legal on custom terms | External dependency Internal non-core | Get terms approval so the deal can proceed |
| Quote approval | Deal context re-explained in every thread | External dependency Internal non-core | Give approvers full context without rebuilding it each time |
| Quote approval | Feedback arrives across email, chat, and CRM notes | External dependency Internal non-core | Understand what must change without repeated clarification loops |
| Contracting | Approved quote version is unclear at signature time | External dependency Internal non-core | Ensure the version signed is the version that was approved |
Section 06
Step 4: Pick the first team
Choose a first team of six to seven people that shows clear recurring friction, is organizationally average, moderately mature, important but not existential, and stable. Force-rank three candidate teams so you always have a fallback.
Even with interviews done, don't go ask for budget yet. First decide which team to start with. It will shape your first paths, your early reputation, and the internal platform narrative. Look for five signals:
01
Clear and recurring friction
If nothing really hurts, your MVP won't matter. The upside must be visible without heroic storytelling.
02
Representative setup
The average stack, the average workflow, the average constraints. First paths must generalize; repeatability beats sophistication.
03
Moderate maturity
Highly optimized teams already run a self-built platform in disguise and your first iterations won't impress them. Disengaged teams won't collaborate. Aim between.
04
Important, but not existential
Don't start with the organization's lifeblood, you need room to iterate without existential pressure. But don't pick a surface nobody cares about.
05
Stability and availability
Teams get reorganized. Line up at least three candidates and force-rank them: build with one in mind, keep two warm.
Approaching the team: Ask for almost nothing. No budget on their side, no binding migration, no sunk time. Frame it as a controlled experiment: "We'll build something that targets the top friction points you described. Your only investment is feedback in a few short sessions. If it improves your workflow, you can choose to adopt it."
Further reading: Building your golden path: Lessons from the trenches (platformengineering.org): a practitioner's "what not to do" compilation on picking teams and rolling out a first golden path.
Section 07
Step 5: Make the case, the 3x3x3 method
The 3x3x3 method is the ask that starts a platform initiative: three people build three paths in three months (the build itself should take closer to three weeks, the quarter is buffer). The financial case is built on the cost of inactivity: frequency × time per occurrence × fully loaded hourly cost, a defensible lower bound.
What "3x3x3" means
Before talking to your manager, have four things in place: three concrete paths to build, three colleagues (including you) to build them, an estimate of what these paths save the organization, and a force-ranked list of three candidate teams. The 3x3x3 isn't a law but a scope control mechanism. If you need more, ask what you're really trying to validate.
The team: three people is the default. One should be (or act as) a product manager: they know how to interview users and stay lean. One should be the calm builder: a system thinker focused on removing the three key frictions. Bonus points if one of the three has been in the user's position and felt the pain.
The financial case: cost of inactivity
Don't invent productivity metrics. Measuring knowledge-worker productivity is an art nobody has mastered, and metrics like DORA are lagging indicators. At this stage you need leading indicators: concrete, observable inputs such as time spent on recurring friction.
The math is simple: how many times per year does the friction occur × hours it consumes (for the user team and the adjacent teams pulled in) × average fully loaded hourly cost (salary + ~40% for overhead). This is the absolute lower bound, it excludes delayed launches, context switching, and rework compounding across quarters.
| Step | Friction point: what blocks progress | Type of friction | Intent: what the team repeatedly needs to achieve |
|---|---|---|---|
| Quote approval | Waiting for deal desk to review the discount | External dependency Internal non-core | Get pricing approval so the quote can be sent |
| Quote approval | Waiting for legal on custom terms | External dependency Internal non-core | Get terms approval so the deal can proceed |
| Quote approval | Deal context re-explained in every thread | External dependency Internal non-core | Give approvers full context without rebuilding it each time |
| Quote approval | Feedback arrives across email, chat, and CRM notes | External dependency Internal non-core | Understand what must change without repeated clarification loops |
| Contracting | Approved quote version is unclear at signature time | External dependency Internal non-core | Ensure the version signed is the version that was approved |
The pitch
Keep the storyline simple and honest:
We've interviewed users in area X to understand where work consistently slows down. Across those conversations, three recurring friction points surfaced that cost us roughly Y per year. We'd like to run a small, contained experiment to address them: three people for one quarter, focused on a single team. The approach is to treat these workflows as products and iterate on them deliberately, commonly referred to as platform engineering. The cost is limited to headcount time. The outcome is a feasibility study with working paths and real user feedback, not a rollout. If it works, we have evidence to invest further. If it doesn't, we stop.
You're not overselling. You're running a test with a vetted hypothesis, and failure is a legitimate outcome. Managers think in quarters, asking for one is a low-risk move.
Further reading: What is a Minimum Viable Platform (MVP)? (platformengineering.org): an independent framing of the same MVP idea (the "HelloWorld app" test for representative and repeatable scope).
Section 08
Step 6: Build the MVP
The MVP program has three moves per path: a deep-dive interview that reconstructs how the work happens today, a design phase that starts from the maximum possible automation and reintroduces reality until a two-week buildable option survives, and a validation loop with the user. Three paths, roughly two weeks each, one team, no generalization.
Figure 2: During the MVP, focus on three narrow paths for one team. Do not optimize for reusability, central policy, identity, or state before demand is proven.
Budget approved? Back to your users. Discovery told you what to build; deep-dive interviews show how those workflows actually operate today. One interview per path, each intent has its own input regime, output regime, and policy topology, and blending them produces a picture that looks coherent on paper and fails in practice.
The deep-dive interview: three things you must leave with
Anchor the conversation in the last concrete occurrence, not "how it usually works." If the user can't recall a concrete example, that's a signal the intent is too rare or too vague to build against. Then walk the path step by step, slower than feels natural. Friction hides in small pauses, handoffs, clarifications, and workarounds. By the end you should be able to retell the story without filling gaps from imagination.
01
Input shape and variability
What triggers the intent? In what format does it arrive, and where does it live? What's always present, what's optional, what makes it messy? You're defining the minimum information the path needs to produce a valid result, not documenting today's implementation. Ask for the ugly cases, after mapping the normal flow.
02
Output shape, quality bar, and variance
The output is defined by what must be true for work to continue, not by what usually happens. Asking what "done" actually means reveals hidden requirements: recorded approvals, correct tagging, passing checks, updated documentation. By interview's end you should be able to state the output as a guarantee.
03
Policy gates and non-negotiable constraints
What must be true before work can proceed? Who signs off, explicitly or implicitly? Log not just the gate but the rule behind the gate: what security looks for, what triggers a legal block. Much of this lives as tribal knowledge ("legal tends to block that"); a well-designed platform gradually externalizes it into visible, versioned constraints.
The path record
Everything from the deep dive lands in Template D, the record that turns a recurring intent into something the platform team can design, validate, and build.
| Field | Notes |
|---|---|
| Path name | Service go-live approval |
| Intent (plain language) | Get security and architecture sign-off so the service can ship to production |
| Trigger | Service is feature-complete in staging and ready for review |
| Frequency (rough) | ~30 go-lives/year |
| Step | What happens today |
|---|---|
| 1 | Engineer opens a go-live ticket and links the repo and staging environment |
| 2 | Security scan reports are run manually and exported |
| 3 | Architecture diagram and config summaries are assembled in a doc |
| 4 | Ticket is assigned to the security review queue |
| 5 | Security feedback returns as ticket comments and chat messages |
| 6 | Configs and dependencies are patched based on feedback |
| 7 | Updated evidence is re-exported and re-attached |
| 8 | Architecture board reviews in its biweekly slot; questions raised |
| 9 | Context is reconstructed; design decisions justified in writing |
| 10 | Both approvals are confirmed in ticket comments |
| 11 | Engineer deploys, manually confirming the approved version is the one released |
| Field | Notes |
|---|---|
| Required input | Repo/branch reference, scan results, architecture diagram, config summary, data classification, target environment |
| Optional input | Threat-model notes, previous review outcomes, dependency exceptions |
| Ambiguous / hard to express | Which findings are blocking vs. advisory, who owns final sign-off, whether feedback applies to code, config, or design |
| Output artefact(s) | Explicit security clearance and explicit architecture sign-off, bound to a specific version |
| Next consumer | Deployment pipeline and operations/SRE |
| Quality bar | No open blocking findings, standards compliance confirmed, approvals explicit and traceable to the released artifact |
| Common rejection causes | Outdated scan results, undeclared dependencies, unclear data classification, approvals tied to the wrong build |
| Field | Notes |
|---|---|
| Hard gates / approvals | Security clearance mandatory before production; architecture sign-off for new services and major changes |
| Final authority | Security team (vulnerabilities and data protection); architecture board (standards and patterns) |
| Common rejection causes | Missing scan evidence, unapproved dependencies, config drift between reviewed and deployed versions, silence mistaken for approval |
Designing the path: dream big, then reintroduce reality
The progression is: map reality (done) → dream up the perfect capability → reintroduce reality → verify → choose with the user.
Start by deliberately ignoring restrictions: what's the maximum automation technically possible? Could the latest AI handle this end-to-end in seconds? That defines the automation ceiling. Then reintroduce reality in two checks: technical (can the technology shoulder this reliably?) and organizational (will this pass policy?). Keep falsifying until an option survives that's buildable in two weeks and still moves the needle.
| Field | Notes |
|---|---|
| Hard gates / approvals | Security clearance mandatory before production; architecture sign-off for new services and major changes |
| Final authority | Security team (vulnerabilities and data protection); architecture board (standards and patterns) |
| Common rejection causes | Missing scan evidence, unapproved dependencies, config drift between reviewed and deployed versions, silence mistaken for approval |
The takeaway is not which option wins. It's how it was chosen: first principles, falsified by technical reality, constrained by policy, cut down to a feasible slice that still moves the needle.
Building and validating
Build capability first, interface last. Start with the "expert interface", whatever scrappy setup accepts input and returns stable output. Only once outputs are stable do you design the real interface.
Meet users where they already live. Developers live in the IDE, build a plugin. Marketers live in Slack, build a bot. Sales lives in the CRM. People hate change; your job is to solve their problem faster inside existing habits, not to pull them into new ones.
Validate with a real run. Let the user execute the path end to end. Watch where they hesitate, double-check, or fall back to old habits. Inspect the output together: does it match their mental model of "done"?
Ask the two money questions: how long does a full run take now (this powers the scale-up case later), and, if this replaced the current flow, would they choose it voluntarily and recommend it to peers?
Never create hidden adoption costs. In the MVP, take on as much migration and integration work yourself as possible. A Norwegian government agency's textbook-perfect MVP stalled because onboarding required data migration that threatened the user team's roadmap, the VP was measured on roadmap delivery, so he simply kept delaying.
Figure 3: MVP path estate diagram
When is an MVP successful? It saves more than it costs to build and maintain, the paths work reliably, and users would use it daily and recommend it. If the primary user is indifferent but adjacent stakeholders benefit hugely, the MVP isn't invalid, the rollout strategy needs adjusting.
Section 09
Step 7: Go production-grade
The Production Readiness Program keeps the same three paths and makes them dependable: identity answers who triggered every run, policy independently verifies every output, and state records what happened and why. In parallel, you develop a repeatable onboarding loop: prepare, onboard, refine, across the first three teams.
Your MVP succeeded, congratulations. Now don't overestimate yourself. The initiative is a small flower that needs tender care. Two skills decide what happens next: going from experimental to production-grade, and mastering rollout for adoption. The second is always underestimated, building a great platform without an adoption plan is like knitting something, putting it in an online shop, and skipping distribution.
Sustaining management buy-in
For the MVP you promised tangible results. Now you have evidence instead of assumptions:
(Cost per run before − cost per run after) × number of runs per year = annual savings potential
A grounded, observed delta, not a vision. The pitch: "We built the MVP as promised, covering paths A, B, and C. The test team wants to use it in production, and rolling it out to comparable teams would save the organization X per year. We don't recommend scaling immediately, the next step is a production-grade version used daily by the first three teams. We're asking for another three months with the same small team."
Tailor emphasis to the audience: a CFO cares about cost structure, a CIO about standardization and risk, a business-unit lead about time-to-market. Same mechanics, different framing.
The three layers of production readiness
Figure 4: Identity, policy, state
Two things you already designed in Part 2, interfaces and capabilities, also need to harden at this stage. Interfaces must now survive everyday use: falsify invalid input early, use fixed inputs where correctness matters, and keep flexibility only where it doesn't; over-structured interfaces create bureaucracy people route around, while free text just creates noise. Capabilities make the jump from "it works" to "it works the same way every time": deterministic, bounded, and explicit about what they don't do. Production-ready capabilities behave less like assistants and more like contracts: they keep their promises, enforce their boundaries, and fail predictably.
Production readiness adds three new layers on top of that: identity, policy, and state.
Identity. Every run must answer: who triggered it, on what permission, and how do we trace it later? Rule of thumb: if someone isn't allowed to perform an action in the environment the path affects, they can't trigger the path. Identity follows roles, not individuals, with no new identity burden for users.
Policy (intra-system verification). One part of the system doesn't trust another's output without checking it. In software: a policy engine scanning configs and code. In marketing: an LLM with access to all written policies assessing compliance. In healthcare: a human gate. The policy layer greenlights or returns an explainable rejection.
State. The platform's memory: which paths ran, which outputs were produced, which policies applied, and why a result exists. Explicit, append-only, independent of originating tools. The test: "If someone asks in six months why this result exists, can the platform answer without anyone's memory?"
Designing for adoption: the onboarding loop
Keep the storyline simple and honest:
Figure 5: Onboarding loop
The onboarding loop has three phases: preparation, onboarding, refinement, and you run it for every team (and later every significant path update). Once introduced, adoption stops "happening to you" and becomes something you plan, iterate, and speed up.
Preparation covers the team (be explicit about what you expect and how the process unfolds; assume the first team mistrusts you by default; keep teams two and three warm) and the platform (wire their tools, configure the paths, set up identity, before the onboarding day; the last thing you want is to drum up a team and find the paths can't serve them).
Two checklists to steal:
Team readiness checklist (goal: confirm the team can be onboarded without surprises)
Expectations & commitment: team and manager know onboarding is happening; understand this is production use, not a demo; roadmap interruptions acknowledged
Timeline & logistics: onboarding date booked; required people available; backup team warmed up
Access & artifacts: platform team has access to required tools and systems; relevant docs and data reachable; no critical input depends on undocumented tribal knowledge
Third parties & sign-offs: reviewers/control functions identified and informed; sign-off mode clear (automated, async, or manual gate)
Decision readiness: no open blockers; open questions documented
Platform readiness checklist (goal: the path works reliably for this team)
System wiring: required tools connected; identity inherited from existing systems; roles and permissions configured
Path configuration: configured for this team's workflow; team-specific parameters set; known variations handled
Testing: executed end-to-end internally; output correct and complete; failure cases behave predictably
Policy enforcement: output checked against the relevant rules; failures return clear, explainable errors
State & visibility: every run logged with requester, output, decision; status visible; outputs traceable
Operational readiness: issue ownership clear; known limitations documented; fallback exists
Onboarding day: book too much time, dry-run with colleagues beforehand, demo the path and explain what happens under the hood, let every user execute each path at least once, and make it crystal clear they're not alone: a dedicated channel, a check-in booked for the following week, even your phone number for the first team. And remember: normality makes indifference, failure makes fans. Respond fast, acknowledge, fix visibly.
Refinement: log every team and path onboarded (you'll thank yourself at scale), capture an anonymous NPS, and fold every question into an FAQ for the next loop. Expect 10–20 repetitions before self-service onboarding is realistic. When in doubt, do it for them.
Figure 6: Loop refinement over iterations
Clarify responsibility before you scale
What works with three people breaks when ten teams depend on the platform. Set boundaries now: the platform team owns the design and operation of reusable paths, the tooling, and the user experience. Control functions (security, compliance, legal, risk) define constraints and non-negotiables. Infrastructure/operations own the foundational systems. The platform doesn't replace control functions or bypass governance, it operationalizes their constraints in a reusable way. Over time, repeated manual reviews reveal patterns that can become structured defaults and guardrails inside the platform: governance moves from reactive review to proactive design.
Section 10
Step 8: Scale deliberately
The Platform Scaling Program grows the platform without turning it into a bloated internal program: a team that scales sub-linearly with users, an ROI built on observed savings and (where possible) revenue, a business case answering why now / why this / what's next, roll-out rhythms that sequence teams deliberately, and roadmaps organized around the path lifecycle instead of feature lists.
You proved feasibility with the MVP, built a production-grade version, and refined a repeatable onboarding loop across three teams. You always delivered what you promised. Now it's time to hit the gas, deliberately.
Structuring your team
Team size is driven by how many paths you support and how many users you serve, and don't underestimate per-path maintenance (spec changes in underlying tools, policy updates, retraining, documentation). Add at least one person for maintenance and support beyond the original three, and grow from there. New hires often aren't needed: platform teams are frequently formed from operations teams, and that's fine, assuming people can't grow into a product mindset is the real mistake. One guardrail: if your platform team scales linearly with the users you serve, you have no effects of scale, you're operating as an operations team. The platform does the heavy lifting, not you.
Long-term roles to consider: a platform product manager, a technical capability builder, eventually UI/UX for workflow embedding, and at some point a leadership advocate: the Head of Platform Engineering (fittingly, HOPE).
Further reading: How to build your platform engineering team (platformengineering.org): role-by-role breakdown drawn from hundreds of platform teams, including the Head of Platform Engineering role.
Proving ROI
Keep laser-focused on money, that's what keeps you funded. ROI = net value created ÷ cost of investment.
Costs: loaded team cost (salaries + ~40% overhead) plus tool licenses.
Savings:
Direct time saved. You logged per-run savings in every path record. Example shape: a path saves 45 min for the primary user and 20 min for an adjacent reviewer, runs 120×/year → ~130 hours/year × fully loaded rate. Concrete and defensible.
Faster onboarding of new colleagues into a well-structured path estate.
Reduced churn: removing repetitive friction raises satisfaction; low churn proxies engagement and expertise accumulation.
Non-human savings: consolidated tooling, procurement at scale, reduced consumption costs (e.g., cloud spend).
One warning: never put job replacement into ROI calculations. It will happen, but the political implications are bigger than you imagine. Let reality do that job quietly.
Revenue: the ultimate discipline. Link the platform to revenue where credible: faster feature delivery in IT, more leads per quarter in marketing (cost-per-lead is already tracked), shorter patient throughput in healthcare. Attribution is hard; the value is real.
Add NPV on top of ROI: future savings discounted into today's money. It can feel like overkill, but finance teams read it as a signal that you care about getting this right.
Further reading: The platform scorecard: A practical way to prove value (and what to measure first) (platformengineering.org) and Top 5 takeaways from the State of Platform Engineering Report 2024 (platformengineering.org): the latter notes that roughly 45% of organizations don't measure platform success at all.
The business case: why now, why this, what's next
Why now: make the cost of not scaling explicit. Manual effort compounds, inconsistent outcomes slow teams, delayed output has opportunity cost. Calmly show the current situation doesn't scale.
Why this: you're not proposing a vision, you're scaling something that already works. Three production paths, three onboarded teams, a proven onboarding loop, documented savings. Incremental expansion of an existing capability, not a greenfield bet.
What's next: what you'll scale (teams, paths), the horizon, the cost envelope, and the metrics you'll report (usage, savings, revenue impact). Conservative assumptions, revisited as real data replaces estimates.
Five-slide structure: 1) current state and scaling problem, 2) what exists and proof it works, 3) proposed next step and scope, 4) ROI/NPV summary, 5) risks, assumptions, and how you manage them. Avoid overselling, credibility compounds faster than ambition.
Marketing and sales for platform teams
Two levers exist: sticks and carrots. Sticks (mandates, extra hoops for non-users) work only in strongly top-down cultures and backfire elsewhere, the platform becomes "the next thing management imposes." Better: make the platform genuinely more attractive (e.g., fewer security reviews for platform users), have leadership publicly position it as the future, or flip the script to onboard-by-default with opt-out.
Your most powerful tool is happy users. Record short interviews about why they onboarded and what changed. Put them on stage at town halls. Let peers convince peers. Give the platform a name and a logo, a platform is a little like the village fireplace people gather around. Offer monthly feedback sessions; even if attendance is thin (a good sign, nothing's broken), knowing how to contribute changes how users relate to it.
Roll-out rhythms
Scaling isn't new mechanics. It's how deliberately you reuse the onboarding loop. Roll-out rhythm is simply the decision of how often you run the loop and with whom. The common failure: demand spikes, exceptions pile up, onboarding dissolves into continuous background activity, and the platform team degrades into reactive support.
Sequencing question: not "who wants to onboard next?" but "which onboarding teaches us the most while introducing the least new risk?" Prioritize by:
Similarity: workflows close to what you support strengthen the playbook instead of stretching it
Frequency: often-run paths generate faster feedback, trust, and ROI
Ownership clarity: teams that can decide without cross-departmental negotiation stabilize faster
Timing: onboard alongside an existing moment of change (new initiative, compliance shift, tooling migration) so the platform feels like support, not disruption
Figure 7: Rollout sequencing quadrant
Saying "not yet" to a team is often the correct move. High demand is leverage. Keep a persistent rollout log: which teams run which paths, how setups differ, which exceptions exist, what version they're on, what each loop taught you. Format is unimportant; the habit is everything.
Further reading: Federated platforms: Scaling platform adoption in the enterprise (platformengineering.org): using a federated model instead of forced assimilation to sequence rollout without triggering political friction.
Designing roadmaps around the path lifecycle
Here's where initiatives quietly lose their shape: the "what next?" discussion regresses into a feature roadmap. Roadmaps turn into lists, lists into backlogs, backlogs into negotiations, and suddenly you're a reactive operations team again.
The real unit of platform progress is not a feature and not "the platform." It's the path. Every path moves through the same lifecycle: discover → build (minimum viable path) → validate → productionize → onboard → observe & refine, and eventually iterate again or retire.
Figure 8: Path lifecycle loop
Seen through this lens, a roadmap is a snapshot of where each path sits in its lifecycle. Every roadmap decision is one of three things: start a new path lifecycle, advance an existing path to its next stage, or re-run onboarding for an existing path. False debates ("adoption vs. innovation?") dissolve, different paths can and should be in different phases simultaneously.
Rule of thumb for updates: if a path's user-visible behavior, guarantees, or constraints change, run an onboarding loop. If not, skip it.
Designing roadmaps around the path lifecycle
01
Sense health continuously
Usage per path, bypass and override frequency, reported frictions, internal NPS. These aren't vanity metrics, they're early-warning systems that re-trigger the lifecycle.
02
Treat policies as evolving artifacts
Risk tolerance, regulation, and standards shift. Version policies, review them, and propagate changes through paths deliberately instead of via incidents.
03
Value relevance over completion
Paths are never finished. The moment users build workarounds, the platform is already behind. Keep asking whether each path is still the fastest, safest, most natural way to the outcome.
Section 11
FAQ
This is the sneak peek. The book is the full journey.
Part 3 of the book walks through every step on this page in depth: the interview scripts, the full template pack, the production-readiness model, ROI and NPV worksheets, and the roll-out playbooks we refined across hundreds of platform initiatives.
