Welcome to the second part of our Platform Engineering series, where we continue our journey from “farm to fork.” In the first part, we laid the groundwork by exploring the foundational principles of platform engineering as a socio-technical discipline. Now, we’re moving into the next stage: understanding the challenges that make building a truly great platform so difficult.
Platform engineering, when done right, can significantly enhance an organisation’s ability to deliver value. However, the path to success is often fraught with obstacles. Drawing on insights from my talk, Why it seems so hard to create a great Platform-as-a-Product?, we delve into the complexities of treating your platform as a product, a concept that’s crucial for long-term success, but one which is often misunderstood and mis implemented in practice.
Platform-as-a-Product
You can’t browse the internet for too long without encountering advice on the importance of treating your platform like a product.
Product thinking is essential for building a successful product—whether it’s a platform or something else—because it ensures that what you’re building is actually something people want.
The core idea of product thinking is to put the users and their experience at the forefront, so you don’t just deliver a collection of nice but disconnected features, but rather services and solutions that provide valuable outcomes tailored to their needs.
This approach requires having a clear value proposition, understanding your users (in this case, your internal teams), and continuously iterating based on their feedback. However, unlike a traditional product, your users are internal—they’re your colleagues, and they rely on your platform to get their work done.
Even though product thinking is well understood in traditional contexts, with strong evidence supporting its effectiveness, many organisations struggle to apply these principles to the platform space. There seems to be a disconnect, and here’s why I believe that happens.
Challenges in Implementation
The internally focused nature of platforms can surface biases and ways of working that sometimes (often unintentionally) short-circuit good product-thinking approaches. If not recognised, these can cause blind spots, leading to challenges down the line. Whilst not exhaustive, The five most commons issues we see when engaging with clients are:
- Internal Platforms Often Aren’t Given the Same Level of Consideration as External Products:
Platform teams frequently assume they understand the needs of internal users without conducting thorough research, leading to platforms that may not fully meet expectations. “I’m an engineer building for other engineers, so I know what they want/need” is a refrain we often hear. This assumption can lead to internal users being taken for granted, seen as a captive audience who will use the platform regardless of its quality. In contrast, with external products, product thinking involves explicitly asking users what they need through surveys and other forms of research to tailor the interface and approach accordingly. This level of diligence is often overlooked with internal platforms.Moreover, internal platforms are often viewed as cost centres rather than value-generating products. As a result, they are managed more like projects focused solely on delivery, rather than products with a well-thought-out roadmap that evolves based on user feedback and needs. Shifting from a “project” to a “product” mindset is crucial for overcoming this challenge and ensuring the platform meets its users’ needs.
- Mandatory Usage:
When platforms are required rather than optional, it can stifle feedback and innovation which is a key part of product thinking. Users may feel less inclined to provide input or suggest improvements because they have no choice but to use the platform. Making platforms optional and enticing users with benefits like ease of use or improved efficiency encourages more engagement and better aligns the platform with actual user needs. Opting for the carrot instead of the stick approach can yield better results in many cases.
(Sidebar: There are some very good mandatory platforms out there, but they heavily prioritise and focus on getting and incorporating user feedback!)
- Optimising for a Mono-Platform:
Organisations often try to build a single platform to serve all use cases, leading to a diluted platform that tries to cater to too many needs. This approach often results in a “jack of all trades, master of none” scenario. Instead, consider focusing on building the platform to cater for the majority of users and use cases which will benefit the most (eg the 80%). Accepting that there will be some which simply don’t fit your platform (the remaining 20% or whatever percentage works for you) can be a real turning point for teams as they realise this helps them focus on building the right thing, and not just any thing.
- Team Composition:
Many platform teams are composed primarily of infrastructure engineers, which can lead to solutions that are too operations-focused and not aligned with application developers’ (and other community) needs. Effective platform teams should be balanced, incorporating infrastructure, application, and product expertise. Including a product manager in the team is crucial for success.
- Static Teams:
When teams are static and not designed to evolve, it leads to limited interaction with end users and insufficient feedback loops. As part of our platform engineering consulting and delivery engagements, we regularly incorporate the concept of enablement teams and other aspects of team topologies into our approach. This really helps to work closely with users to gather insights and continuously improve the platform based on real-world needs.
Conclusion
As we conclude this second part of our Platform Engineering series, it’s evident that building a great platform is no easy task. We see how great platforms are very much forged in the fires of the “Platform-as-a-Product” mindset. But also recognise the challenges can be numerous and often stem from the unique dynamics of internal platforms—where assumptions, biases, and the complexities of internal team dynamics can undermine even the best of intentions.
We’ve explored how treating your platform as a product can help address some of these challenges, but it requires a disciplined approach. Understanding your internal users, being deliberate about engaging and soliciting feedback instead of just relying on mandatory usage, and ensuring your platform is focused and adaptable are all critical to success. Additionally, having the right team composition and maintaining a flexible, evolving structure are essential to creating a platform that truly meets the needs of its users.
Being aware of these potential stumbling blocks in advance will help you adjust your approach or make corrections before they turn into significant issues.
Now we turn our attention to assessing where you stand on your platform engineering journey and how to ensure continuous improvement. Just as a farmer regularly checks crop health and makes necessary adjustments to guarantee a fruitful harvest, you’ll need to evaluate your platform’s maturity and take deliberate steps to refine and optimise it over time. In the final instalment of this series, Part 3: Assessing Your Platform Maturity and Continuously Improving, we’ll conclude our exploration by focusing on how to move closer to the ultimate goal: delivering a platform that truly empowers your organisation.
Looking for more help?
OpenCredo has been working with organisations of all shapes and sizes on their platform engineering initiatives. This ranges from strategic consulting and advice, to reviews and assessments, a platform accelerator offering, as well as the provision of leadership and hands-on delivery teams to accelerate the adoption of fit-for-purpose platforms. If you’re looking for more help in this area, please reach out below and let us know how we can help you.
This blog is written exclusively by the OpenCredo team. We do not accept external contributions
Related articles
