The idea behind it
Platform as a product is the practice of running an internal platform the way a software company runs a product. The platform team treats the developer teams who build on it as customers. It finds out what they need, decides what to offer, and measures whether they choose to use it. Matthew Skelton and Manuel Pais made the idea widely known in Team Topologies, where a platform team exists to reduce the load on the teams that ship features. A platform built without this discipline tends to grow from the platform team's own interests and gets adopted only when its use is mandated.
The canvas borrows two tools from product management. Jobs to be done, associated with Clayton Christensen, describes what a user is trying to get done rather than which features they ask for. The when, I want to, so I can format is the job story, a way of writing a job that keeps the situation and the outcome in view. The paved road is Netflix's term for the supported, opinionated path through build, deploy and run; Spotify calls its version the golden path. Teams may leave the paved road, but they then carry more of the work themselves. Anti-goals set the platform's limits in writing, so requests outside its scope can be declined by pointing to an agreed page.
What's inside
- Platform identity: name, one-sentence mission, owner and version.
- Users: primary and secondary developer teams, personas and pain points.
- Jobs to be done: three jobs in a when/I want/so I can format, and the jobs the platform will not do.
- The paved road: what it includes, the off-road option and the support commitment.
- Five adoption metrics, such as adoption rate and time to first deploy, and four anti-goal prompts.
- A completed example for a fictional developer platform.
Format: PDF (4 pages) and PowerPoint file.
A look inside
Pages 1 and 2 of 4 of the PDF. Select an image to enlarge it.
Who uses it
- Heads of platform engineering, to agree with their own team what the platform is for before the next roadmap is written.
- Platform product managers, to turn developer interviews and support tickets into ranked jobs and a target for each adoption metric.
- CIOs and CTOs, to see in one page what an internal platform promises its users and how its progress will be judged.
- Engineering managers of the teams that use the platform, to check that their pain points made it onto the canvas.
When to use it
- A platform team is being formed, or an infrastructure team is being renamed a platform team.
- Adoption has stalled and teams keep building their own pipelines alongside the platform.
- The platform team is asked to take on a new capability, such as data or ML workloads, and needs to decide whether it is in scope.
- Support tickets to the platform team are rising and nobody has defined what the platform supports.
- A planning cycle starts and the platform roadmap has no measures tied to its users.
How to use it
Fill it in with the platform team and its users, and revisit the metrics and anti-goals each planning cycle.
- Fill in Platform Identity: the platform's name, a one-sentence mission stated as what it does for its users, a single accountable owner, and a version and date.
- Name the primary and secondary users under Our Users by team name, not as all engineers. Write two or three personas and the top three pain points.
- Write three jobs in the when, I want to, so I can format, with Job 1 the most important. List the user needs the platform will not take on under Jobs We Are NOT Doing.
- Describe The Paved Road: what the supported path is, the tools and services it includes, what happens when a team goes off it, and the reliability and support commitment.
- Record the current figure and a target for each of the five Adoption Metrics: adoption rate, time to first deploy, developer satisfaction, platform reliability and support ticket volume.
- Complete the four Anti-Goals prompts, including Success does NOT mean, the outcome that would look like progress but signal a problem.
- Compare your entries with the worked example for the level of detail expected, then revisit the metrics and anti-goals each planning cycle.
You leave with: A one-page statement of who the platform serves, the jobs it does and refuses, the paved road it supports, and the numbers it will be judged on. It can be put in front of developer teams and leadership as it stands.
Where it goes wrong
- Listing users as all engineers. The canvas asks for team names because a platform built for everyone is usually built for no one in particular.
- Writing jobs as features, such as add a Kubernetes operator. The job story format forces the situation and the outcome into the sentence.
- Counting a high volume of feature requests or tickets as success. The Success does NOT mean prompt exists to name these signals as warnings.
- Leaving the off-road option undefined, so teams that deviate either get no help or get the same support as the paved road.
Get the canvas
It is free. Enter your work email and we send the download link.
Questions
What does platform as a product mean?
It means an internal platform team treats the developer teams that use its platform as customers. The team researches their needs, chooses what to build, and measures voluntary adoption and satisfaction. The idea was popularized by Matthew Skelton and Manuel Pais in Team Topologies.
What is a paved road in platform engineering?
A paved road is the supported, opinionated path for building, deploying and running a service on an internal platform. Teams that stay on it get tooling and support from the platform team. Teams can leave it, but they take on more of the work. Netflix uses the term; Spotify calls its version the golden path.
How do you measure internal developer platform adoption?
Common measures are the share of eligible teams using the platform, the time a new user takes to deploy a first service, developer satisfaction, platform reliability and support tickets per team. Each needs a current figure and a target. Falling ticket volume and rising voluntary use are better signs than the number of features shipped.