‘You build it, you run it.’ In 2006, Amazon's CTO Werner Vogels introduced a transformative shift in software engineering. Traditionally, developers simply would pass their code to operations teams to manage in production. However, this new approach would require developers to take full ownership of deploying and running their applications and services from start to finish. Thus, DevOps had arrived.

Since then, DevOps has revolutionized the way we build, test, and deploy software, breaking down silos between development and operations teams. So far, it all sounds great. The challenge is however, as organizations scale, they begin to face a deluge of new issues - cognitive load on developers, tool sprawl, fragmented workflows, operational inefficiencies, and not to mention the ever-increasing complexity in managing infrastructure. As time went on and DevOps developed, these pain points led to a growing realization: simply adopting DevOps practices isn’t enough for the majority of organizations to achieve streamlined delivery and innovation.

This is where platform engineering comes into the picture. A Platform engineer's core focus is on building and managing an Internal Developer Platform that reduces the cognitive load on developers, enables developer self-service, standardizes infrastructure, and automates end-to-end workflows. Through this, platform engineering teams reduce friction while ensuring consistency and scalability. But how do they actually ensure this?

By adopting the Platform as a Product approach. This new methodology is one of the foundational concepts of platform engineering. It borrows best practices from product management principles and involves your platform team treating their IDP like a product, and their developers as their customers. By building and running an IDP based on user feedback and business needs, your IDP stands a better chance of delivering not just better business outcomes, but also better working conditions for developers.

This shift is the key difference between a classic DevOps approach and platform engineering. DevOps often tends to solve individual and team problems (e.g. by training devs to solve problems on their own), while platform engineering thrives on solving organizational problems at scale. 

What does platform as a product mean?

A Platform as a Product approach sits at the core of platform engineering. As Manuel Pais, co-author of “Team Topologies,” explained in his talk at PlatformCon 2022, successful platform teams treat their IDP like any other product and follow product management principles and best practices. This approach ensures that a platform team builds an IDP that developers actually want to use and that can deliver value to the organization.

The IDP should abstract the complexity of the underlying infrastructure stack while providing developers with just the right amount of context to perform their tasks effectively. To achieve this balance, the platform team must closely engage with developers and develop a deep understanding of the challenges they face.

To better understand this, a helpful analogy is seeing the platform team as a startup that’s developing a product (and a respective go-to-market motion). Imagine this hypothetical startup’ product has a total addressable market (TAM) that is equal to all the application developers in the engineering organization. Similar to a startup, the platform team will launch a V1 of the platform (a Minimum Viable Platform, or MVP), then iterate on it continuously based on the feedback of its users (and customers) - the developers. 

The platform team is responsible not only for developing the IDP but also for promoting it internally, gradually gaining support from developers and other key stakeholders such as architects, infrastructure and operations teams, security, and executives. In larger enterprises, there may be multiple platform initiatives, with different teams competing to capture the engineering organization's TAM by marketing their own IDP solutions.

Platform as a Product is essential to providing an Internal Developer Platform that lets developers move faster without breaking things (i.e. staying compliant and following security best practices). This is what ultimately drives down time to market for the entire organization and delivers the high ROI that platform engineering promises

Challenges of Platform as a Product

Shortage of product management talent 

There aren't enough skilled product managers (PMs) with the experience to build complex products like an Internal Developer Platforms that meet the needs of diverse stakeholders. At the same time, many companies are reluctant to assign their top technical PMs to platform initiatives, often prioritizing customer-facing products instead, as they view the platform as a cost center. However, leveraging your best PM talent for the development and rollout of an IDP may actually yield the highest ROI.

What can help? Upskilling through courses like the official platform engineering community course, Platform Engineering Fundamentals, which covers key concepts such as Platform as a Product and helps you promote them within your platform team and the broader engineering organization.

Politics

Product management is already a delicate balancing act, and it becomes even more challenging when applied to platform product management. While customer-facing products receive clear feedback through sales, internal products like IDPs are influenced by more complex dynamics that extend beyond simple supply and demand, often involving internal politics. Who should have the final say in how the platform is built—the developers or the CIO? The answer is not always as straightforward as it should be.

Listening too closely

It is crucial to maintain tight feedback loops between platform teams and developers, which often involves a key aspect of good product management: user research. However, a common pitfall is interviewing developers and then building exactly what they said they wanted, only to see little platform adoption afterward. How could that happen? Didn’t you give them exactly what they asked for?

User research isn't about building what developers ask for directly; it's about identifying and understanding their pain points and creating solutions at a higher level of abstraction.

As Henry Ford famously said, "If I’d asked customers what they wanted, they would have told me, ‘A faster horse!’"

10 proven best practices

Build vs. buy vs blend 

The market reached a maturity level where it doesn’t make sense anymore to build everything from scratch. You should make a business case and do your ROI calculations as early as possible. According to our DevOps Benchmarking Study 2023, the best-performing platform engineering teams blend OSS with commercial vendor offerings but do not build everything from scratch. Check the platform tooling landscape for inspiration.

Apply well established architecture patterns 

With a three-tier architecture (presentation, application, data): start building from the backend; do not simply put a developer portal as a presentation layer on top of your existing setup and build additional logic into it. Build the house first, then the front door.

This reference architecture for a multi-cloud setup on AWS and GCP highlights an enterprise-grade Internal Developer Platform built with Backstage as the frontend interface layer, and the Humanitec Platform Orchestrator for the backend logic.

Everything as code

Consider code as the single source of truth which helps maintain transparency, increase reliability, and simplify maintenance. An IDP that’s code-first at its core allows for disaster recovery, versioning, and structured product development principles. This does not exclude further interface offerings such as a UI (portal), CLI, or API.

Build golden paths over cages

Creating golden paths that provide best practice guidance and recommended approaches helps lower cognitive load and improve security and standardization. IDPs that apply smartly layered abstractions give developers the choice to follow the golden paths and be free to leave or change lower-level configs if the security posture allows.

Take an 80/20 attitude to platforming

Do not try to please everyone. To adapt to different situations, meet diverse needs, and benefit from evolving technologies, staying open-minded is key. But your platform design should not try to cover every technology on earth or convince every developer in a user base. Do not assume that you will be able to please 100% of developers. Instead, consider achieving 80% a great win.

Leave platform interface choice to the developer

To ensure adoption, give developers the freedom to use the interfaces they’re most comfortable with and that best meet their needs. Provide the option to use an OSS workload

specification like Score, a portal (GUI), CLI, or API.

Security from scratch

To get buy in, implement security best practices from the get-go. If the V1 of your platform doesn’t fulfill security and compliance requirements and if there is no proof that the platform will even support ensuring security and compliance by design, security teams will veto and your platform initiative is dead before it could even properly start.

Measure from the beginning 

Measure success with hard numbers to support informed decisions and generate stakeholder buy-in. Choose metrics wisely, considering both leading (e.g., automation and complexity scores) and lagging indicators (e.g., DORA metrics). Track leading indicators in non-production environments early on. Remember to include NPS scores for developer satisfaction, as well as stability metrics, SLOs, and SLAs.

Gain stakeholder buy-in

Make sure all stakeholders have a seat (besides the developers - your customers). From security to compliance and legal teams, from architects to I&O teams, and important for the funding of your platform engineering initiative: executives. Make sure you build a platform team where important stakeholders are represented by heralds and the team goals are aligned with those of your stakeholders.

Think about adoption from the first day

If the platform is not used, it is dead. This is about internal marketing/evangelism.

Identify the right first team to onboard and make them advocates of your platform They are essential for platform success and developer adoption.

Conclusion

Platform engineering is continuously evolving. However, following a platform as a product approach will always be a core component of a successful IDP. By investing in user research, building out a product roadmap, defining a clear mission, and establishing continuous feedback loops, platform teams can avoid the pitfalls that doom platform engineering initiatives.

Avoid all these challenges and enact these best practices by building your Internal Developer Platform within the Humanitec Minimum Viable Platform program and working alongside our platform architects.