As a product owner of an internal development tool part of my job was to talk to developers to find out how our tool could help them in their day-to-day work. To identify developers’ needs and provide solutions to them by means of our tool. And we were doing pretty well, I must say.
Our tool was only one of many good internal tools. But a collection of good internal tools does not necessarily provide a good overall end to end solution, so the decision was taken to offer our tools as part of an internal platform.
A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced co-ordination.
What I Talk About When I Talk About Platforms, Evan Bottcher
Becoming part of a platform meant that our tool was now only a piece of the puzzle. We no longer had to cater to the needs of our own tool but also to those of the platform. We needed to adjust the way we asked users what they needed but also how we communicated our features to them. Here are some actions I took to make the transition.
Understanding the big picture – ALL the parts
I had some knowledge of the tools that directly integrated with our own but there were so many questions to ask now in the context of the platform. What needs were they serving and more importantly what pain points did they address? Could it be that we were targeting partially the same? Was there something that our too could offer to make the tasks of their users easier? And what about the tools we didn’t integrate with? Were there opportunities to explore?
Besides the individual parts, it was good to know what the purpose of the platform was, as a whole. The reasons that brought the need for a platform in the first place were a good starting point. The direction that the platform was going towards was also something that helped me to consider my options for charting a new course.
Distributing existing needs
Once I had a better understanding of the needs that the platform addressed, I started comparing them to ones that our tool served. Was there no, some, or lots of overlapping?
If the needs did not overlap, I guess a good discussion would be in order whether it made sense for our tool to be part of the platform. We were on the other end of the spectrum were the majority of the needs our tool fulfilled would also fulfil platform needs. We were indeed at the right place.
Documenting the standalone part vs the integrated part
Even if the needs we fulfilled were highly aligned with those of the platform, there was still some standalone functionality our tool provided. We wanted to tell our users that if you used our tool as part of the platform you would get many things out of the box. But even if you didn’t use the entire platform we wanted to provide guidance how to make use of our tool.
How to get our new feature
> If you use the entire platform, you are all set!
> If you are using feature X of the platform then you only need to do Y.
> If you are not using the platform you need to do X and Y.
There were some benefits of writing our documentation in such a cascading manner. To our users it brought clarity in what they had to do depending on their starting point. To the platform it brought more visibility through our tool. And to us less support questions, as the users could easily identify the part they really needed help for.
With this activities we started going from an “internal tool” mentality to that of “part of an internal platform” one. I started changing my discussions with our users, focusing not only on what is relevant for our tool but also what is usefull to serve the entire platform through our tool. The road is long and winding but at least we are on our way.
More Questions Than Answers 
One thought on “From Internal Tools to Internal Platforms: Getting Started”