Lessons learned from managing internal products

Lessons learned from managing internal products

BY Ahmed Sulaiman ON JUNE 3, 2021

Working on an internal product isn’t different from any other publicly available product. You still have to understand the problem, clearly communicate the value, and make sure people get things done. The only difference is that your users also happen to be your teammates.

Early last year, the company I co-founded got acquired by Abstract. We joined the team to lead an internal product called Abstract SDK. Simply put, SDK is a code library that gives engineers the necessary building blocks for implementing product experience. Engineers at Abstract were using SDK to build certain parts of the application. Additionally, because this library is also open-source, anybody from the community could use it to extend the product’s functionality. So, technically, SDK was an internal product with external use-cases.

While leading a product on such an intersection, I’ve noticed a few core themes that propelled it forward. Let’s dive in and explore them in details with examples:

• Make sure you understand people’s needs
• Communicate the value and shared context
• Help people make progress

Make sure you understand people’s needs

Internal or External, the product should solve a problem. As with any other product work, you have to understand the context first. What is the job that people are hiring an internal product for?

Your goal here is to extract as much context as possible. Different teams would care about various things. So it’s vital to analyze personas early on.

Discover more insights on user personas 

For example, at SDK, the support team wanted to know how they can help customers with SDK-related requests. Meanwhile, the sales team wanted to understand who among customers might be interested in using the SDK. So they can offer it during the pitch.

As a Product Manager building an internal product, you have certain advantages:

• Your “customers” are only one Slack message away.
• You know the organization structure and which team is in charge of what.
• You can see people’s schedules.

Here are a few ways how you can utilize these advantages.

Conduct a regular sync meeting with team leads

The recurring conversation with team leads has proven to be extremely useful for understanding the teams’ targets. Together you can construct an overall team’s problem-stack. Doing so shows all the challenges the team is facing, sorted by importance. It would help you estimate how valuable an internal product is for that team compared to other challenges.

Make sure internal product aligns with company objectives

An internal product should be tight to the overall company objective. Without this relationship defined and communicated, there is no sense to push such a product internally or externally.

A clear objective connected to the company’s mission is the best way to align everyone on the journey. Why else would team-leads spend their precious time talking to you if not to move the company objective forward?

For example, the high-level company objective might be to improve customer support experience. In the case of SDK, it would mean improving the support experience for people with SDK-related issues. You might want to prepare a playbook with common SDK-related problems or enrich the SDK documentation with relevant guides and tutorials. Listen to this podcast with Emily Patterson to discover more insights on managing internal tools.

Communicate the value and shared context

After collecting initial context from team leads, it’s time to align everyone around the shared understanding of internal product capabilities and values.

This part is especially relevant for a technical product like SDK. It might not be used directly by everyone in the company, but everyone needs to understand what it is and how it could be useful for them. It also makes an overall environment more inclusive. With the same context, team members can articulate ideas and suggestions from their unique perspectives.

Setup regular workshops with each team

You can set up occasional workshops and Q&A sessions where people could ask any question about the internal product. The goal here is to educate your teammates about the capabilities and make sure everyone understands what the product does.

For the SDK, it looked this way: We started with a short presentation of what the SDK is. We explained the product with simple language tailored for each team. Then we walked through the “jobs” of SDK, describing each use-case separately. The rest of the meeting was an open conversation with questions.

Keep people informed about the progress

Make sure you communicate continuously how the product changes over time. Try to mention how the change benefits different stakeholders and why they should care. Just like external products have public Release Notes, the internal product needs to have a private alternative tailored for different teams.

During the time at Abstract, I was sending regular release notes for SDK every two weeks. These notes included:

• What has changed in the last two weeks
• What our team is planning to do during the next two weeks
• How these recent changes impact other teams

This way, I could communicate our plans and challenges. Additionally, these documents became a source of truth for everything SDK-related. So I often refer them to bring new people in the team up to speed.

Make the internal product a first-class citizen

In a 60+ people team, people care about different parts of the product. It’s still important to make sure the internal product stays on top of mind for directly involved teams.

In our case, SDK was closely related to API requests developed by a backend team. It means that every time there is a new API request, there should be a reflective change in the SDK. It was critical to set up a direct communication channel between our teams—so everyone would know about updates on both ends. We ended up setting a Slack + GitHub integration to keep teams aligned. The Slack bot has subscribed to the GitHub repository’s RSS feed. The new entry in the RSS feed would trigger the notification in Slack.

Help people make progress

At this point, people should have a shared understanding of the product and how it helps them. If you set up all the systems in place (well-written documentation, internal FAQ, release notes, etc.) the team should be well-positioned for success. The only thing left is to maintain this direction.

Close feedback loops with internal stakeholders

With a shared understanding of the product, people would be more willing to contribute and send specific requests. Make sure you have a system in place to handle every one of them. More importantly, make sure you get back to those who requested a feature or reported a bug with clear next steps. Answering people’s requests would help build the relationship even further.

The closing feedback loop concept (Image: Ahmed Sulaiman)

Wrapping Up

Maintaining and growing an internal product isn’t different from building a regular product for external customers. To summarise, it’s a continuous process where you need to:

• Constantly watch how the team’s needs evolve. What are their objectives and motivations?
• Communicate and educate team members. Stay on top of the new perspective each of them brings.
• Support your teammates while they use the product internally. Respond to feature requests and bug reports.