3 Tips for the Successful Internal Product Manager
To begin, what is an ‘internal product manager?’ An product manager is someone who manages the backlog of work for a team. They prioritize what needs to be done, gather the requirements, deeply understand the customer, and ensure the highest value things are being done. The internal product manager is specifically a PM who’s customers are within the company. It comes with a unique set of challenges and differences than the traditional PM that most literature and training focuses on, in that typically most material on PMs is focused on those with customers outside the company. I spend my 9 to 5 (or really 7 to 4) as a product manager inside a large organization for a tool we technically don’t need to sell because people don’t really have a choice in the matter of what to use. Management decides for them — for this aspect of your job, use this tool. So I don’t need to go out and evangelize my product, right? Well, yes and no, but I’ll save that for a different day. This article is going to focus on 3 tips for the internal product manager.
1. You still need to know your customer
Even though you don’t have to entice people to use your tool, you do still need to understand your users. Understand their day to day pain. You’ve been there before — management said you have to use some particular tool, and the tool might be OK, but how do you give the developers feedback? How do you let them know what’s not working? How do you let them know that you need feature X? As a PM, it’s on your shoulders to understand the communication networks in your organization, and understand where your users work. If you need to, setup a communication platform for them to ask questions and share thoughts about the problem you’re trying to help solve. There’s nothing more frustrating than having no way to provide a tool you have to use feedback.
2. You still need to advocate for your tool
I can’t tell you how many times I’ve seen an internal tool start off decent and have really great intentions, however features were added, bugs were fixed, but no one knew. People assumed that it was the same basic tool they saw day one. End users either reverted back to their old solution <ahem>excel</ahem>, or they conjured up a new one. If you see this happening, tap into how they are solving their problem and see if your tool already solves that problem and they don’t realize it (maybe they just need some training), or see how you can incorporate that solution into your tool. In any case, even though management has told the masses that your tool is the defacto for xyz task(s), that only buys you time to prove the tool is useful. If enough of the masses ditch and go elsewhere, you’re going to find yourself in shelfware land looking for another job.
3. Allow your customers to provide direction
This one is easy to lose sight of, especially if you are in a system that operates where direction is mostly (or completely) taken from upper management on what to do next. See tip 1. Understand your customer’s pains and talk with them. If there’s a way you can provide them a mechanism (could be via a part of your tool if it’s web based, or could be low fidelity like a dot voting board somewhere — which could be virtual too) to say what they would like to see prioritized next. This is feedback that you can also take into your stakeholder conversations and let your stakeholders know what the people want. It might not change the end game, but having that channel and knowledge can be priceless. It also shows your stakeholders that you’re trying to balance input from them (the stakeholders) and the end users.
