“Platform teams are to application teams what those teams are to their users: they provide capabilities, not tickets.”
The following are hard-won lessons I learned as part of the team building Walmart’s first global software delivery platform. The goal from the start was maximum impact, minimal OpEx, and a platform that optimized for continuous delivery as the default workflow. When I left, the Software Delivery Enablement (SDE forever!) organization was 0.4% the size of our internal customer base of 20k developers. We provided 24x7 support. We mostly slept very well.
A platform is a curated set of tools, services, and workflows that make the right thing easy. Platform-as-product means treating your internal developers as customers; understanding their needs, measuring their satisfaction, and delivering capabilities they choose to adopt because they provide clear value. Too many platform team implementations devolve into tool teams or “Platform as a Service Ticket” teams. The following is tested in the real world at scale. It’s optimized for maximum impact with the smallest possible platform teams.
Know your users: Regular user research, interviews, shadowing sessions
Measure satisfaction: NPS, CSAT, surveys, or similar customer metrics (not just usage)
Prioritize by value: Product roadmap based on customer impact, not loudest stakeholder
Transparent communication: Share roadmap, decisions, and changes proactively
Why: If users don’t choose your platform, they’ll route around it. Customer focus drives adoption through value, not mandate.
Self-service APIs and tools: Users provision/configure without platform team intervention
Clear documentation: Users can onboard and troubleshoot independently. A question that’s not covered by the documentation is a defect in the docs.
Escape hatches: Users can extend the platform when the platform doesn’t fit
Observable and debuggable: Users can understand what the platform is doing
Why: Tickets and handoffs don’t scale. Self-service unblocks users and frees platform teams for higher-value work.
Golden paths: Opinionated, well-paved defaults for common cases (80% of needs)
Progressive complexity: Simple to start, powerful when needed
Guardrails, not gates: Enable safe experimentation without approval workflows
Automate toil: Eliminate repetitive tasks users currently do manually
Why: Adoption comes from reducing friction, not adding it. The right path should be the easiest path.
Security by default: Authentication, authorization, encryption built into the platform, not optional
Compliance automated: Audit logging, data retention, access, and regulation controls enforced automatically
Dangerous operations protected: Destructive actions require confirmation, elevated permissions, or are blocked
Can’t skip critical steps: Security scans, approval gates, compliance checks run automatically
Why: Platforms that make it easy to create security vulnerabilities or compliance violations create organizational risk. The wrong thing should be harder than the right thing.
Track adoption metrics: Active users, service utilization, time-to-onboard
Monitor user outcomes: Deploy frequency, lead time, failure rate for users of platform
Regular feedback loops: Surveys, retrospectives, office hours
Leading indicators: Early signals of dissatisfaction or abandonment
Why: You can’t improve what you don’t measure. Customer metrics surface problems before they become crises.
End-to-end ownership: Platform team owns development, deployment, operation, and support of the platform
Clear SLAs: Documented reliability commitments
Proactive support: Monitor for user problems, don’t wait for tickets
Deprecation strategy: Plan for sunsetting capabilities with migration paths
Why: Partial ownership creates accountability gaps. Full lifecycle ownership ensures quality and responsiveness.
Ship MVPs: Deliver working capability quickly, iterate based on feedback
Validate before building: Prototype and test with real users first
Version and evolve: Graceful upgrades without breaking existing users
Kill failed experiments: Stop investing in unused capabilities
Why: Long build cycles create misalignment between what you build and what users need. Fast iteration minimizes waste.
Prefer existing tools: Use proven open-source/COTS over custom builds
Thin integration layer: Wire together best-of-breed tools with minimal abstraction, but avoid excessive tool hopping for developers
Standards over invention: Adopt industry standards unless clear reason to diverge
Buy commodity, build differentiation: Only custom-build what’s unique to your organization
Why: Every custom component is technical debt. Curation scales better than creation.
Don’t: “All teams must use Platform X by Q3”
Do: Platform provides clear value that users choose
Why: Mandates create hostility and workarounds. Valuable platforms don’t need mandates.
Don’t: “We’ll build X because it’s interesting”
Do: “Users struggle with Y, we’ll solve it”
Why: Building without validation wastes time on unused capabilities.
Don’t: “Submit a ticket and we’ll provision your database”
Do: “Click here to provision your database in 2 minutes”
Why: Ticket queues bottleneck delivery and frustrate users. Self-service enables flow.
Don’t: Custom DSL/UI that obscures underlying tools
Do: Sensible defaults with access to underlying primitives that don’t introduce organizational risk
Why: Abstraction that hides too much becomes a cage. Users need escape hatches.
Don’t: “Our platform must handle all possible workflows”
Do: “Our platform handles common cases excellently”
Why: Edge case support dilutes focus. Optimize for the common path, allow escape hatches for the rest.
Don’t: Minimal docs, expect users to figure it out
Do: Clear guides, examples, troubleshooting before launch
Why: Poor documentation kills adoption. If users can’t learn it, they won’t use it.
Don’t: Platform stops at the API boundary
Do: Platform includes adoption support, troubleshooting, and ongoing improvement
Why: Value is realized at adoption, not at deployment. The last mile determines success.
Don’t: Platform team decides what’s needed
Do: Regular user research, office hours, embedded support
Why: Building without feedback creates misalignment. Users know their problems better than you do.
Don’t: “We’ll build our own logging/monitoring/CI system”
Do: Use industry-standard tools with a thin customization layer
Why: Proprietary tools trap users and create vendor lock-in to an internal team. Standard tools enable mobility.
Don’t: Change advisory boards, lengthy approvals, stability over speed
Do: Rapid iteration, customer feedback, measured risk-taking
Why: IT service models optimize for control, not flow. Platforms need product velocity.
If you’re starting a platform team:
Identify your first customer segment (don’t boil the ocean)
Interview 5-10 users to understand their biggest pain points
Build the smallest thing that solves one real problem
Measure adoption and satisfaction
Iterate based on feedback
If you’re evaluating an existing platform:
Measure: What’s your user satisfaction score?
Observe: Are users choosing your platform or being forced?
Ask: When was the last time you interviewed a user?
Check: Can a new user be onboarded without talking to you?
Validate: Are you building what users asked for or what you think they need?
Platform as a Product - Full whitepaper by Bryan Finster
Team Topologies by Matthew Skelton and Manuel Pais - Platform Team patterns and interaction modes
Accelerate by Forsgren, Humble, Kim - Evidence for platform effectiveness on delivery performance
Spotify’s Golden Paths - Making the right thing the easiest thing
Thoughtworks Technology Radar - Platform Engineering trends and practices
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.