Working as CEO and CTO of OpenCredo, a software development consultancy, I’ve had the opportunity to understand various customers’ platform engineering challenges Many organizations struggle to build a great platform as a product initiative. This got me thinking, why is this the case? Is there something specific that is challenging or harder to do than it appears? That is where this article and my PlatformCon 2023 talk on the same topic were born.
In the title, I give away my very firm belief that great platforms are forged in the fires of a platform as a product or product-thinking mindset. It seems there’s a disconnect when the "as a product" bit is applied to platforms. I observe that, while on paper, a product approach seems simple enough for people to follow, this is much harder to do in practice. Let’s dig into that and explore why that is the case.
Why is a platform as a product mindset important?
Product thinking is the core of building a great product, whether this is a platform or otherwise. This is because it prevents us from building something that nobody wants. The whole point of product thinking is to make sure that we put our users and their experiences front and center of what we do. So we don't just deliver a nice collection of disjoint features, but something that really produces their outcome and is useful to them.
Applying this to Internal Developer Platforms is no different. Firstly, this helps us to focus on the problem space of your internal developers. This is about doing what is needed to make life easier for them in order for them to deliver software to their end users.
As with any other product, a platform needs to be useful and desirable. This means your Internal Developer Platform should not be a ragtag collection of stuff but rather a curated set of offerings and features that developers will actually want to use to do their jobs. This is where product thinking provides us with techniques and approaches and the framework that really helps us to engage our users, get feedback, and adapt the product and the platform in order to make it fit for purpose.
With many products, you need to consider how to deal with adding new features and options to your platform. Core ideas in any product that need to be thought about and designed right from the start to ensure that you can proactively create a platform that can provide a sustainable service to your business. In short, we rely quite heavily on product thinking tools and techniques to create a good fit-for-purpose platform. Product thinking to the rescue!
But we seem to have these stumbling blocks in our way. Let's have a look at why that may be the case.
Taking internal users for granted
We don't always afford the platform the same considerations that we might if this was an external product. We know it's all about the users and their needs. However, when users are internal, we have a tendency to think that we have a better insight track into what they're actually thinking, what they want, and maybe we can just short-circuit some of the user interaction stuff and get there a little bit quicker.
This includes things like their level of ability. You might say, "Well, they're developers, I'm a developer, they should know how to configure a YAML file, so I'm sure it's okay if we just provide that as an interface for the system." You might also think that you know what's best for them in terms of best practices for CI/CD and then impose that on them as the way to do things. Also, they are a captive audience; they can't really go anywhere. There's an assumption that internal users will be more willing to accept whatever is put in front of them because they can’t say no. Maybe some features aren’t quite ready yet but they're pushed out anyway because they're just internal users, and it's not going to make that much of a difference.
Treating the platform as a cost center
Because most platform teams don't actually ship an actual product to the end users, they are sometimes treated as a cost center. Treating the platform as a cost center can cause problems if it's not recognized.
Organizations that treat the platform as a cost center might focus on delivering very specific features on time and within budget. But that’s not really what we're looking for here. We want more product thinking where we have product roadmaps informed by user feedback. This mindset runs the risk of having budgets and cost-cutting measures impact the platform team because it’s perceived as not shipping a real product.
The antidote to this is to try and market the value of the platform as either a revenue or a cost-to-market enabler. This can be done by suggesting the use of metrics. For example, you might suggest having a look at how fast it takes for a new team to onboard a new product and get it to market without the platform and with the platform. This can be used to actually drive and provide evidence for the fact that the platform really does provide end usage to the end users and to the business.
Making the platform mandatory
The second stumbling block is one that can come across because we often insist on making our platforms mandatory. If you look at other successful products out there, no one forces you to buy an Apple phone or to use AWS services. You generally do so because you've decided it's worth it. Product thinking understands this and gives the techniques and the approaches to try and build in specific opportunities to solicit regular feedback from users to actually improve, adapt, and make it a more attractive proposition as you go along.
The problem is that if you make the platform mandatory, you close off some of these feedback loops, while an optional approach invites more discussion and innovation. Feedback is often not provided because people will think, "Well if it's mandatory, why would I bother giving feedback? It doesn't matter anyway. It's not critical, and they're not necessarily going to do something about it because they've decided how they're going to do it in any case." So, optional is really the way to go.
But why do we try to make the platform mandatory? Sometimes, I would say this mandatoryness comes because there's pressure to use the platform for purely regulatory or security compliance. Now, don't get me wrong, I'm not saying that this can't be a feature of the platform or that it can't be used to achieve this, but when it becomes the driving force behind things, then the focus shifts off of what the user needs more onto how can we get them to actually comply with the least amount of fuss. If this is actually one of your goals, don’t opt for a command and control type approach. Instead, give the teams a choice. So, define and communicate clearly what is required of either security or compliance aspects and allow the teams to do that themselves. Tell them, "The platform can do it for you, and actually, it will go X times faster, or it will be so much easier." Use a carrot rather than a stick to entice them onto the platform.
With mandatory platforms, you will find that your teams may still end up being successful. But it may be in spite of the platform rather than because of it. You don't want this. Shifting more to have an optional platform is the way to go in this case.
Mono platform thinking
Product thinking is all about focusing on the user. Building the right thing also requires focusing on the problem first instead of the solution. However, our focus is often drawn to the solution and, more specifically, the one right solution that we need to build. Instead, we should recognize that the platform could just as easily be a collection of various curated things brought together.
Too many teams assume that the platform needs to support every single use case out there. You may be on a digital transformation where you have a big legacy estate that you need to port over. But this doesn't mean that every single application from that legacy estate needs to land and be catered for on your platform. Some may just need retirement, some may be lifts and shifts. These probably couldn't and shouldn't land in a cloud-native platform if it's not suitable. But the assumption that you must cater to everybody runs the risk that the main platform that you're building becomes diluted and not fit for anyone in the end. You just end up with a jack of all trades and a master of none-type platform.
The other area where assumptions are made is around the offerings that are actually implemented in the platform. If, for example, you're offering a CI/CD platform or a CI/CD feature, it may be that you think there should be only one of these things. We've only got enough resources to actually build one, and there shall be only one. But there's going to be different teams with different requirements. Some may want a lot of control, some may just want to give one or two parameters and get a pipeline going. It's okay to have multiple different implementations for the same feature. You obviously don't want a plethora of them, but this assumption that there must be only one implementation is something that can cause you to create features that are not fit for purpose.
Team composition
Some of the challenges can occur because of how we actually put our teams together to tackle building the right products. Our blind spots and our assumptions can cause us to create less-than-ideal team setups.
In many companies, platform teams start out by being staffed with predominantly infrastructure engineers. This is a very natural play because the platform is seen as more ops-y in nature; you're building infrastructure services. However, we observe that this natural skew towards the op-centric sort of solutions ends up with more op-centric solutions. Instead, what we really want is this balance of both infrastructure and application. This means we want to have a bilingual team, for lack of a better phrase, and a mix of engineers that really understand architecture and application requirements, as well as infrastructure, in order to help really bridge the gap.
This point may be a little bit controversial, but in a platform team, the product owner or the product management type role is really key. Ideally, you have somebody with a technical background here. This is not essential, but it is certainly helpful because being forearmed with some of this knowledge can really help to build more natural empathy and understanding with the various different users of the platform in different situations. It can be useful when they may need to be a referee in terms of different requirements coming in, competing requirements, or indeed, actually to help understand and assess when to make trade-offs about what things should be in the platform and not. Obviously, you would be working with your technical architects in this particular case and your platform engineers. If you can find a product owner who has a technical background, it makes a big difference in smoothing some of the road to understanding some of the challenges that your end users have.
Another less-than-ideal setup is to have a static or non-evolvable team. This is specifically where the platform team, in whatever shape or form you kind of find it, is not able to spare the time or the resources to help teams onboard and troubleshoot. This time needs to explicitly be built in and factored into. We find the concept of using enablement teams, as it's described in Team Topologies, as a really helpful mechanism here. This will allow your platform team to really engage with the users, and build in solid feedback loops.
Technology focus
As engineers, we tend to have a very unhealthy focus on technology. We always want to start by building something concrete, and this can really lead to problems, and you can trip over yourself if that's the case.
The key to building the right thing is to focus on your users first and the technology last. So don't let the tail wag the dog. Think of your users first, do the tech last. If you want more on this, I suggest that you have a look at my PlatformCon 2022 talk.
Conclusion
In conclusion, I think great platforms are indeed forged in the fires of a platform as a product or product-thinking mindset. But you need to be aware that there are some potential stumbling blocks on this path. This can happen because there are parts of your organization's approach and ways of working that may seem very natural and default to you, but some of these assumptions may ultimately work against you in trying to achieve the end outcome if you aren't aware of them.
.webp)
.webp)
