Platform as a Product & Golden Paths

Here is the single idea the whole job — and the whole exam — turns on: a platform is a product, and your developers are its customers. Not a mandate you push down, not a project you finish and hand off, but a living product people have to actually want to use. This lesson goes deep on that mindset: paved golden paths that are optional yet so good people choose them, the thinnest viable platform you start with, how to discover what developers really need, and how to measure whether they love it — because if they don’t, you built the wrong thing.

A platform is a product, not a mandate

☺ Like you’re 10: A product is something people choose because it helps them. A mandate is something people are told to use — and quietly resent. Build the first kind.

Most internal platforms die the same death: a team spends a year building a grand tool, mandates it in a policy doc, and six months later half the org has quietly built shadow scripts to route around it. It “launched,” but nobody loves it and adoption is a rounding error. The problem was never the technology; it was the mindset — they ran a platform like a one-off project instead of a product.

The fix reframes everything: your platform is a product, and your developers — 🦆 Dot and the other ducklings — are customers you win over and over. Products get continuous funding, a roadmap, and real support, and they’re never “done.” Crucially, customers can leave — Dot can always drop back to raw kubectl or lobby for an exception, and that looming exit is what keeps a product team honest.

What a product mindset actually changes

It changes concrete decisions. You stop asking “what should we build?” in a vacuum and start asking “what is Dot’s biggest, most repeated pain, and would this remove it?” You measure outcomes (“time-to-first-deploy fell from three days to an hour”) instead of output (“we shipped 12 CRDs!”), and you budget for docs and support, not just features. The centre of gravity moves from the platform team’s convenience to the customer’s success.

The failure mode: the platform nobody asked for

The opposite of a product is 👺 Gizmo’s favourite trap — the platform nobody asked for. It looks impressive (a portal with two hundred buttons, an abstraction over an abstraction), but it fails because it solves a problem the team imagined, not one Dot has. We give that its own lesson in Anti-Patterns & Pitfalls; the antidote starts here — only build what discovery proves is real, and keep everything optional so developers get a vote.

Golden paths: the paved road

☺ Like you’re 10: A golden path is a smooth, well-lit road with guardrails to where most people need to go. You can hike off into the woods — but the road is so nice you rarely want to.

The product you’re shipping has a signature feature with a name: the golden path (Spotify popularised the term; Netflix calls its version the “paved road”). It’s the opinionated, supported, secure-by-default way to do a common thing — spin up a service, get a database, ship to prod — bundling the good decisions so a developer doesn’t make forty of them correctly by hand. Walk it and you get a repo, a pipeline, sensible manifests, a database, dashboards, and guardrails: all wired up, all blessed, all boringly reliable.

Opinionated, supported, secure-by-default

Those three words are the whole spec. Opinionated means the platform makes the boring choices for you — base image, folder layout, deploy strategy — so Dot doesn’t drown in decisions (that’s cognitive load, the thing platforms exist to reduce). Supported means a real team stands behind it, so when the path breaks someone answers. Secure-by-default means the safe thing is the easy thing — RBAC, network policy, mTLS, image signing come pre-wired, so walking the path yields a compliant setup, not a 40-page policy PDF. Same outcome, hand-rolled versus paved:

# The OLD way — Dot stands up the “payments” service by hand
mkdir payments && cd payments
#  1. copy-paste a Dockerfile from another repo (hope it’s current)
#  2. hand-write manifests from scratch:
#       deployment.yaml service.yaml ingress.yaml hpa.yaml servicemonitor.yaml
#  3. file a ticket for a namespace + RBAC ............ wait ~1 day
#  4. file a ticket for a Postgres database ........... wait ~2 days
#  5. copy a CI pipeline from a teammate, paste secrets in by hand
#  6. beg the platform team on Slack for cluster access to test
#  7. review flags a missing NetworkPolicy + Pod Security Standards you’d never heard of
#  8. redo steps 2 and 5 after the review comments
# result: ~3 days, 4 tickets, 0 features shipped — and EVERY team redoes it

# The GOLDEN PATH — same outcome, one command, ~2 minutes
# (illustrative: `platform` here is a made-up in-house CLI — yours might be a
#  Backstage template, a portal button, or a repo-scaffolding script)
$ platform new service --template golden-service \
      --name payments --language go --db postgres

✔ repo created (payments) with Dockerfile + health checks
✔ GitOps manifests generated (Deployment, Service, HPA, NetworkPolicy)
✔ CI/CD pipeline wired: build → scan → sign → deploy
✔ Postgres provisioned via a Crossplane composite resource (dev + prod)
✔ dashboards + alerts registered, on-call route set
✔ secure-by-default: RBAC, Pod Security admission, and mTLS already on

→ open a PR to ship. First deploy to prod: before lunch.

The second block isn’t magic — it’s the boring, correct version of the first, packaged once and handed to everyone. How that scaffolder and the Crossplane API behind the database work is the story of Self-Service & Portals and Platform APIs & CRDs; here, the point is that it exists and Dot chose it.

The 80% common case — and escape hatches for the 20%

A golden path is deliberately for the common 80%, not a cage. The 20% who genuinely need something bespoke — a stateful workload, a GPU node pool, a compliance carve-out — must be able to step off the road without punishment, ideally with the guardrails still on. That’s the difference between a paved road and a walled garden: give them documented escape hatches to override a default or drop to a lower-level API. And keep the path optional — mandate it and you can’t tell a genuinely great path from a merely tolerated one, so it stops improving. “Optional but excellent” forces you to make staying the obvious choice.

The thinnest viable platform

☺ Like you’re 10: Don’t build a giant castle on day one. Build one small, genuinely useful room, let people move in, and add rooms as they ask for them.

So where do you start? Not by boiling the ocean. The answer, from the Team Topologies playbook, is the Thinnest Viable Platform (TVP): the smallest set of tools, APIs, docs, and support that meaningfully lowers cognitive load right now. A TVP can be embarrassingly small — even a single well-curated wiki page documenting the one blessed way to deploy. If it removes real pain today, it counts; you grow it only when discovery proves the next slice is worth building.

Start with the single biggest pain

The TVP’s first slice should attack the one toil that hurts the most people the most often — usually the same suspect: getting a new service from nothing to a running production deploy takes days and a fistful of tickets. Solve exactly that, end to end, and make it delightful. Resist the urge to also do secrets, cost dashboards, and multi-region in v1 — one pain killed completely beats ten addressed halfway, because a path that’s 90% paved and then dumps you in mud is a path nobody trusts.

Don’t boil the ocean — and don’t build a spaceship

Two symmetric failures bracket the TVP. Boiling the ocean is a multi-quarter mega-build that solves every problem before shipping anything, so feedback arrives far too late and the first release is both enormous and wrong. Building a spaceship no one boards is a gorgeous, over-engineered platform bristling with abstractions that dazzle in a demo but match no developer’s actual job. The TVP dodges both by being small and relentlessly validated — ship the thinnest thing that removes real pain, then let behaviour, not your architecture diagram, decide what comes next.

Product discovery: finding the real toil

☺ Like you’re 10: Before you build, go ask people what actually annoys them — and watch them work. Don’t guess; find out.

Here’s where 🐿️ Nutty earns her keep. Discovery is the product craft of figuring out what to build before you build it, and for platforms it’s the highest-leverage habit — your customers sit right down the hall. No focus groups needed; just talk to developers and watch them struggle. The goal is to find the biggest, most repeated toil — the manual, repetitive, low-value work that eats Dot’s day — and aim the platform squarely at it.

Interview developers; follow the toil

Good discovery is mostly listening. Ask five or six developers to walk you through the last time they shipped a service, got a database, or debugged a failed deploy — not “what features do you want?”, which people answer with solutions rather than problems. Watch where they sighed, waited, or filed a ticket. A pattern emerges fast: the same three toils show up in every interview, and that convergence is your signal — the same muscle behind every good platform case study.

Turn findings into a roadmap

Discovery without prioritisation is just a sad list. Rank the toils by reach (how many teams) times pain (how badly) against effort, pick the top one or two, and lay them out on a simple now / next / later roadmap where each item pairs a problem with a bet and a metric. Keep it public — developers who see their pain on your roadmap feel heard, and feeling heard is half of adoption.

# platform-roadmap.yaml — run the platform like a product
now:                       # this quarter — the biggest measured toil
  - problem: "New service takes ~3 days to reach prod"
    bet:     "Golden-path scaffolder + Backstage template"
    metric:  "time-to-first-deploy: 3 days → < 1 hour"
next:                      # validated pain, not yet started
  - problem: "Every team hand-rolls a database + secrets"
    bet:     "Self-service Postgres via a Crossplane composite resource"
    metric:  "database tickets / month: ~40 → 0"
later:                     # on the radar, still in discovery
  - problem: "No standard way to preview a pull request"
    bet:     "Ephemeral preview environments per PR"
    metric:  "adoption: 0 → 60% of teams"
principles:
  - "Optional but excellent — we earn adoption, never mandate it."
  - "Ship the thinnest slice that removes real pain, then iterate."

Internal marketing: you can’t mandate love

Building the golden path is only half the job; since you refuse to mandate it, you have to market it internally. That means great docs and a five-minute getting-started, a launch demo at the all-hands, office hours and a responsive #platform-help channel, and champions on other teams who vouch for you. Celebrate wins loudly (“payments shipped in 40 minutes”) and remove the smallest papercuts fast. Adoption is a trust curve you climb one delighted developer at a time. You can’t mandate love — you earn it.

Measuring a platform developers love

☺ Like you’re 10: How do you know your lemonade stand is winning? Count the repeat customers and ask if they’re happy — not how many lemons you squeezed.

If the platform is a product, you owe it real metrics — and “features shipped” is not one of them. That’s a vanity metric: it measures your activity, not Dot’s success. The measures that matter track whether developers adopt the platform, get faster, and stay. The CNCF’s Platform Engineering Maturity Model makes “Measurement” a core dimension for exactly this reason: a team that can’t say whether it’s helping is flying blind.

The metrics that matter

Watch a small, honest basket of signals. Adoption % — the fraction of teams on the golden path — is the headline; a platform nobody uses is worth nothing. Time-to-first-deploy (empty repo → running in prod) is the crispest proxy for cognitive load removed, and ticket / toil volume should fall as self-service rises. DevEx surveys capture how developers feel across the three dimensions the research highlights — feedback loops, cognitive load, and flow state. And the DORA four keys — deployment frequency, lead time for changes, change-failure rate, failed-deployment recovery time — measure whether delivery genuinely improved (deep-dive in Observability & Operations).

Leading vs lagging indicators

Leading indicators move early and predict where you’re heading — adoption trend, onboarding time, survey sentiment. Lagging indicators confirm results after the fact — the DORA outcomes, incident rate, developer retention. You steer by the leading ones (they buy time to react) and prove impact with the lagging ones (they’re what leadership funds). Stay honest, too: beware Goodhart’s law — once a metric becomes a target, people game the number — so triangulate a hard measure with a soft one, and treat a flat adoption line as the product telling you something true.

Running the platform team as a product team

☺ Like you’re 10: The team behind the platform should act like the team behind your favourite app — someone steering, a plan, real help when things break, and promises they keep.

All of this only holds together if the team is organised like a product team, not a ticket queue. In Team Topologies terms this is a genuine platform team whose customers are the internal stream-aligned teams, and whose job is to reduce their cognitive load through a well-run product — the throughline into Best Practices & Operating Model later in the course.

A PM, a roadmap, and real support

Product teams have a product manager accountable for discovery, prioritisation, and saying “no” to the shiny thing so the important thing ships. They keep a visible roadmap driven by developer pain, not architectural fashion. And they treat support as first-class — docs, onboarding, office hours, a staffed help channel, and a loop that turns every support question into a docs fix or a roadmap item. Treating support as an interruption is the surest sign a team has slipped back into project mode.

SLAs for the platform itself

Here’s the mindset-flipping part: if developers are your customers, the platform owes them promises, just as a SaaS vendor owes you an uptime guarantee. So it publishes its own SLOs — provisioning latency, portal availability, pipeline success rate — plus support commitments, and holds itself to them. Nothing says “we take you seriously as customers” like being on the hook for your own reliability.

# platform-slo.yaml — the platform makes promises to its customers too
# (a plain team document, not a Kubernetes resource — no apiVersion/kind here)
service: internal-developer-platform
objectives:
  - name: golden-path-provisioning
    sli: "P95 time to provision a new service"
    target: "< 5m over 30d"
  - name: portal-availability
    sli: "successful portal requests / total requests"
    target: ">= 99.9% over 30d"
  - name: pipeline-success
    sli: "green CI runs / total runs (excluding user error)"
    target: ">= 99% over 7d"
support:
  hours:   "Mon–Fri 9–6; follow-the-sun on-call for Sev1"
  channel: "#platform-help — first response < 30m"

That’s the keystone. Hold “platform as a product, developers as customers, golden paths that are optional but excellent” in your head, and the rest of the course is execution: next comes the reference architecture that gives the product its shape, and later how self-service portals turn a golden path into something Dot walks entirely on her own. (New here — golden path, TVP, toil? They’re all in the glossary.)