Platform as a Product: How to Run Your Infra Team Like a Product Team

The Ticket Queue Anti-Pattern

Most platform teams operate as ticket queues. Developer needs a database? Open a ticket. Need a new environment? Ticket. VPN access? You guessed it.

This doesn’t scale. The platform team becomes a bottleneck. Developers wait days for basic infrastructure. Everyone’s frustrated.

The fix: treat your platform as a product. Your developers are your users. Build for them like you’d build for customers.

The Product Mindset

1. Define Your Users

## Platform Users

### Persona: Backend Developer (60% of users)
- Needs: databases, message queues, CI/CD, staging environments
- Pain points: slow provisioning, unclear docs, debugging deployments
- Skill level: knows their language, basic Docker, minimal K8s

### Persona: Data Engineer (25% of users)
- Needs: compute clusters, data pipelines, GPU instances
- Pain points: cost visibility, job scheduling, data access
- Skill level: Python/Spark, some Terraform, no K8s

### Persona: Frontend Developer (15% of users)
- Needs: CDN, preview environments, environment variables
- Pain points: "it works locally", deployment complexity
- Skill level: JavaScript/TypeScript, Docker basics

2. Build a Roadmap

Platform teams need roadmaps just like product teams:

Q1 2026: Self-service databases (PostgreSQL, Redis)
Q2 2026: Preview environments for every PR
Q3 2026: AI-assisted troubleshooting in Backstage
Q4 2026: Multi-cloud deployment (AWS + GCP)

Prioritize by impact × number of affected users, not by what’s technically interesting.

3. Measure Satisfaction

# Developer Experience Survey (quarterly)
DORA_METRICS = {
    'deployment_frequency': 'How often can you deploy?',
    'lead_time': 'Time from commit to production?',
    'mttr': 'Mean time to recover from failures?',
    'change_failure_rate': 'What % of deploys cause issues?',
}

PLATFORM_METRICS = {
    'time_to_first_deploy': 'Time from idea to first deployment?',
    'self_service_ratio': '% of infra requests without tickets?',
    'developer_satisfaction': 'NPS for platform team (1-10)?',
    'onboarding_time': 'Days for new dev to deploy first change?',
}

4. Provide Golden Paths, Not Golden Cages

Golden paths are opinionated defaults that cover 80% of use cases. They’re not mandates — teams can diverge, but the golden path should be so good they rarely want to.

I build golden paths with:

• Backstage templates — scaffold new services in minutes
• Terraform modules — standardized infrastructure (see Terraform Pilot)
• Ansible roles — consistent configuration (see Ansible Pilot)
• Helm charts — Kubernetes deployment patterns (see Kubernetes Recipes)

The key: golden paths must be maintained. An outdated template is worse than no template.

Team Structure

The best platform teams I’ve worked with follow this structure:

Platform Product Manager (1)
  ↓
Platform Engineers (3-5)
  ├── Core Infrastructure (K8s, networking, security)
  ├── Developer Experience (CI/CD, templates, docs)
  └── Data Platform (pipelines, compute, storage)

Developer Advocates / Enablers (1-2)
  └── Training, onboarding, feedback collection

The product manager is often the missing role. Without one, the team builds what’s technically fun instead of what developers need.

Communication

Internal Marketing

Yes, marketing. If developers don’t know your platform capabilities exist, they don’t exist.

• Weekly changelog — what shipped this week
• Monthly demo — live walkthrough of new capabilities
• Slack/Teams channel — #platform-updates for announcements
• Office hours — weekly drop-in for questions

Feedback Loops

Developer feedback → Platform backlog → Sprint planning → Build → Ship → Measure → Repeat

The loop must be visible. When a developer requests a feature, they should see it move through the backlog. When it ships, notify them directly.

Anti-Patterns to Avoid

1. Building everything in-house — Use managed services when they’re good enough
2. Platform team as gatekeepers — Self-service or bust
3. No documentation — If it’s not documented, it doesn’t exist
4. Ignoring developer feedback — You’ll lose trust fast
5. Over-engineering for future scale — Build for today’s 50 devs, not imaginary 500

The Bottom Line

Platform engineering is a product discipline, not an infrastructure discipline. The technology matters, but the user experience matters more. If your developers are filing tickets instead of shipping features, your platform has a product problem, not a technology problem.

For the technology foundations — Kubernetes, Ansible, Terraform — I maintain deep-dive resources at Kubernetes Recipes, Ansible Pilot, and Terraform Pilot. But remember: the technology is the easy part. The hard part is building something developers actually want to use.