Platform as a Product: Minimum Viable Principles
“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.
Core Operating Principles
Treat Users as Customers
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.
Default to Self-Service
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.
Make the Right Thing Easy
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.
Make the Wrong Thing Hard
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.
Measure What Matters
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.
Own the Full Lifecycle
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.
Build Small, Iterate Fast
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.
Curate, Don’t Create
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.
Anti-Patterns to Avoid
Mandate Without Value
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.
Build Features Nobody Asked For
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.
Ticket-Based Model
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.
Over-Abstraction
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.
Supporting Every Edge Case
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.
Documentation as Afterthought
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.
Ignoring the Last Mile
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.
No Feedback Mechanism
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.
Proprietary Replacements
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.
Treating Platform as IT Service
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.
Getting Started
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?
Further Reading
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