While “build it and they will come” might be a viable strategy in the movies, it doesn’t translate well to internal platform development. In fact, relying too heavily on the idea that developers will choose to use your platform usually leads to a lack of adoption.
By using basic product management techniques, you can ensure your Internal Developer Platform (IDP) project meets the needs of its stakeholders.
The developer is your customer
Mandated usage leads to resentment, "shadow infrastructure", and reduced trust.
One of the first rules of good platform development is that the developer is your customer. Sure, this might seem obvious to you, but for many organizations, the idea of treating a developer as a customer is something of a revolutionary concept.
There’s a pattern in a lot of organizations where it’s not always the developer that had the idea to build a platform. Sometimes, the platform is an effort to control costs or standardize the development process. And yes, those things are important, but at the end of the day, if the customer doesn’t accept the platform, you’re going to have a bad time.
It’s the job of Product Managers (PMs) to make sure that the customers of their products are happy. So, when developers aren’t considered as customers, they end up resenting being forced to use the platform because there’s no incentive to voluntarily adopt it into their working environment. A mandated move from something like AWS onto your own IDP won’t gain anything but compliance, and in most cases, this mandated usage hurts the morale and trust of your engineering teams.
Not only that, but you’ll likely find that your developers disobey the paths you set out and start using other tools that work better for their tasks. This shadow infrastructure doesn’t just mean the platform you’ve spent money on developing isn’t providing value, either. It’s also a big security risk if developers aren’t storing keys or secrets in the right way.
This feeds into another common myth - that if you build a platform, your developers will adopt it with no problems. It’s a misconception that still plagues platform product development.
A lot of people like to think Steve Jobs was this amazing person that came out with the iPhone without any customer feedback. It’s entirely a myth. Even the best Product Managers on Earth use customer feedback, do user testing, and work hard to make sure they’re building the right product for the customer.
Some platform project leaders still believe that they can build the perfect platform based on the vision of one person. It doesn’t work. So many platform initiatives get bogged down because leaders focus too much on the ideas of one guru-type person instead of the needs of the customer.
When you don’t have PMs to handle your IDP project and implementation, then your platform development team won’t have a fixed focus. Instead of having a roadmap of features that would serve the customer, you instead end up developing every feature that every user requests.
So, you end up building a product with a ton of half-baked features that don’t fit together. Certain abstractions might work, but others don’t. It’s another reason why it’s vital to think of the developer as your customer, because otherwise you’ll end up building a Rube Goldberg machine by mistake.
Three platform requirements to remember
So, what are the main requirements for an internal platform, and how does this relate to product management?
The first is security. When you build a platform, you need to make it easy for engineers to conform to your organization’s security mandates. Things like standardizing secret storage and traffic flow make voluntary adoption a lot more likely.
Secondly, you need to set defaults for the developer experience. You need to make it really clear how to comply with these defaults and that it’s more likely that engineers can meet those requirements if they use the platform in a standard way. While there will be exceptions where engineers need to take a different approach, having a comprehensive set of defaults ensures that those instances are truly exceptional.
Last, but certainly not least, you have to consider the cost. It’s remarkably easy for costs to rise higher than you expect, particularly given how many software development tools are on the market today. But one of the great things about internal platforms is that they can nudge engineers towards using tools that meet your cost requirements and their needs.
What do Product Managers do?
The key thing to understand is that PMs don’t operate in the same way as engineering managers or developers. Typically, PMs will be spending a lot of time with developers to understand their workflow, routines, and pain points. It’s really important that they build relationships and solicit feedback from engineers to build trust.
What PMs do is show developers that you’re not just trying to sell them something. They show your developers that you’re listening to them and that, if they have any concerns, they can trust the PM to have their back.
It’s not just about developers, though. PMs will meet with other stakeholders like security, financial operations, data analysts, and others to make sure that the platform makes it easy to comply with company standards. They’ll inevitably come across trade-offs between features, cost, and security, but it’s up to PMs to ensure the trade-off is acceptable to all (or most) stakeholders.
So, it’s the job of a PM to understand how people use - and want to use - the product, and make sure that the product evolves based on customer feedback.
So, why do organizations still hesitate to hire PMs?
Cost is usually the biggest hesitation, but the truth is that hiring a PM is significantly cheaper than building a product that customers don’t want or doesn’t meet their needs. If you don’t think the PM will achieve the goals you want to achieve, then that’s a problem with the way product management is structured - not with idea of hiring a good PM.
While you can make a case that an engineering manager should do product management, it’s not ideal for every organization. Engineering managers are usually focused on helping their teams advance their careers and ensuring that their projects are completed on time to company standards. It’s a vastly different job from product management. While it can be effective in some circumstances, it’s better to hire someone who’s directly focused on customer needs.
On that note, mandated usage is often an excuse for not hiring PMs. When you don’t treat the primary user with respect, you end up with a lot of resentment. Sure, you’ll get some adoption of your platform, but you really can’t afford to upset your developers.
While this last point - the idea that platform devs know what they need in a platform, so they should build it - has some credibility, it’s not ideal. Developers have to think about different problems than their managers or PMs, so you’ll end up with a vastly different feature set. It’s important to understand the developers’ point of view, but getting them to build your platform means you’re missing out on the other viewpoints PMs can bring to your platform project.
The most valuable platform metric you’re (probably) not tracking
Of course, I’m not saying that you shouldn’t be tracking DORA metrics. But, if there’s one thing you need to take away from this talk, it’s this:
If you build a platform that helps your engineers get their jobs done, be more creative, and sleep at night, you’re going to have happier engineers. You take some of that stuff off their mental load, and your engineers will feel more productive and will build the products they came to your company to build.
With the engineering labor shortage, you need to be building platforms that encourage the engineers you have to stay with your company. A platform built with them in mind makes them far less likely to quit.
