Building Internal Tools and Balancing Different Stakeholders’ Requirements

Problem

I work at a team named Internal Tools and the product that I own is tailored to meet the requirements of internal business units, including Marketing, Sales, Finance, Support, Implementation, etc. The main challenge we face as a team is how to align all these different internal business units and prioritize their different requirements. Each of those stakeholders has different goals. For example, Finance would seek to maximize the revenue while Support would look to decrease the number of tech support tickets. In addition to alignment, we would make sure to maintain a good relationship with all of them and explain our choices and tradeoffs.

Actions taken

As a product manager, the first thing I would do would be to establish relationships. We are all about understanding our users and their needs and in this particular case, our users are different internal business units. To be able to solve their problems, I would have to understand how Finance is operating or how Support is dealing with our customers and how all of that ties into the work that we as a team does. Rather than talking with upper management, I would be sitting with rank-and-file people on the finance team, asking them to show me how they would do account reconciliation or how Support does tickets.

For each set of requirements I would receive, I would do an in-depth analysis of the impact and compare it against the company’s goals. For example, for Finance, it is always about revenue and together with the finance team, I would analyze the revenue impact.

I created a framework to assign the impact in terms of revenue, cost, user experience, scalability, and compliance for each of the requirements. The framework is designed as a scorecard and it helps stakeholders understand how I evaluate their projects and create the list of priorities.

I would have regular meetings with all stakeholders going through the framework and encouraging people to share their opinion. While they could (dis)agree with the vaguely described impact, they wouldn’t be able to challenge a precise and concrete reference for every score. For example, people may question why the revenue impact score is 5, but since I already defined 5 as “bringing 3+ million,” it would be hard to question something that could be empirically validated.

Getting people together and have them look at the numbers would curtail an endless debate. Data is always the most convenient and persuasive way to secure alignment and meetings become much easier because we can all agree about the data.

Lessons learned

• Be precise. When dealing with different stakeholders, define things in advance and prevent long arguments about things that shouldn’t be arguable. Also, be detailed in your analysis and how did you get a specific number. For example, you can explain how you calculated cost saving by showcasing how many agents for how many hours were doing something manually and that would justify why it should be automated. It is much easier to defend your proposal when you have a detailed analysis to back up your position.
• Every quarter we would have planning sessions with all stakeholders. Having them sit together in the same room and hear other people making their case would help them better understand what other stakeholders are doing and why their requirements are important. Our meetings evolved from planning sessions into collaboration meetings where we would discuss their projects for the next quarter. That discussion is crucial for securing alignment because they should be aware of how their different goals can result in misalignment.