Managing Internal Stakeholders as a Product Manager

If you are a Product Manager and have worked at least at one startup, then I’m certain you are familiar with the concept of resource constraints, and the simple fact that there’s never enough time or resources (engineers, designers, testers, etc.) to get everything done on time.

In my experience, this is also an exponential problem. That being, no matter how many resources and/or time you have at your disposal, there’s always more to be done in less time than the resources you have available.

One thing that can exacerbate this problem is when you have multiple internal stakeholders with distinct and competing priorities all vying for these limited resources.

In any given day you may get a request from the Director of Marketing to add a new product to your company’s portfolio so they can issue a press release demonstrating how you have surpassed your competitors services, while the VP of Sales asks you for a new “simple feature” so he/she can close a deal with a possible customer while your Customer Success Manager begs you to fix N number of bugs so his call/email volume goes down. All of these requests are coming at you like a hail storm and in addition to these requests, you have the ones that are also coming from your users.

And yet, your resources remain the same.

This can add up to a huge amount of pressure and lead to burn out if you are not careful and able to find a few strategies to help you cope and manage the load.

As a Product Manager, one of my main objectives is to identify what’s the most valuable things that my team (Product, Engineering, Sales, Marketing, Support, QA, Design, etc.) and me can be working at any given time, where “most valuable thing” is that which, by delivering value to our users it also helps deliver value back to the business, and where value is measured by how our activities help the company achieve its goals and move towards its vision (it’s important to be very clear and aware about this value-deliver-cycle [company->users->company], as it’s possible to deliver value to users yet never achieving the company’s goals and vision).

Another focus of mine is to facilitate an understanding of how resource constraints impact the decisions that we make. As much as I do understand each unit’s priorities and that to that unit that’s the most important thing we could be doing, in reality, the most important thing that we could and should be doing is that which brings about the successful implementation of the value-delivery-cycle described above.

My goal is to bring forward an awareness that we are all one team; that we will all fail or succeed together — and that the most important thing is not what’s at the top of each unit’s list — rather what’s at the top the business’ list.

One technique I’ve been using for the last couple of years at various startups and with great success is to facilitate a weekly or bi-monthly (depending on your development cycle cadence) meeting with the various internal stakeholders’ units leads where each department gets to present their top five product priorities. One at a time, each team lead goes around the room describing each product priority and what value it will provide to their respective units.

Once all the departments have presented their various lists, they will review them one more time, but this time, they will have to describe how each item relates to the currently stated company goals and vision — and what value they will unlock for the users while in return, how it will contribute to the business’ objectives.

The goal is not to impose one department’s product needs over another one, but rather, by working as one team with one common goal (business success); prioritize the product work that needs to be done, given the available resources that will deliver the most benefit in the value-delivery-cycle.

The outcome of this exercise is a prioritized list of “business value” for Product to take into account when reviewing their roadmap and backlogs against all the other work that needs to be done — whether it’s users’ request, bug fixes, enhancements to current functionality, etc.

Well executed, this simple process will align the various units around the company’s goals and vision, while maximizing value delivered to the users and the business, improving resources utilization, and also boosting and strengthening a sense of team and dependency on each and every person in the company.

NOTE 1: Each time the internal stakeholders meet, they should start by reviewing each of the top five priorities identified in the previous meeting and evaluate whether or not they are still current and valid. If they are, then any new item presented should be evaluated against these. Any top five priority that’s no longer valid should be removed from the list or reprioritized as needed. It’s ok to keep the list the same or change it completely each meeting. The goal should always to have the five most important things that can be done for the user and the business.

NOTE 2: The priorities list can contain more than five items (similar to a backlog), as sometimes it’s good to keep a long list of “kind of important” items warm in case priorities change. But Product should, for sake of managing load, only take the top five into account when reviewing all other priorities (user’s ask, roadmap, and backlog).

About author

Diego Schmunis is a Product leader with hands-on, end-to-end experience guiding organizations with product vision, strategy, and leadership. He has a keen intuition for product design and usability that fulfills the job-to-be-done. Diego is skilled in product lifecycle, MVPs, user research, problem-product-business model/market fit and leading lean/agile cross-functional teams.