Project 5: Platform-as-a-Product Blueprint

Design a product strategy for an internal developer platform (IDP) with value proposition, feature roadmap, and success metrics.

Quick Reference

Attribute	Value
Difficulty	Advanced
Time Estimate	2 Weeks (25-35 hours)
Primary Language	Markdown / JSON
Alternative Languages	HTML, Figma (for mocks)
Prerequisites	Understanding of developer workflows, platform concepts
Key Topics	Platform Engineering, Product Management, Developer Experience

1. Learning Objectives

By completing this project, you will:

Think of internal tools as products with customers and value propositions
Identify developer pain points and translate them to platform features
Design a “Thinnest Viable Platform” (TVP) that provides value without over-engineering
Define success metrics for internal platforms (adoption, NPS, time-to-hello-world)
Create a roadmap that balances quick wins with strategic vision

2. Theoretical Foundation

2.1 Core Concepts

The Platform-as-Product Mindset

TRADITIONAL INFRASTRUCTURE         PLATFORM-AS-PRODUCT
┌─────────────────────────────┐   ┌─────────────────────────────┐
│ "We're a support team"      │   │ "We're a product team"      │
│ "Developers are requesters" │   │ "Developers are customers"  │
│ "Tickets in, infra out"     │   │ "Self-service, no waiting"  │
│ "We build what we're told"  │   │ "We discover what's needed" │
│ "Success = tickets closed"  │   │ "Success = adoption rate"   │
└─────────────────────────────┘   └─────────────────────────────┘

The Thinnest Viable Platform (TVP)

Not “Minimum Viable” but “Thinnest”—the least intrusive layer that still provides value.

                    ┌─────────────────────────────────────┐
                    │         DEVELOPER EXPERIENCE        │
                    │  (What devs interact with daily)    │
                    └─────────────────────────────────────┘
                                      │
                    ┌─────────────────┴─────────────────┐
                    │     THINNEST VIABLE PLATFORM      │
                    │                                   │
                    │  ┌───────────────────────────┐   │
                    │  │ Self-service provisioning │   │
                    │  │ Golden path templates     │   │
                    │  │ Observability defaults    │   │
                    │  │ Security guardrails       │   │
                    │  └───────────────────────────┘   │
                    │                                   │
                    │  NOT: Complex abstractions       │
                    │  NOT: Mandatory workflows         │
                    │  NOT: Heavy governance           │
                    └─────────────────────────────────┘
                                      │
                    ┌─────────────────┴─────────────────┐
                    │       UNDERLYING INFRASTRUCTURE    │
                    │  (Cloud providers, Kubernetes)    │
                    └─────────────────────────────────────┘

The Golden Path

A paved road that makes “the right thing” also “the easy thing.”

Aspect	Golden Path	Alternative Allowed?
CI/CD	Standard pipeline	Yes, but you maintain it
Logging	ELK with standard format	Yes, but no support
Secrets	Vault with rotation	No exceptions
Deployments	Kubernetes + ArgoCD	Yes, with review

2.2 Why This Matters

Platform teams fail when they:

Build what they think developers need (not what they actually need)
Create abstractions that are more complex than raw infrastructure
Force adoption through mandate rather than value

The “Credit Card Test”: If teams had a budget and could choose between your platform or raw AWS, would they pay for your platform?

2.3 Historical Context

Heroku (2007): First successful PaaS with “git push to deploy”
Netflix Platform (2010s): Internal platform for 1000s of microservices
Spotify Backstage (2020): Open-sourced internal developer portal
Platform Engineering (2022+): Recognized as distinct discipline

2.4 Common Misconceptions

Misconception	Reality
“More features = better platform”	Simpler = more adoption
“Developers will use it if we mandate”	Mandates create resentment and workarounds
“One platform fits all”	Different teams have different needs
“Platform team doesn’t need a PM”	Platforms need product thinking more than most

3. Project Specification

3.1 What You Will Build

A comprehensive Platform Product Brief including:

Vision and mission statement
Developer personas and pain points
Feature roadmap (TVP → Full Platform)
Success metrics and measurement plan
Mock portal/UI concepts

3.2 Functional Requirements

Developer Research
- Identify 3 developer personas
- Document top 5 pain points per persona
- Prioritize based on frequency and severity
Platform Vision
- One-paragraph vision statement
- Three core principles
- What the platform is NOT
Feature Roadmap
- TVP (Quarter 1): 3 features that provide immediate value
- Growth (Quarter 2-3): 5 features that expand scope
- Maturity (Quarter 4+): 3 features that complete the vision
Service Catalog Mock
- Design the “storefront” experience
- Show how developers discover and use services
Success Metrics
- Leading indicators (usage, NPS)
- Lagging indicators (lead time, reliability)

3.3 Non-Functional Requirements

Document must be understandable by non-technical stakeholders
Roadmap must include effort estimates (T-shirt sizes)
Metrics must be measurable with available data

3.4 Example Usage / Output

Platform Vision Document:

# Acme Developer Platform

## Vision
Enable every developer at Acme to ship secure, reliable software in
minutes instead of days—without needing to understand infrastructure.

## Mission
Reduce cognitive load by providing self-service, opinionated defaults
while preserving escape hatches for edge cases.

## Core Principles
1. **Self-Service First**: No tickets, no meetings for standard requests
2. **Golden Path, Not Golden Cage**: Defaults are easy; alternatives are allowed
3. **Developers Are Customers**: Measure adoption, not mandates

## What We Are NOT
- A gatekeeper that slows down teams
- A one-size-fits-all solution
- A replacement for developer skill

---

## Developer Personas

### Persona 1: "New Hire Nina"
- **Role**: Junior Developer, 6 months at company
- **Pain Points**:
  1. "I don't know how to deploy my first service"
  2. "I can't find documentation for our internal tools"
  3. "I'm afraid of breaking production"
- **Platform Need**: Guided onboarding, templates, safety rails

### Persona 2: "Veteran Victor"
- **Role**: Senior Engineer, 5 years at company
- **Pain Points**:
  1. "I spend 2 hours setting up each new service"
  2. "I want to use a new database but can't get approval"
  3. "Our CI is slow and I can't configure it"
- **Platform Need**: Self-service, flexibility, speed

### Persona 3: "Manager Maria"
- **Role**: Engineering Manager, owns 3 teams
- **Pain Points**:
  1. "I don't know what services my teams own"
  2. "I can't prove we're meeting SLOs"
  3. "Audits take weeks to prepare"
- **Platform Need**: Visibility, reporting, compliance

Roadmap (JSON):

{
  "roadmap": {
    "q1_tvp": {
      "theme": "Remove the First Friction",
      "features": [
        {
          "name": "Service Templates",
          "description": "One-click creation of a new service with CI/CD, logging, monitoring preconfigured",
          "effort": "M",
          "value": "High",
          "metric": "Time from idea to first deploy"
        },
        {
          "name": "Namespace Self-Service",
          "description": "Developers can create their own Kubernetes namespaces without a ticket",
          "effort": "S",
          "value": "Medium",
          "metric": "Tickets to platform team"
        },
        {
          "name": "Developer Portal v1",
          "description": "Central place to discover existing services and their owners",
          "effort": "L",
          "value": "High",
          "metric": "Portal daily active users"
        }
      ]
    },
    "q2_q3_growth": {
      "theme": "Expand the Golden Path",
      "features": [
        {
          "name": "Database Provisioning",
          "description": "Self-service Postgres/Redis with backup and monitoring",
          "effort": "L",
          "value": "High"
        },
        {
          "name": "Secret Management",
          "description": "Vault integration with automatic rotation",
          "effort": "M",
          "value": "High"
        },
        {
          "name": "CI/CD Templates",
          "description": "Reusable pipeline components for common languages",
          "effort": "M",
          "value": "Medium"
        },
        {
          "name": "Cost Attribution",
          "description": "Show each team their cloud spend",
          "effort": "M",
          "value": "Medium"
        },
        {
          "name": "SLO Dashboard",
          "description": "Automatic SLO tracking for all services",
          "effort": "L",
          "value": "High"
        }
      ]
    },
    "q4_maturity": {
      "theme": "Complete the Experience",
      "features": [
        {
          "name": "Progressive Delivery",
          "description": "Canary deployments and feature flags",
          "effort": "L",
          "value": "Medium"
        },
        {
          "name": "Platform API",
          "description": "Programmatic access to all platform capabilities",
          "effort": "L",
          "value": "High"
        },
        {
          "name": "Maturity Scorecard",
          "description": "Track and improve service operational maturity",
          "effort": "M",
          "value": "Medium"
        }
      ]
    }
  }
}

Success Metrics:

## Success Metrics

### Leading Indicators (Weekly)
| Metric | Target | Current | Status |
|--------|--------|---------|--------|
| Portal DAU | 80% of engineers | 45% | 🟡 |
| Template usage | 90% of new services | 65% | 🟡 |
| Time to first deploy | < 30 min | 2.5 hours | 🔴 |
| Platform NPS | > 50 | 35 | 🟡 |

### Lagging Indicators (Monthly)
| Metric | Target | Current |
|--------|--------|---------|
| Change failure rate | < 5% | 8% |
| Deployment frequency | Daily per team | 3x/week |
| Lead time for changes | < 1 day | 4 days |
| MTTR | < 1 hour | 2.5 hours |

3.5 Real World Outcome

You will have:

A document that could be presented to VP Engineering to secure investment
A roadmap that aligns team work with measurable outcomes
Mock designs that show the developer experience vision

4. Solution Architecture

4.1 High-Level Design

┌─────────────────────────────────────────────────────────────────┐
│                    PLATFORM PRODUCT SYSTEM                      │
└─────────────────────────────────────────────────────────────────┘
                              │
        ┌─────────────────────┼─────────────────────┐
        │                     │                     │
        ▼                     ▼                     ▼
┌───────────────┐     ┌───────────────┐     ┌───────────────┐
│  DISCOVERY    │     │   DELIVERY    │     │  MEASUREMENT  │
│               │     │               │     │               │
│ - User        │     │ - Templates   │     │ - Usage       │
│   research    │     │ - Self-service│     │   analytics   │
│ - Pain points │     │ - Portal UI   │     │ - NPS survey  │
│ - Personas    │     │ - APIs        │     │ - SLO tracking│
└───────────────┘     └───────────────┘     └───────────────┘

4.2 Key Components

Developer Portal: Central UI for discovering and using platform
Service Templates: Pre-configured starting points
Self-Service APIs: Programmatic access to platform capabilities
Metrics Dashboard: Track adoption and impact

4.3 Data Structures

# platform-catalog.yaml
services:
  - name: kubernetes-namespace
    category: compute
    self_service: true
    sla:
      provisioning: "< 5 minutes"
    docs: https://platform.internal/docs/namespaces

  - name: postgres-database
    category: data
    self_service: true
    options:
      - size: small (10GB)
      - size: medium (100GB)
      - size: large (1TB)
    sla:
      provisioning: "< 15 minutes"
      backup: "Daily, 30-day retention"

# developer-survey.yaml
survey:
  frequency: quarterly
  questions:
    - id: nps
      type: scale
      text: "How likely are you to recommend the platform to a colleague?"
      scale: 0-10
    - id: time_saved
      type: choice
      text: "How much time does the platform save you per week?"
      options:
        - "Less than 1 hour"
        - "1-5 hours"
        - "5-10 hours"
        - "More than 10 hours"

4.4 Algorithm Overview

Platform Prioritization Framework:

For each proposed feature:
  1. Score FREQUENCY (How often is this needed?)
     - Daily: 3, Weekly: 2, Monthly: 1

  2. Score SEVERITY (How painful without it?)
     - Blocking: 3, Frustrating: 2, Inconvenient: 1

  3. Score EFFORT (How hard to build?)
     - Small: 3, Medium: 2, Large: 1

  4. Calculate PRIORITY = (Frequency * Severity) / Effort

  5. Rank features by PRIORITY
  6. Select top features that fit capacity

5. Implementation Guide

5.1 Development Environment Setup

No special setup—this is primarily a documentation and design project.

Tools you might use:

Markdown editor (VS Code, Obsidian)
Figma or Excalidraw for UI mocks
Google Sheets for roadmap visualization
Notion for collaborative editing

5.2 Project Structure

platform-blueprint/
├── research/
│   ├── interview-notes/
│   │   ├── interview-nina.md
│   │   ├── interview-victor.md
│   │   └── interview-maria.md
│   ├── personas.md
│   └── pain-points.md
├── strategy/
│   ├── vision.md
│   ├── principles.md
│   └── roadmap.json
├── design/
│   ├── portal-mockups/
│   │   ├── homepage.png
│   │   ├── service-catalog.png
│   │   └── create-service.png
│   └── user-flows.md
├── metrics/
│   ├── success-criteria.md
│   └── measurement-plan.md
└── README.md  # Executive summary

5.3 The Core Question You’re Answering

“If you had to charge your developers money to use your platform, would they pay for it or find an alternative?”

This question forces you to think about actual value delivered, not just features built. Internal platforms succeed only when they are easier to use than the alternatives.

5.4 Concepts You Must Understand First

Stop and research these before starting:

The Thinnest Viable Platform (TVP)
- Why is a “Golden Path” better than a “Golden Cage”?
- What happens when the platform is too opinionated?
- Book Reference: “Team Topologies” Ch. 5 - Skelton & Pais
Developer Experience (DevEx)
- What are the dimensions of DevEx? (Flow, cognitive load, feedback loops)
- How do you measure it?
- Reference: DX survey research
User Research for Developers
- How do you interview developers to find pain points?
- How do you distinguish “wants” from “needs”?
- Book Reference: “Continuous Discovery Habits” by Teresa Torres

5.5 Questions to Guide Your Design

Before writing, think through these:

Mandatory vs. Optional

Should developers be forced to use the platform?
How do you handle “edge cases” that the platform doesn’t support yet?
What’s the “escape hatch” policy?

Feedback Loops

How will you know if a new feature is actually reducing cognitive load?
How quickly can you iterate based on feedback?
Who decides what to build next?

Competition

What alternatives do developers have? (Raw cloud, external tools)
Why would they choose your platform over those?
What can you do that external tools can’t?

5.6 Thinking Exercise

The “Credit Card” Test

Imagine every team is given a $50,000 annual budget. They can:

Use your internal platform (costs $0 direct, but has constraints)
Go directly to AWS/GCP and manage it themselves ($X based on usage)

Questions:

What is your platform’s unique selling point?
If your platform is “free” but takes 2 weeks to provision a DB, while AWS takes 2 minutes for $50/month, which will teams choose?
How do you lower the “Cost of Entry” for your platform?

Write down:

3 things your platform can do that raw cloud can’t
3 things raw cloud does better today
1 thing you must fix to win the comparison

5.7 Hints in Layers

Hint 1: Start with the Toil Interview 5 developers. Ask: “What took the most time last week that wasn’t writing code?”

Common answers:

Setting up environments
Waiting for approvals
Debugging infrastructure
Finding documentation

Hint 2: Define the Product Don’t just build scripts. Define a “Service”:

What: Staging Environment as a Service
Inputs: Service name, size
Outputs: Working environment URL
SLA: Provisioned in < 10 minutes

Hint 3: Map the Onboarding Write down every step a new developer takes from “Repo created” to “Code in production”:

Clone repo
Set up local environment
Configure CI
Create namespace
Set up database
Deploy to staging
Deploy to production

Your platform should automate at least 50% of these steps.

Hint 4: Use Backstage as a North Star Look at backstage.io. Specifically:

Software Templates
Service Catalog
TechDocs integration

You don’t have to use Backstage, but it shows what “good” looks like.

5.8 The Interview Questions They’ll Ask

Prepare to answer these:

“What is a ‘Thinnest Viable Platform’ and why is it important?”
- Enough abstraction to help, not so much that it hinders. Reduces cognitive load without adding complexity.
“How do you measure the success of a Platform Team?”
- Adoption rate (% using platform), NPS, time-to-production, reduction in tickets
“How do you handle ‘Feature Requests’ from app teams without becoming a bottleneck?”
- Prioritization framework, self-service where possible, extensibility for edge cases
“Why should a Platform Team have a Product Manager?”
- To do user research, prioritize roadmap, measure impact—same as external products
“What is the ‘Golden Path’ and how does it differ from a standard?”
- Golden Path = recommended default. Standard = mandatory requirement. Golden Path is easier; Standard is enforced.

5.9 Books That Will Help

Topic	Book	Chapter
Platform Teams	“Team Topologies” by Skelton & Pais	Ch. 5: The Four Team Topologies
DevOps Metrics	“Accelerate” by Forsgren et al.	Ch. 5: Architecture
Product Discovery	“Continuous Discovery Habits” by Torres	All
Developer Experience	“A Philosophy of Software Design”	Ch. 4

5.10 Implementation Phases

Phase 1: Discovery (5-7 hours)

Interview 5+ developers from different teams
Document pain points and frequency
Create 3 personas with distinct needs

Phase 2: Strategy (4-5 hours)

Write vision and principles
Prioritize pain points using framework
Define TVP (first 3 features)

Phase 3: Roadmap (4-5 hours)

Map features to quarters
Estimate effort (T-shirt sizes)
Define dependencies between features

Phase 4: Design (6-8 hours)

Sketch portal homepage
Design key user flows (create service, find docs)
Create mockups for TVP features

Phase 5: Metrics (3-4 hours)

Define success criteria
Create measurement plan
Identify data sources

5.11 Key Implementation Decisions

Decision	Option A	Option B	Recommendation
Build vs Buy	Build custom portal	Use Backstage	Backstage for MVP
Adoption	Mandate usage	Incentivize adoption	Incentivize
Feature scope	Broad but shallow	Narrow but deep	Narrow and deep first
Roadmap visibility	Internal only	Shared with devs	Shared (transparency)

6. Testing Strategy

User Testing

Show mockups to 5 developers
Measure task completion time
Gather qualitative feedback

Feature Validation

Before building, share spec with potential users
Get commitment: “Would you use this?”
Iterate based on feedback

Metrics Validation

Ensure metrics can be collected with current tooling
Set up dashboards before launching features

7. Common Pitfalls & Debugging

Problem	Symptom	Root Cause	Fix
Low adoption	< 30% of teams using	Not solving real pain	More user research
Feature creep	Roadmap keeps growing	No prioritization framework	Apply value/effort scoring
Over-abstraction	Developers bypass platform	Platform harder than raw cloud	Simplify, add escape hatches
No metrics	Can’t prove value	Didn’t plan measurement	Add instrumentation to features

8. Extensions & Challenges

Extension 1: Developer Survey

Create and deploy a quarterly DevEx survey. Track NPS over time.

Extension 2: Backstage Implementation

Actually set up Backstage with 5 services cataloged.

Extension 3: Golden Path Workshop

Run a workshop with developers to define the “golden path” for a new service.

Extension 4: Cost Model

Calculate the cost of the platform vs. value delivered.

9. Real-World Connections

Case Studies:

Spotify Backstage: Open-sourced their internal portal
Netflix Platform: Paved paths with freedom to deviate
Mercari Microservices Platform: Reduced setup time from weeks to hours

Common Patterns:

Self-service portals with templated provisioning
Curated library of “blessed” components
Metrics dashboards showing platform value

10. Resources

Platform Engineering

Backstage.io - Open source developer portal
Internal Developer Platform
Platform Engineering Community

Developer Experience

DX Survey - DevEx measurement framework
DORA Metrics - DevOps Research and Assessment

P02: Team Service Interface - Define team as service
P09: ORR System - Production quality gates

11. Self-Assessment Checklist

Before considering this project complete, verify:

I’ve interviewed at least 5 developers
I have 3 distinct personas with documented pain points
Vision statement is one paragraph, memorable
Roadmap has 3+ quarters with prioritized features
Each feature has effort and value estimates
Portal mockup shows key user flows
Success metrics are defined with targets
I can answer “Why would devs pay for this?” convincingly

12. Submission / Completion Criteria

This project is complete when you have:

Research folder with interview notes and personas
Vision document with principles and anti-patterns
Roadmap JSON/YAML with Q1-Q4 features
Portal mockups (3+ screens)
Metrics plan with leading and lagging indicators
README with executive summary
Presentation (optional): 10 slides pitching to leadership

Previous Project: P04: Escalation Logic Tree Next Project: P06: Cognitive Load Survey & Heatmap