Back to resources

Building an Internal Product: How to Manage Internal Stakeholders

Managing Expectations
Product
Collaboration

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.

Problem

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

Building and Maintaining Company Culture: How to Scale Teams Accordingly

26 May

Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.

Mission / Vision / Charter
Scaling Team
Building A Team
Company Culture
Collaboration
Onboarding
Sharing The Vision
Elwin Lau

Elwin Lau

Director of Software at JANA Corporation

Building and Maintaining Company Culture: How to Scale Teams Accordingly

26 May

Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.

Mission / Vision / Charter
Scaling Team
Building A Team
Company Culture
Collaboration
Onboarding
Sharing The Vision
Elwin Lau

Elwin Lau

Director of Software at JANA Corporation

The Art of Asking Why: Narrowing the Gap Between Customers and Users

24 May

Jord Sips, Senior Product Manager at Mews, shares his expertise on a common challenge for product managers – finding root causes and solutions.

Customers
Innovation / Experiment
Product
Personal Growth
Leadership
Stakeholders
Users
Jord Sips

Jord Sips

Senior Product Manager at Mews

Managing Different Time Zones: Inclusive Collaboration Methods

19 May

Jonathan Belcher, Engineering Manager at Curative, shares an unknown side of synchronous communication tools and advises managers on how to handle a team that’s spread across the globe.

Remote
Internal Communication
Collaboration
Cross-Functional Collaboration
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Creating a Company Culture That Balances Helpfulness and Productivity

16 May

Alexis Philippe, Vice President, Product & Engineering at Amilla, describes his one simple rule for creating a culture of helpfulness that doesn't disrupt productivity.

Mission / Vision / Charter
Company Culture
Collaboration
Cross-Functional Collaboration
Alexis Philippe

Alexis Philippe

Vice President, Product & Engineering at Amilla

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.