Introduction
Welcome to our second lesson on platform engineering. In our previous session, we established a clear definition of platform engineering, distinguishing it from DevOps and traditional infrastructure roles. We concluded that the pivotal difference lies not in the technology, but in the adoption of a product mindset, where internal developers are treated as valued customers.
This lesson delves deep into that very concept. Our objective is to explain the platform-as-a-product mindset and how it changes the way platforms are built, maintained, and evolved. For an experienced engineer like yourself, this isn't just about soft skills; it's about understanding a fundamental strategic shift that has profound implications for system design, team structure, and an organization's ability to innovate. We'll explore why this mindset is the dividing line between successful and failed platform initiatives, connecting it to core sociotechnical principles like Conway's Law and cognitive load theory.
The Central Dichotomy: Project vs. Product
Many expensive, well-intentioned internal platform initiatives fail. They become ghost towns, ignored by the very developers they were meant to help. The root cause often traces back to a single, critical mistake: treating the platform as a finite project instead of a living product.
A project has a defined scope, a budget, and a deadline. The implicit goal is to "finish" the work and move on. A product, by contrast, is never finished. It lives, breathes, and evolves to continuously meet the needs of its users. The article "Why enterprises fail at platform engineering" from PlatformEngineering.org captures this distinction perfectly.
Why enterprises fail at platform engineering: Project vs Product ...
This article gets straight to the heart of the matter, identifying the project-first approach as the primary reason for platform failure.
Please read the introduction, from the beginning, to understand the core problem. Then, read the section on the PaaP mandate. Pay attention to how it shifts the focus from delivering features to solving actual developer problems through investigation and observation.
This mindset shift from project to product manifests in every aspect of the platform effort. The image below, from ProdPad, offers a concise summary of these contrasting philosophies.
The core of the product mindset is viewing developers not as a captive audience but as customers you must win over. Their adoption of the platform is voluntary, earned by the platform's quality, usability, and tangible value. This changes how you measure success, how you structure your team, and how you plan for the future.
A more academic paper on this topic provides a fantastic summary table that crystallizes this paradigm shift. It’s a powerful tool for diagnosing which mindset is active in an organization.
[PDF] How Turning Internal Platform Solutions into a Product Increases the ...
This paper provides a structured, research-backed view of the PaaP concept. We will focus on its definitions and the comparative table.
First, read the brief definition of PaaP in the first paragraph of the "Results and Discussion" section. Then, carefully study Table 1, titled "Comparison of traditional and product approaches". This table is a crucial reference point, contrasting the two approaches across six key criteria: objective, users, success metrics, team composition, evolution, and funding.
As you can see from the table, every dimension shifts.
- Objective: From simply "centralizing infrastructure" to "increasing developer productivity."
- Metrics: From technical uptime and cost to business-aligned outcomes like DORA metrics and developer satisfaction (NPS).
- Evolution: From a reactive, ticket-driven backlog to a proactive, roadmap-driven strategy based on user research.
- Funding: From a cost center to be minimized, to a value center that drives business growth.
The 'Why' Behind the Product Mindset
This shift is more than just a change in vocabulary; it's rooted in fundamental sociotechnical principles that govern how complex software systems are successfully built by human beings.
- Managing Cognitive Load: As an engineer, you know that your capacity for holding complex problems in your head at any one time is finite. This is known as cognitive load. In software development, we can break it down into three types. The Team Topologies authors provide an excellent explanation.
Monoliths vs Microservices is Missing the Point—Start with Team Cognitive Load - Team Topologies
This excerpt from a talk by Manuel Pais, co-author of Team Topologies, explains cognitive load in the context of software engineering.
Please watch the segment from the definition of cognitive load. He defines the three types: * Intrinsic: The inherent difficulty of the problem domain (e.g., understanding banking regulations). * Germane: The "good" cognitive load, spent on deep problem-solving and learning within that domain. * Extraneous: The "bad" cognitive load, spent on wrestling with tools, processes, and environments (e.g., "How do I deploy this thing again?"). The primary goal of a platform, viewed through this lens, is to **ruthlessly minimize extraneous cognitive load** for development teams, freeing their mental energy for the germane load that actually creates business value. A project-minded platform often *increases* extraneous load by being poorly designed or solving the wrong problems. A product-minded platform is obsessed with reducing it.
- The Reverse Conway Maneuver: You're likely familiar with Conway's Law: an organization's communication structures will be mirrored in the architecture of the systems it produces. A product-oriented platform team acts as a conscious application of the reverse Conway maneuver. By providing a well-defined, self-service product with clear APIs and documentation, the platform team deliberately shapes the organization's communication pathways to foster a desired loosely coupled architecture, enabling stream-aligned teams to work with greater autonomy.
Platforms for Innovation, Not Just Harmonization
A common trap for project-minded platforms is to focus exclusively on cost reduction through standardization. This leads to what architect Gregor Hohpe calls the "pyramid model," where the platform tries to anticipate every need, leaving only a tiny "tip" of custom work for developers. This stifles innovation.
A product-minded platform aims for something much more powerful: enabling economies of speed. It seeks to foster innovation and diversity, not just enforce homogeneity. Gregor Hohpe's talk on this subject is a masterclass in platform strategy.
Platforms: Build abstractions, not illusions - Gregor Hohpe - NDC Porto 2024
In "Platforms: Build abstractions, not illusions," Gregor Hohpe uses brilliant analogies to explain the strategic purpose of a modern platform.
First, watch the opening segment from the start of the main talk, where he contrasts economies of scale with economies of speed and introduces the "innovation through harmonization" concept using the car industry as an example. The key insight is that the platform's goal was to enable more car models, not fewer. Next, watch his proposed test for a platform, from the binary test. Has anyone built something on your platform that surprised you? If not, you may have inadvertently built a restrictive pyramid.
This perspective reframes the platform's role. It's not a gatekeeper or a central service desk to be put "in the cycle" of development via tickets. Its role is to act like a well-oiled bearing, making the entire development cycle spin faster.
The Evolving Nature of a Platform Product
Because a platform is a product, it has a lifecycle of continuous discovery, planning, and development.
This cycle never truly ends. A platform is never "done." The LINK article you read earlier outlines a typical maturity journey:
- Minimum Viable Platform (MVP): Validate assumptions and solve a high-value pain point for a single pioneer team.
- Production Readiness: Focus on stability and resilience.
- Adoption and Scaling: Automate onboarding and drive broader, voluntary adoption.
This evolution also involves strategic decisions about what the platform should and should not do. As the underlying technologies (e.g., cloud services) mature, the platform must adapt. Gregor Hohpe offers another powerful metaphor for this: the "rising ocean level."
Platforms: Build abstractions, not illusions - Gregor Hohpe - NDC Porto 2024
Let's return to Gregor Hohpe's talk for one more strategic concept.
Watch the segment from the "rising ocean level" metaphor. This explains how a platform team must decide whether to "float" by shedding capabilities that have become commoditized by cloud providers and move up the value chain, or risk "submerging" by maintaining functionality that is no longer a differentiator.
A project mindset often falls victim to the sunk cost fallacy, continuing to maintain an internal tool long after a better, cheaper managed service is available. A product mindset forces the discipline to ask, "Does this feature still provide unique value to my customers?" If not, it's time to deprecate it and focus resources on the next high-value problem.
Conclusion
In this lesson, we have moved beyond a surface-level definition of platform engineering to explore the strategic core that drives its success: the platform-as-a-product mindset.
Key Takeaways:
- Treating an internal platform as a finite project leads to low adoption and wasted investment. Treating it as a living product with developers as customers is the foundation for success.
- This mindset shift transforms a platform initiative from a cost center focused on technical outputs (uptime, SLAs) to a value center focused on business outcomes (developer productivity, satisfaction, time-to-market).
- The primary function of a product-oriented platform is to minimize extraneous cognitive load for developers, freeing them to innovate.
- A successful platform enables economies of speed and innovation, not just economies of scale and cost savings. It provides meaningful abstractions that empower developers to build surprising and novel solutions.
- A platform is never "done." It evolves through a continuous cycle of user research, roadmap planning, and iterative development, strategically adapting to the "rising ocean level" of commoditized technology.
Preview of the Next Lesson
Having established the "why" and "how" of the product mindset, we will now turn to the "what." In our next lesson, we will examine the core components of a modern Internal Developer Platform (IDP) and see how they come together to provide the developer self-service capabilities we've been discussing. We will also introduce the concept of "golden paths" and their role in guiding developers.