# Roadmapping Without Product: Platform and Infra Teams Source: https://www.techinterview.org/post/3233475350/roadmapping-without-product-platform-infra-teams/ Updated: 2026-05-06 · techinterview.org Most engineering management writing assumes a PM partner. Platform, infra, security, and developer-tools teams often do not have one — or have a PM whose role is mostly intake and not strategy. EMs of these teams have to do the roadmapping themselves, with all the cross-functional discipline that requires. This guide is for that EM. ## The fundamental difference Product teams ship features for end-users; platform teams ship capabilities for other engineers. The "user research" is internal interviews; the "metrics" are developer velocity, reliability, and cost. The "PM" role is the EM's job (or shared with a TL). ## Identify your stakeholders - Other engineering teams who consume your platform - Their EMs and senior ICs - The leadership chain that funds you - Compliance, security, finance — depending on the platform - Sometimes external — vendors, customers using your APIs Write the list explicitly. You will refer to it when prioritizing. ## Discovery: what do they need? - Quarterly interviews with each stakeholder team's EM and senior ICs - Specific questions: what is slowing you down? What capability is missing? What would you build if we could not? - Quantify when possible — "compile takes 12 minutes; we lose 2 hours/day per engineer" - Watch for patterns — three independent teams asking for the same thing is a strong signal ## Themes from the inputs Group raw requests into themes: - Reliability: reduce SEV count, improve MTTR - Velocity: faster CI, better local-dev, less yak shaving - Capability: new platform feature requested by multiple teams - Cost: reduce infra spend with same throughput - Compliance: security or regulatory commitments 3–5 themes per year is the right level of abstraction. Don't roadmap features; roadmap themes with named outcomes. ## Prioritization without a PM The PM-equivalent rubric for platform work: - Number of teams impacted - Severity (is it a velocity tax, a reliability risk, a compliance gap?) - Cost to ship (engineer-quarters) - Strategic fit (does it align with stated company direction?) - Reversibility (can we ship a partial version and iterate?) Score, rank, and present. The act of writing it down lets stakeholders push back with specifics. ## OKRs for platform teams Platform OKRs are easier than product OKRs in one way (no growth metric required) and harder in another (the value is felt downstream). Examples that work: - "Reduce p99 CI build time from 18 min to 8 min" - "Onboard 3 new teams to the new auth library" - "Reduce SEV-2 incidents in the data pipeline by 50%" - "Cut infra spend on service X by 30% with no latency regression" - "Ship the eval-as-a-service platform; 5 teams using it by EOQ" ## The customer review Once a quarter, present the roadmap to the consuming teams' leads: - Themes for the quarter - What you are committing to - What you are deprioritizing and why - What you need from them (review time, beta participation, feedback) This is the platform-team equivalent of a product launch review. Do it whether or not anyone asks for it. ## Operational discipline Platform teams own services that everything else depends on. The roadmap must include: - On-call rotation and incident playbook - Maintenance budget — % of time for upgrade, patching, deprecation - Documentation budget — your platform is unusable without docs - Onboarding budget — every new consuming team requires support Skipping these makes the platform fragile. Bake them in at planning time. ## Communicating across the gap - Office hours: weekly drop-in for consuming teams - Slack channel: real-time questions, with rotating coverage - Quarterly newsletter: what shipped, what is coming, what is deprecated - Release notes for platform changes — even small ones ## The political game Platform teams are political because they say no a lot. Strategies that work: - Build credibility with one or two consuming teams who advocate for you - Quantify your impact in their language ("we saved your team 8 person-weeks last quarter") - Frame your asks in terms of company outcomes, not platform aesthetics - Be visible at planning sessions across the org - Avoid the "platform team that says no to everything" reputation by saying yes selectively and well ## What separates senior platform EMs from staff/director Senior EMs run their team's roadmap effectively. Staff/director-level platform EMs work the cross-team layer well — they shape consumer expectations, negotiate roadmap sequence with peer EMs, and influence company-wide architectural direction without owning a product. ## Frequently Asked Questions ### Should I push to get a PM assigned? If your platform is large enough (say, 15+ engineers and 5+ consuming teams), yes. Below that, the EM-and-TL pair usually suffices. ### How do I justify investment without revenue? Tie to the consuming teams' goals. "If reliability does not improve, the X launch slips a quarter; that is the cost of not investing." ### What metrics actually matter for platform teams? Time-to-build, deployment frequency, MTTR, incident count, infra cost per unit work, satisfaction of consuming teams (annual survey). Lines of code never matters.