In the fall of 2021, I joined Schibsted as a product manager for the team responsible for the shared Web platform for our multiple Nordics news brands.

The stack served (mainly) articles and (sometimes) front-end and collection pages to the millions of users of four national brands; nine local, regional, and special brands; and multiple niche sites.

And, guess what? The platform is open for more than 150 developers to collaborate on. Let that sink in!

At the start, it was confusing to me as to where to start. How do I know what the problems at hand are? Should I grab the bull by its horns or its tail? I experimented and learned, and now I wholeheartedly endorse and uphold the following strategies.

Look beyond the obvious stakeholders

Like a typical product manager, I started with understanding my target audience.

I did dozens of 101s, starting with my own tech team and engineering partner. Then I headed to my obvious stakeholders: product directors and product managers in the stakeholder teams.

It was like basic maths: 1+1=2. But, did it?

While I gathered a lot of insights, I still felt there were some pieces missing from the puzzle. Until one day, when it struck me that I would get the real meat from the developers using and contributing to the platform and the ones they share their concerns with — their tech leads and engineering managers.

And, voila! I struck gold!

Play the “I am new card” — unapologetically!

Being a new team member, I had an ace card. And, it’s called “I am new here.” In an organisation with a complex matrix, you can perhaps use it for years. I used it unapologetically, even to ask questions that otherwise would have been labelled blunt or political. But, how would a new person know that?

Create a structure around collaboration

All those 101s I invested in the first couple of months gave me gems of information about my stakeholder teams and the dynamics of our complex matrix. And, I did not want to just let it sit in my notes. I created an excel sheet and mapped out the common denominators. I then built my insights on what is important to which stakeholders.

Considering I had more than 13 stakeholder teams to collaborate with, I could not have collaborated with everyone at the same time, so I had to prioritise. I created my dart board of prioritised focus: I began in the centre and, with time, expanded my focus toward the outer layers based on the level at which each brand team used the Web platform.

One meeting is often not enough

When I joined Schibsted, my team at the time was suffering from the lack of product management. And, among other problems to be addressed, collaboration topped my chart.

This is where I pulled out my Excel sheet together with my focus dart board. I scheduled regular sync meetings with the identified stakeholders, both product managers and engineering managers. These syncs not only helped me build a rapport with my stakeholders, but also gain insight into where the problems existed. It’s a no-brainer that any product manager will take that into account when prioritising work for their teams.

Share updates regularly

I strongly believe an excellent product that is poorly promoted fails to reach its true potential.

As a product manager for internal developer platforms, one should be strong at promoting to their users and stakeholders. Promotion doesn’t translate to sales in this case.

My focus was to reach out to all the developers using the platform and make them feel part of the ecosystem, especially because not all users engaged with the platform at the same level and at the same frequency. They often struggled with keeping up with the changes.

Our open Slack channel was my best tool. It was the key ecosystem for the platform users. They were quite active on it and would turn to it for all their questions. So, I was confident they would see what I posted there.

I made sure to post weekly updates on the channel with a summary of what has happened on the platform each week. The users not only appreciated the flow of information, they engaged in asking questions about why, what, and when. My two cents is that weekly updates are so worth it.

Repeat the information mindfully

Repetition is not redundancy; it’s the rhythm that harmonises understanding and orchestrates collaboration. But, repetition for the sake of it can be overwhelming and fail its purpose.

What we need to do is repeat the information to the right audience in the right language at the right time. In the case of an internal developer platform, what this ensures is that eventually users have the same information, use the same language as you, and indirectly become ambassadors.

I picked one problem at a time — the most critical one — and addressed it in every form of communication until users and stakeholders started sharing the suggested solution with each other without my or my own tech team’s support. I enjoyed the ripple effect.

Improvise on collaboration as many times as needed

The best part of working on an internal developer platform is being able to reach out to users several times. It’s free and much appreciated.

To ensure we reach out to even those users who are not Slack-friendly or shy away from asking questions in writing, we started a monthly Q & A session where anyone could ask us anything about the platform.

On re-evaluation, we figured the platform is so complex and huge that it is perhaps hard to even ask specific questions. So, we pivoted and turned it into monthly platform demos to showcase the latest and the greatest. The result? Higher engagement!

Build your allies

Make four people sit together and you will get eight different opinions. Imagine how it is for a technically complex platform used and contributed to by more than 150 users.

While the users could be critical toward the platform, the platform team had built such a rapport that even the harshest criticisers of the platform loved the team. Why? Together as a team we were very clear that we needed to solve user problems and in all our communication for users and stakeholders, we authentically shared that vision.

On top of that, we were attentive on the Slack support channel, ensuring no question or request for help goes unaddressed. This gave us allies — quite strong ones!

To conclude, collaboration strategies can and should vary with organisations and the nature of the product you are handling. However, what stays the same is the underlying principles of communication, empathy, and authenticity.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .