Platform as Product
The pattern: an internal platform has users — developers — and users have UX expectations. Time-to-first-deploy, golden paths, self-service, clear failure modes, predictable upgrades. Treat the platform as a product: personas, roadmap, eval (NPS-style or “time-to-deploy” metrics), support channels — not just a stack of YAML someone left running.
The trade-off: engineering effort vs. developer productivity. A platform-as-product investment is real (frontend dev, UX research, on-call for the platform itself). The return compounds: every developer’s friction multiplies across the org. Smell test — if engineers cannot deploy a new service in under 10 minutes using your platform, the platform is broken. Fix it like a customer-facing bug, not a backlog ticket.
Deepens in Year 2 Phase 12: Platform Engineering and Year 5 Phase 29 — the Studio portal launch is the synthesis. basecamp is the substrate; platform-ctl is the front door.
Related patterns
- gitops — the deploy contract the platform exposes to developers.
- progressive-delivery — golden paths include safe rollouts, not just
kubectl apply. - multi-tenancy — every product team is a tenant; isolation is part of the UX.
- sli-slo-error-budget — the platform’s reliability is itself a product contract.
- runbook-as-code — support channels backed by executable docs, not tribal knowledge.
- least-privilege — secure defaults are part of the golden path, not a separate review.
- Phase 12: Platform Engineering,
platform-ctl,basecamp— where the platform stops being a stack and starts being a product.