Back to resources

Building Internal Tools and Balancing Different Stakeholders’ Requirements

Managing Expectations
Collaboration
Team Processes
Prioritization

28 December, 2020

Frances Li
Frances Li

Principal Product Manager at Adobe

Frances Li, Lead Product Manager at Carta, describes how she created a unique framework that helps her balance different stakeholders’ requirements when building internal tools.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Myth Busting

10 December

Supporting principles on why being data led (not driven) helps with the story telling.

Alignment
Managing Expectations
Building A Team
Leadership
Collaboration
Productivity
Feedback
Psychological Safety
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

The Not-So-Easy Guide on How to grow and develop an Amazing A-Team

5 December

Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.

Alignment
Building A Team
Company Culture
Sharing The Vision
Embracing Failures
Team Processes
Jaroslav Pantsjoha

Jaroslav Pantsjoha

Google Cloud Practice lead at Contino

The Growth Mindset in Modern Product Engineering

28 November

The impact you can have with a Growth Mindset' and the factors involved in driving orchestrated change.

Building A Team
Leadership
Collaboration
Feedback
Ownership
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

How to measure Engineering Productivity?

30 November

When you grow fast, its normal to focus on Value delivery aka "Feature Releases". Too many releases too soon will inevitably lead to piling tech debts and before you know, inefficiencies creep in, performances goes down, and ultimately any new release takes too long. Sounds familiar? Then read on..

Productivity
Prioritization
Performance
Ramkumar Sundarakalatharan

Ramkumar Sundarakalatharan

VP - Engineering at ITILITE Technologies

How to improve engagement and retention in remote engineering teams?

25 October

Mrunal Kapade, an Engineering leader, based in Silicon Valley, shares tips that helped reduce attrition in the remote engineering teams while leading multiple teams from startups to Fortune 500 companies.

Remote
Company Culture
Collaboration
Motivation
Team Processes
Mrunal Kapade

Mrunal Kapade

Director of Engineering at Inspire Energy