Building an Internal Product: How to Manage Internal Stakeholders

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.