Introduction
Platform engineers are learning that they must operate more like product managers to build scalable platforms developers love. But while a primary tenet of this philosophy requires platform engineers to treat developers like customers, exactly how that’s done has been almost completely absent from current discourse.
This guide level-sets platform engineering fundamentals, posits what’s been missing from the platform-as-a-product mindset, and shares direct advice on how to close the gap for scalable systems that give developers what they need—not just what they want.
BONUS: Be sure to check out the free interview guide we’ve attached to get you started with a more structured approach to user research and analysis.
What is Platform Engineering?
Platform engineering is the discipline of designing, building, and maintaining the platform that serves as the foundation for developers to efficiently build, deploy, monitor, and scale software.
The goal of platform engineering is to centralize infrastructure, tools, and workflows, ensuring that developers can focus on writing code and building features instead of managing complex infrastructure. Platform engineers abstract away the underlying complexity of cloud environments, CI/CD pipelines, and operational tools to create a “golden path”—a seamless and repeatable development process that aligns with organizational standards.
Key responsibilities of a platform engineer include:
Centralize resources: Create a single access point for tools, documentation, and environments with Internal Developer Portals like Cortex to simplify the development process.
Standardize workflows: Establish consistent pipelines, environments, and deployment patterns.
Abstract complexity: Simplify the interaction with services and infrastructure through automation and self-service.
Improve developer experience: Reducing friction and inefficiencies in development workflows, so developers can focus on their core tasks.
Automate infrastructure management: Create context-aware workflows to automate tasks like environment setup, testing, and deployments.
Gather feedback: Treat the platform like a product, gathering feedback through surveys, analytics, and developer discussions to continuously improve and adapt to changing needs.
Note that many of these tenets were not “conceived” as part of platform engineering practice, but rather born from DevOps. This illustrates a fundamental principle of platform engineering, that it is not mutually exclusive to DevOps, but can instead be thought of as an extension of DevOps practices.
Components of an Internal
Developer Platform
An Internal Developer Platform comprises various tools and services that together enable developers to deliver software quickly and reliably. The components of an Internal Developer Platform are designed to support the entire software development lifecycle, from coding to deployment to monitoring.
Here’s an overview of the key components:
Source Code Management (SCM)
A centralized system for storing and managing code (e.g., GitHub, GitLab, Bitbucket) enables version control, collaboration, and code review.
Continuous Integration/Continuous Deployment
(CI/CD) Pipelines
Automated pipelines that build, test, and deploy code (e.g., Jenkins, GitHub Actions, CircleCI) ensure code is automatically tested and deployed to production environments.
Infrastructure as Code (IaC)
Tools that enable infrastructure provisioning and orchestration through code (e.g., Terraform, Chef) so developers can self-serve environments and infrastructure.
Container Orchestration
Management of containers and microservices through platforms like Kubernetes to ensure consistent deployment environments across the organization.
Monitoring & Observability
Tools that provide visibility into system performance and health (e.g., Prometheus, Grafana, Datadog) to help developers and platform engineers identify issues, performance bottlenecks, and system health.
Security & Compliance
Integration of security checks into the CI/CD pipelines (e.g., Snyk, Aqua Security) to ensure code adheres to security and compliance standards before reaching production.
Internal Developer Portal—”The Choreographer”
The Internal Developer Portal connects all of the above as the single entry point for developers to access information, standards, & self-service (e.g., Cortex, Backstage).
In line with the note in the above section, these tools also did not originate in the movement towards platform engineering, but have been used in whole or in part by DevOps practitioners for many years. As an example, good DevOps practice incorporates tooling like Source Control Management and CI/CD pipelines, and makes use of monitoring and observability and strong security practice.
Why a Product Mindset Matters
in Platform Engineering
Traditionally, platform engineers have focused on solving technical problems. However, as the Internal Developer Platform becomes a crucial product for developers within the company, platform engineers need to shift their mindset and approach.
Instead of merely focusing on the backend infrastructure, platform engineers should start thinking like product managers, who build tools and features based on user (developer) feedback and needs, and prioritize user experience and value delivery. Here’s how:
Take a User-Centric Approach: Developers are the users of the platform, and their needs should be at the center of platform decisions. Like product managers who focus on customer satisfaction, platform engineers should focus on the developer experience, gathering feedback, iterating, and improving the platform based on real-world usage.
Build Roadmap & Prioritization: Product managers often maintain roadmaps, prioritize features, and work toward delivering value. Similarly, platform engineers should create a roadmap that improves the platform based on the jobs-to-be-done, focusing on the highest impact improvements. The now seemingly-ancient wisdom that it doesn’t really matter what you’re improving as long as you are improving something is alive and well in platform engineering.
Gather Feedback and Iterate: Rather than large-scale, slow-moving infrastructure projects, platform engineers should adopt an agile approach—shipping incremental improvements regularly, testing them with developers, and gathering feedback.
Measure Success: Product managers measure success using KPIs like user engagement, satisfaction, and churn. Platform engineers should similarly track multiple critical platform metrics, and understand the tensions that exist between them. Developer productivity metrics, such as onboarding time, as well as traditional metrics like DORA’s deployment frequency and mean time to recovery (MTTR), become significantly easier to measure when the Internal Developer Portal abstraction is added on top of the platform.
Systems Thinking: Great platform engineers are great systems thinkers, and understand the underlying interplay between systems, and the systems in which their users do their work. They understand clearly that the overall productivity of a team or organization is primarily constrained by the underlying set of systems in which that organization is forced to work. It is this very principle that drives and motivates a great platform engineer to build systems that are frictionless and satisfying to use.
The Difference Between Product Manager, and Order Taker
While platform engineers recognize the importance of building scalable platforms, many miss a key nuance in a user-centric approach: it’s not about asking developers what to build, but rather what’s working and what’s not. Simply delivering on specific requests—like a tool or pipeline—might satisfy short-term needs but often results in a patchwork of solutions that fail to scale or anticipate future needs.
Platform Engineers should also take care to pull in parameters from adjacent teams. Talking to SREs, Infrastructure, and Security teams will ensure the solution is scalable and secure. Importantly, this distinction has nothing to do with whether you think your developers are “right” about what they request. Focusing more on pain points than solutions just ensures you're building the thinnest possible platform that serves the broadest range of use cases.
By focusing on outcomes rather than specific feature requests, platform engineers can create systems that solve current issues while preparing the organization for future growth. This thoughtful approach avoids piecemeal solutions and ensures scalability.
How Platform Engineers Can Operate Like Product Managers
Now that we understand both why adopting a product mindset matters, as well as what it really means to be user-centric, let’s dig into the additional areas platform engineers should explore:
Anticipate Developer Needs, Don’t Just Fulfill Requests
As discussed above, a key difference between order takers and product managers is the ability to anticipate needs and deliver solutions that go beyond what developers are explicitly asking for. Platform engineers operating like product managers dig deeper, identifying root problems and delivering scalable solutions that not only meet today’s needs but also prepare the platform for future growth.
For example, if a developer asks for faster builds, a platform engineer thinking like a product manager would first explore why builds are slow. Instead of simply addressing surface-level issues, platform engineers should ask deeper questions: Why is this process taking so long? What are the real bottlenecks? Is it the build system? Some approval gate? How can we automate or streamline this task to remove friction entirely?
Example: Instead of just improving one-off deployment scripts for microservices, introduce a self-service platform that standardizes the deployment process across all teams, using tools like Cortex to ensure self-service stays on the rails, and software stays aligned to standards at deployment and continuously thereafter.
By thinking ahead, platform engineers can deliver solutions that solve the underlying problems and ensure the platform remains scalable and adaptable as development needs evolve. (Note: See attached interview guide for more on surfacing the right insights for your research).
Survey Adjacent Teams: Ensure Security and Scalability
Just as product managers gather insights from multiple stakeholders, platform engineers should survey adjacent teams like security, SREs, infrastructure, and operations to ensure the platform is secure and scalable. After all, one desired outcome of implementing platform engineering practice is creating better cross-functional alignment across heterogeneous organizational functions. Engaging with these teams uncovers essential insights about organizational requirements and potential risks:
Security Input: Collaborate with security teams who need to identify and address vulnerabilities, ensuring that the platform integrates automated security checks and complies with internal policies.
Example: Integrate tools like Snyk or SonarQube into CI/CD pipelines to catch security issues early.
SREs and Infrastructure: Work closely with SREs and infrastructure teams to ensure the platform is designed for high reliability, scalability, and performance.
Example: Introduce automated monitoring and alerting tools like Prometheus and Grafana to maintain system stability and performance at scale.
Operations: Ensure that the platform aligns with operational workflows, reducing friction during incident management or large-scale deployments.
Example: Build in observability and centralized logging with tools like Elasticsearch or Splunk to streamline troubleshooting.
By gathering insights from these adjacent teams, platform engineers can build platforms that balance developer productivity with security, scalability, and operational resilience.
Prioritize Features According to Research Themes
To build a successful platform, engineers need to maintain a clear roadmap that prioritizes features based on their impact on developer productivity. Just like product managers balance short-term feature requests with long-term product vision, platform engineers must balance developer needs with the overall scalability and future readiness of the platform.
Use an Impact vs. Effort Quadrant: Evaluate each request based on its impact on developer workflows and the effort required to implement it. High-impact, low-effort changes should be prioritized to deliver quick wins, while larger initiatives should be planned for long-term platform development.
Example: If several teams request automated test environments, this might be a high-impact, low-effort win using tools like Docker Compose or Kubernetes to spin up testing environments quickly.
Balance Short-Term Needs with Long-Term Vision: Some requests, like improving pipeline speed or simplifying environment setup, are important for immediate developer satisfaction. However, platform engineers should also plan for long-term needs like scaling the platform for new services or improving security compliance.
Example: While automating deployments can be a quick win, building a GitOps-based deployment strategy using something like ArgoCD can set the platform up for long-term growth.
Build Iteratively with Feedback Loops
Platform engineers treating their platform like a product build it iteratively and use continuous feedback loops to drive improvements. Rather than building a full-fledged platform in one go, start small, deliver incremental improvements, and continuously iterate based on user feedback. These releases are treated as organizations would treat any product release, informing users of changes and new features, and handling post-release maintenance,
Define and implement an MVP (Minimum Viable Platform): Build an initial version of the platform that solves the most pressing and specific needs identified during developer interviews and feedback sessions. This could be as simple as a basic CI/CD pipeline, or an MVP of a developer self-service portal.
Example: Start by automating the most commonly requested environments with Terraform, allowing developers to spin up development environments on demand.
Iterate Based on Developer Feedback: After rolling out the MVP, gather regular feedback from developers on what works and what doesn’t. Use surveys, platform metrics and analytics, and one-on-one discussions to understand where further improvements are needed.
Example: If feedback reveals that certain teams are struggling with traceability, add tools like Grafana and Prometheus for real-time monitoring and centralized logging systems like Elasticsearch.
Ship Continuous Improvements: Rather than waiting for major releases, ship small improvements regularly based on feedback. This agile approach ensures the platform evolves based on real-world usage and helps avoid technical debt or feature overload.
Example: Incrementally introduce new CI/CD pipeline templates based on team-specific needs, or improve environment provisioning based on feedback from the developer teams.
Measure Success with Data-Driven KPIs
Just as product managers track key performance indicators (KPIs) to measure product success, platform engineers need to define metrics to evaluate how well the platform is serving developers. These KPIs help identify areas for improvement and ensure the platform is driving tangible benefits.
Key Metrics to Track:
Developer Productivity Metrics
Flow State: The opportunity for developers to stay in a state of productive flow for as long as possible without context switching
Build and Test Cycle Times: The time it takes for the underlying build systems to provide the feedback necessary within the developer’s inner loop to continue work at a pace that encourages flow
Developer Onboarding Time: The time it takes for a developer who is either new to the company or new to a service to become productive with that service
Toil and Useless Cognitive Load: The cognitive load a developer must spend on low or no-impact engineering activities such as spinning up infrastructure or chasing down dependency owners
DORA Metrics:
Lead Time for Changes: Measure how long it takes for code changes to go from commit to production.
Deployment Frequency: Track how often teams can successfully deploy their code.
Change Failure Rate: The percentage of releases that result in failures or additional errors.
Mean Time to Resolve/Repair: The calculated time that it takes from an incident report to resolving or repairing the issue.
Platform Adoption and Performance:
Platform Efficiency: Monitor full feedback loops from keyboard to production, as well as failure rates and system non-determinism (flakiness).
Infrastructure Uptime: Ensure that environments are stable, reliable, and available when needed.
Developer Adoption: Monitor how often developers are using various parts of the platform, and ensure that they are adopting at rates that will provide real business improvements. If adoption is low, find out while and deliver the features developers ask for.
By measuring these KPIs, platform engineers can ensure the platform is continually improving, driving efficiency, and meeting the needs of developers.
How Cortex Abstracts Away Complexity, Ensures Alignment, and Enables Self-Service
At the heart of platform engineering is the need to provide developers with an environment where they can easily find the right information and get their tasks done quickly. Cortex, an Internal Developer Portal, helps platform engineers prioritize developer experience by providing a centralized hub for managing software, continuously assessing software, and shipping quickly according to organizational standards.
With Cortex, you can:
Centralize Documentation & Resources: Developers no longer need to search through disparate systems—Cortex centralizes everything in one place, making it easy to find environments, pipelines, and documentation.
Reduce Context-Switching: Cortex brings all critical information into one dashboard, so developers can easily find the status of open PRs, tickets, incidents, and tasks like package upgrades or documentation requirements.
Accelerate Onboarding: Make it easy for new hires or transitioning teammates to see exactly what they own, what’s available to them, and what standards exist.
Ease Security Compliance: Cortex integrates with security and compliance tools, helping developers meet organizational requirements with minimal effort, and continuously improve their software to avoid distracting incidents.
Enable Safe Self-Service: Cut the wait time and enable devs to self-serve critical steps in service creation like requesting keys, applying templates, and creating entities in adjacent tools
By providing these essential tools in a unified, user-friendly platform, Cortex helps organizations prioritize the developer experience, enabling teams to ship code faster and with fewer bottlenecks.
Conclusion
Platform engineering is about building and maintaining a robust Internal Developer Platform that abstracts complexity and empowers developers. By adopting a product management mindset and focusing on what’s driving developer pains and gains, platform engineers can deliver a seamless and efficient experience.
With solutions like Cortex, platform teams can centralize resources, automate workflows, and ultimately, accelerate developer productivity. By prioritizing the developer experience, you can turn your Internal Developer Platform into a strategic asset that drives innovation and delivery across the organization.
