Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

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

Specialization vs. Wearing Many Hats

23 November

William Bajzek, Director of Engineering at Sapphire Digital, compares and contrasts a team structure that utilized siloed skill sets and one where everybody’s duties overlap at the edges.

Internal Communication
Collaboration
William Bajzek

William Bajzek

Director of Engineering at Sapphire Digital

Why Overloading Product Teams Never Work

23 November

Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he identified the symptoms of his overworked product team and worked towards defining conflicting priorities.

Managing Expectations
Product Team
Deadlines
Stakeholders
Adi Purwanto Sujarwadi

Adi Purwanto Sujarwadi

VP of Product at Evermos

How to Pivot a Product Idea at the Right Time

23 November

Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he diligently managed a product in one of the biggest eCommerce companies by being an individual contributor.

Innovation / Experiment
Product Team
Product
Embracing Failures
Adi Purwanto Sujarwadi

Adi Purwanto Sujarwadi

VP of Product at Evermos

Mergers and Acquisitions: Collaboration tools hold a key to bringing cultures together

23 November

Neelima Annam, Sr Director Information Technology at Outmatch, shares how something as minor as collaboration tools can be a BIG issue during mergers and acquisitions.

Acquisition / Integration
Internal Communication
Collaboration
Neelima Annam

Neelima Annam

Sr. Director Information Technology at Outmatch HCM

Overcoming imposter syndrome through focusing on your strengths

19 November

James Engelbert, Head of Product at BT, recalls when he had to battle imposter syndrome when managing a new team.

Product Team
Product
Health / Stress / Burn-Out
James Engelbert

James Engelbert

Head of Product at BT

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.