Back to resources

Building an Internal Product: How to Manage Internal Stakeholders

Managing Expectations

25 December, 2020

Sumitha Poornachandran

Sumitha Poornachandran

Engineering Leader at Ex-Lyft

Sumitha Poornachandran, a Senior Engineering Leader, discusses how she launched an internal product after successfully managing different internal stakeholders and their different sets of requirements.


I was tasked to lead a team that should build an internal product to be used by different stakeholders within our company. The stakeholders would typically have different interests and each of them would have a different set of requirements. Given that, how would we decide what product to build and ensure alignment around the bare minimum MVP?

Actions taken

I started off by meeting with all the stakeholders. After talking to them I realized that there was no common ask and that some of them would be upset no matter what we would build. Simply, it was not possible to support all stakeholders from the get-go, and I had to decide on:

  • a. Who would be the primary stakeholders for the product;
  • b. What should we build first.

We proposed who should be the primary stakeholders and got aligned with the leadership. Since the data science and operations team were making key business decisions out of this product, they should have an upper hand in deciding which features should be supported. Though the product was meant to be used company-wide, others were encouraged to share their requirements but we weren’t able to offer the same amount of support to them.

To decide what we should build first I ran a vision exercise with all stakeholders as an offsite and asked them to prioritize on top three initiatives we should focus on. Based on that we did a ranking and secured an alignment on what should be developed first. The product was essentially a reporting tool and minimal expectations people had included reporting, diagnosing, and some advanced analytics. Even without this product, most stakeholders were able to solve much of their reporting problems, but what we wanted to ensure was consistency across the company. For example, some stakeholders may have a bug in their query or would have a different source of truth and consequently, we would get different numbers. We wanted to standardize reporting and get the metrics definition correct.

Once we had the vision written down, the conversation was much easier. The vision exercise took three to four iterations and the final version was polished by my PM and me.

Some stakeholders wanted advanced functionality from the get-go, and I had to educate them that we would start with building a common foundation first and then develop some other functionalities they were looking for. Even though the foundation wouldn’t have an immediate impact it would be a prerequisite for building something that would comprehensively solve the problem and support advanced use cases.

To best understand all stakeholders’ needs we did site-sharing with them for a week just observing their day-to-day work and their regular responsibilities -- how exactly they would be using the product and what for, what other tools they would be using, etc. We collected those data points as well which helped us empathize with what stakeholders wanted with the product.

Once we ensured alignment with all stakeholders we built a product through an iterative process. We first built a bare minimum MVP that would give an idea to stakeholders what the product would be about -- what would be the look and feel of the product, what would be the latency, and whether it would be useful to them. When they agreed, we built a full-blown version.

Lessons learned

  • You should create an opportunity for every stakeholder to speak up about what they wanted out of the product. Every perspective should be heard even though you won't be able to build a product -- at least from the get-go -- that would meet all of their requirements.
  • Fail fast. Don’t invest too much in a product until you get validation from stakeholders. Have regular cadence check-ups with stakeholders to demo what you have built. Frequent checkups are always better than quarterly updates and building a product through small steps and continual iterations.

Discover Plato

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

Related stories

Scaling a Team in Two Parts: The Product and Manager

2 August

Viswa Mani Kiran Peddinti, Sr Engineering Manager at Instacart, walks through his experience scaling a team, product and his skills as a leader.

Managing Expectations
Scaling Team
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

How to Organize, Manage, and Grow Your Team

12 July

Vineet Puranik, Senior Engineering Manager at DocuSign, discusses the impact of roadmaps, organization, and proper management for your teams to procure growth.

Managing Expectations
Vineet Puranik

Vineet Puranik

Senior Engineering Manager at DocuSign

How to Navigate Your Manager Role at a New Company

1 July

Saikrishna Desaraju, Engineering Manager at Marks & Spencer, draws from his personal experience to advise new managers on thriving in their roles.

Managing Up
Managing Expectations
New Manager Of Manager
Changing Company
Saikrishna Desaraju

Saikrishna Desaraju

Engineering Manager at Marks and Spencer

How Product Management Chose Me

23 June

My accidental journey into product management

Personal Growth
New PM
Career Path
Michael Castro

Michael Castro

Sr. Manager, Product Management at Capital One

How Product Marketing Can (and Should) Help Product Development

20 June

Pavel Safarik, Head of Product at ROI Hunter, discusses the frequently overlooked role of product marketing in getting high user adoption rates for your product.

Goal Setting
Product Team
Different Skillsets
Cross-Functional Collaboration
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter