Platform engineering has taken the world by storm, and for good reason. Good platforms reduce TicketOps, standardize config setups, and cut lead time and time to market. Despite the discipline’s new popularity, there remain some questions about what sets platform engineering apart from DevOps. The answer to those questions lies in the platform as a product approach–the heart of every successful platform engineering effort.
What is Platform Engineering?
According to Luca Galante, platform engineering is “the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era.” Platform engineers build an internal developer platform, which “consists of many different tech and tools, glued together in a way that lowers the cognitive load on developers without abstracting away context and underlying technologies.”
What is the Platform as a Product Approach?
A product approach requires user research, a defined mission, leveraging lighthouse teams, getting regular feedback, iterating and marketing your platform for internal buy-in. Together, these product management best practices will ensure your platform enables true developer self-service and finds the right level of abstraction.
“Build it, and they will come” is not a viable strategy for ensuring developers will adopt your platform. Similarly, forcing developers to use a platform is likely to fail. Mandated usage creates resentment, reduces trust and results in shadow ops. To avoid your platform’s untimely demise, you have to treat your platform like a product and sell it to your customers: Your developers.
This article provides a high-level overview of what a product mindset looks like in practice and why each component contributes to the success of your platform.
Do Your Research
Unless you gain a comprehensive understanding of developers’ pain points and what they’re already doing to mitigate those issues, you won’t build a platform people actually want to use. Hashicorp’s Michael Galloway shared this example of a user survey he conducted with his team while at Doma. The idea is to ask questions about the full software delivery process, from the planning stages of the interviewee’s work to debugging and testing. This way, the platform team can prioritize creating features to solve developers’ most frustrating problems.
Oftentimes, platform teams will find that teams have conflicting wants and perspectives on what the platform should be. A platform product manager will help translate disparate responses into an actionable and successful plan. Successful platform teams also research open source and commercial tools and integrate pre-built solutions into their platform where beneficial. They study blueprints, like the internal developer platform reference architectures developed by McKinsey, as a starting point.
Define Your Mission
Your mission statement gives your platform team a clear identity and priorities. It’s also a starting point for understanding and communicating your impact on the business to relevant stakeholders. Good mission statements are emotional and inspiring, simple but meaningful, match the longevity of the organization and are informed by user research.
Leveraging Lighthouse Teams
When starting their platform engineering journey, many organizations don’t know what to build first. The confusion arises from having two important yet conflicting priorities. On the one hand, your platform team doesn’t want to bite off more than it can chew by building too many features at once. On the other hand, platforms that are thin enough to cover the entire enterprise often fail to provide enough value to individual teams.
The way to strike the right balance is by leveraging lighthouse teams. A lighthouse team is the first group of people you’ll choose to build your organization’s platform for, so spend a lot of time with them to get it right. Cultivate ambassadors and evangelists and give them time to get the rest of the team (and the organization!) on board with your platform. Once you’ve built a platform that provides real value to your lighthouse team, repeat this process with more teams across the organization.
The lighthouse team approach is valuable because it helps platform teams avoid boiling the ocean while also ensuring your platform provides real value every step of the way.
Stay in the Loop
Initial user research is not enough to sustain a successful platform engineering effort. Platform teams should solicit regular feedback from developers and use it to iterate the platform.
Market Internally to Get Buy-In
Conversations about platform engineering often focus on developers, but developers are not your platform’s only stakeholder group. Your platform team will also need buy-in from managers, SysAdmins, DevOps engineers and the C-suite.
In his PlatformCon 2023 talk “How to communicate the business value of platform engineering,” Gartner’s Manjunath Bhat shared Gartner’s Enterprise Value Equation as a foundation for platform teams to understand and communicate the value of their Internal Developer Platform to different stakeholder groups.
The process includes assessing stakeholder priorities and concerns, identifying and defining value enablers, building a value map to map value enables to stakeholder impact, supporting the value story through outcome metrics, and communicating the “why” and realized value to the organization.
Sounds Great. What’s the Catch?
Applying a platform as a product approach can be difficult in practice. For example, many organizations struggle to afford the internal developer platform the same considerations as they would an external product. When working with internal developers, it’s easy for platform teams to make assumptions about what those users know, want and need. However, platform engineering requires avoiding these assumptions and always seeking user perspectives.
Another common pitfall organizations encounter is mandating platform adoption. Making the platform mandatory closes off the critical feedback loops platform teams need to gauge the success of their platform and make continuous improvements.
Conclusion
The platform as a product approach is what sets platform engineering apart from DevOps. It’s deceptively simple but important if you want to build an internal developer platform people actually want to use.