Stakeholder management in a large-scale product build
By: Shahneela Shaukat
Tags: Product Design, UX, Product Management, Design Process, User Experience

1. Finding the main point of contact

Every project has a client-side lead, or a main point of contact, for you to refer back to. It can be anyone from the marketing manager to the product owner.

My first step was to find the main point-of-contact and establish a good relationship with them. This was relatively simple in this project, as we had an established relationship with our client, and already had a point-of-contact.

2. Understanding overall emotions

Large product builds and new product launches in any organisation come with charged emotions on various levels. You can have some departments that are hugely excited for this new product, while others feel uneasy, abandoned, or confused. Even within departments, different people have different reservations.

I set out to understand the overall emotions related to the project, so that I could have a strong foothold before delving into the stakeholder interviews.

I talked to my main point-of-contact to get an understanding of how all stakeholders and departments feel. My main takeaway was that it was important for all stakeholders to be heard, and for their needs to be mapped out and implemented within the build.

3. Planning stakeholder interviews

Stakeholder interviews allow us to systematically listen to various stakeholders, and map out their needs. This is especially crucial when there is a large number of stakeholders involved in a complex build. We want to make sure that we capture all the insights we need before moving to the design phases. In many ways, stakeholders are a type of user, and we need to advocate for their needs.

Planning was key, as my interviews would take up an approximate 30–45 minutes of each person’s time, and I wanted to make sure that I get to capture the insights needed. I was also to conduct group interviews consisting of 3–4 different stakeholders from each department.

I looked over the documentation of the product, and researched each department’s involvement in the project. I set aside an entire week to conduct stakeholder interviews, in which I was onsite at the organisation’s headquarters, interviewing each department. Our client was kind enough to provide us with our own space to conduct all the research and meetings throughout the length of the project.

I used the following steps to plan the stakeholder interviews:

Research each department and their involvement in the project Research each department’s current manual process (which would be affected by the product build’s new automated process) Draft interview questions to ask each department. Then refine the draft questions into finalised versions Send interview questions for approval to my client point-of-contact Write out a script for each of the interviews Warmly introduce myself via email to all the people I would be interviewing Practice interview questions and recording to make sure everything is in order and the script has a logical flow

4. Conducting stakeholder interviews

Before starting each interview, I asked for the consent of each participant to record the interviews (assuring them that only I would be listening back to the recordings to compile the findings).

I followed the script to make sure that everything is covered, but also kept the structure relaxed. The stakeholders brought up many great insights when the interview structure was more flexible.

The interviews ended up being more like two-way conversations, which was the best possible outcome, because this meant that we were able to establish repertoire and trust in the product build during the interview process.

Some interviews also doubled-up as mediating sessions. This was because I inevitably ended up being the main external point of contact for the stakeholders to address questions to. Hence, it was important for me to know the project inside-out. I addressed their questions at the end of each interview, which established confidence in the product build.

Presenting stakeholder findings

The mode of presenting stakeholder findings depends on the project and situation. It can be anything from a detailed report to a short group debriefing.

Remember that stakeholders are often time-stressed people. The findings should be presented succinctly, and with actionable items kept in mind. Deliver what is most important to your stakeholders.

For this project, the findings were delivered in two main methods: a group presentation involving all the stakeholders, and a detailed report to be sent to everyone involved.

The presentation and report were mini UX projects in and of themselves. I really had to hone in on what data and findings were crucial, and how to present them in a way that was intuitive and actionable to the stakeholders.

I presented the information in 4 main areas that were important to the stakeholders:

Concerns: what concerns had been expressed

Emotions: predominant emotions expressed

Solutions: how can we solve the concerns that have arisen

Opportunities: exciting new opportunities that have been identified

The stakeholder interview findings showed that similar concerns and insights were common across various departments, hence I made the decision to combine the data from different departments into one. This helped ease many of the concerns of the stakeholders, by showing that everyone was actually thinking among similar lines.