Internal platforms are products too!

As companies grow, engineering teams start gathering more and more common layers in the company's product parts they own. So instead of each of them "re-inventing the wheel", internal platforms are created to encompass all the common layers or even to add new layers that serve specific purposes. It's quite common to have a "monitoring" platform, a "deployment" platform, a "development environment" platform, a "log aggregation" platform, a "compliance" platform and so on and so forth.

These platforms are internal products whose users are other employees from the very same company. And yet, they are usually not being treated like a real product being offered to paying customers. Maybe because they are not really paying for it, but still I believe it is in the company's interest to treat these products like they would be released to external paying customers.

Here are 3 common aspects where I found most internal products to be lacking:

1. Knowing your users is crucial ❗

In case of external products, there is no doubt that knowing the needs of these products' users and how they use the product is crucial. This impacts the decisions on how the product is developed, released, maintained but also how the company itself is being governed. Successful product => company growth, shitty product => company fail. Any amazing idea that is put into a product needs to be shaped by constant feedback from its users and from the reality of the context of the company behind it.

An internal platform that is completely detached from its users needs is a failed product. Developing and maintaining it, but also making it mandatory to use are a huge drain of energy and money.

2. Product managers shape the product(s) 💠

Product manager is a job position, in some places it is an actual job people do fulltime and in some companies it is an explicit role that people take. Regardless, they are the ones who drive the products further. They keep in touch with the users, they collect requirements from different sources and they distill all this in consistent product vision and roadmap.

In the same way this is an important thing to have for an external product, it should be a mandatory position or role for internal products. In the case of the internal products, this position many times doesn't exist and the role is usually shared, but not even in an explicit way. The result is a Frankenstein (no offense intended Frankie!) of a product that nobody knows where it started from and where is it really going.

3. Keep users in the loop ➿

Most successful products have a lot of content available about them. There is documentation, there are blog posts announcing new features and how to use them, local events bringing their users in a certain location together and even large conferences dedicated to one single product. The purpose is to have the users informed and feel part of the development of the product, but also have them interact with the product company and form a community.

Internal platform products might not have the same amount of users compared to external products or the same amount of people supporting them, but in large companies these numbers can be quite significant. Especially in the situations where a small number of people need to maintain and develop a platform that is used by hundreds of users, community is very important. And comunity is being built through multiple channels of communications with the users, be it blog posts, regular office hours where new features are introduced and questions are answered, workshops, events or seamless means for the community to contribute.

Conclusion

It's quite easy to discount internal users' time and make them use poorly developed products. Their time does not have an explicit price tag and they are also not bringing any explicit income by using these platforms. Because these are very hard to track or measure, then they are also easy to neglect. But the benefits of these platforms are there, if they are executed in a good way.

P.S. I wrote about some specific dysfunctions of a platform team some time ago here.