Five questions to improve your pre-project stakeholder meetings

At the outset of one of my first projects here at Lightricks, I remember asking questions about research goals, expectations, and potential impact. I had the opportunity to set expectations and make certain clarifications. Still, at some point, while knee-deep in a diary study analysis and halfway through a long set of interviews, I realized that my stakeholders and I weren’t truly aligned.

I salvaged that project and produced insights that stakeholders used, but it was needlessly stressful. In my postmortem, I traced the difficulties to that initial stakeholder meeting. I asked the prescribed questions and followed up with a written research plan. But I didn’t dig deeply enough. We each had an understanding that was too general. I’d failed to understand the nuances of what the stakeholder was trying to accomplish and why.  

Over time, I learned that knowing something like: “I suspect there is an issue with this flow, and I want to identify the top UX issues so that we can make iterations and improve the export rate” is just the beginning of understanding stakeholder needs. For example, maybe the stakeholder’s manager is already married to a specific solution, and the goal isn’t as open-ended as it sounds. Or perhaps someone on their team has been advocating for a different solution based on their work, and no one is listening.

Based on my early experiences, I developed the following list of more nuanced questions to ask stakeholders in our initial meetings before we kick off a new project. I’ve found that these guiding questions make for a more detailed conversation that gives all of the necessary context.

What problems are you trying to solve?

While there is nothing wrong with asking a stakeholder what their goal for the research is, I find that product people usually think about problems to solve rather than overall goals. Research project goals are important, but problems give more context. Here’s an example:

Goals: I want to get some user insights to prioritize these two features for our Q3 roadmap.

Problems:  I need to prioritize these two features for our roadmap, and there’s disagreement among our team. We tested an MVP of X feature, and some of the team think it failed because it didn’t meet a user need in general. Others believe we failed on execution. Also, the engineers aren’t optimistic about feature Y in terms of building it on a timeline that the VP of Product will align with. 

Looking at the problem space from a stakeholder perspective provides a lot more information. It helps me understand the constraints we’ll operate under in terms of delivering insights that the team can use. For example, from that reply, I already know that it’ll probably be worth my time to speak with other relevant people on their team to understand the conflicting hypotheses more in-depth. 

Particularly in startups, stakeholders operate at high speed with challenges related to users, teams, politics, and more. Though one definitely could have gotten all of these details by talking about goals, I find that asking about all the problems surrounding a research goal, instead of assuming they’ll come up in conversation, gives me a lot more necessary information from the get-go.

What are the expectations of you in terms of this feature or exploratory research? What is your manager asking of you?

While it doesn’t always feel super easy to ask a stakeholder what their manager is demanding of them, I’ve learned that it’s worth the 30 seconds of discomfort. Demands on a stakeholder are in the category I call silent constraints. Almost anyone you work with on the Product team has a boss. That boss has an opinion, a complaint, or an unfaltering belief in something.

Here’s an example I got recently from a Product Manager: [my boss] thinks the export rate should be significantly better if this feature really gives the user value. I’m under pressure to improve it by the end of the quarter while still keeping up with everything else we’ve planned to build and release.

From that context, I understood that our research needs to deliver insights and recommendations that can be implemented quickly and easily, alongside other initiatives and likely with limited resources. If we deliver complex recommendations that require multiple quarters to plan and execute, that Product Manager won’t be answering the demands placed on him by his manager. In my experience, some stakeholders readily offer this type of context when asked about project goals—but many stakeholders need to be asked directly.

Who on the team identifies with your hypotheses, and who sees it differently?

Often, I’ll meet with a VP of Product or a Product Manager, and I won’t even have to ask for their hypotheses about research outcomes. They’re usually eager to validate their assumptions and want to be doubly sure that the questions we’re asking give their hypotheses a chance to be proven right (though we all know that talking through what we’ll do if their hypotheses are invalidated is a huge part of initial alignment).  

When I ask about the hypotheses within a team, things get a lot more interesting. A PM is likely working with designers and engineers, for example. It’s unlikely all of their inclinations and beliefs are the same. I find asking for the varying hypotheses within a team helps me refine the research scope and craft a plan that addresses all of the outstanding questions to assist decision-making later on. Asking this question is essentially an acknowledgement that decision-making is complex within teams, and what you’re hearing from the main stakeholder may not always be the full story.

An additional tip here: depending on how much the hypotheses vary within a team, you may want to consider meeting with some of the secondary stakeholders as well.

What deliverables will be most helpful for you and your team to work with?  

On our team, we’ve found a groove that works for us when presenting research results: we present the results to the main stakeholders in a meeting and then send out the slides to all relevant stakeholders at the company. When relevant, the slides include insights, recommendations, and some raw data, such as interview clips or dashboards. Overall, we received positive feedback on this approach both directly and indirectly.  

But as I got to know the various stakeholders and different teams at Lightricks, I realized that even with our standard format, some teams are more likely to absorb what we give them or utilize our recommendations if we provide additional deliverables. For example, one team prefers to have its designers review the raw qualitative data and then, in addition to our usual stakeholder presentation, schedule a group discussion where everyone has a chance to voice their observations and talk through all of the relevant points together.  

I’ve also heard from a fellow researcher at another company that her team strongly prefers to get video summaries of research results rather than hosting a meeting. They like to watch and absorb the information at their own pace and then come together for a discussion afterwards.

Primarily, this is a matter of finding a routine but also being willing to add additional practices based on how stakeholders work and their preferences. After working with different stakeholders for a year, I don’t always have to explicitly ask this question because I’ve gotten to know the teams. But at the outset, inquiring about deliverables at the beginning of a project helped us give deliverables that had maximum impact.

By what date will these insights be too late for you to use in your decision-making process? 

Most stakeholders value speed and efficiency and generally want the results as soon as possible. I found myself frustrated at the beginning of my journey as a researcher because everyone “needed” results by next week. I feared I’d sacrifice quality with speed, which made planning a research roadmap difficult and put me in a situation where I couldn’t plan more than a couple of weeks in advance.

I learned that tweaking the question about the timeline created a more workable situation, allowing me time to do great research and planning in advance. Instead of asking, “What’s your timeline?” or “when do you need results?” I ask stakeholders for the date by which these insights will be too late to use in their decision-making processes.

Asking this way helps initiate a conversation in which stakeholders think through the timeline instead of the go-to ASAP. Recently, a stakeholder told me they had an urgent project and wanted to know if we could get preliminary results by the end of the following week. After asking this amended question, the stakeholder realized that actually, they wouldn’t need the insights for decision-making until a month from now when they’re finalizing a certain aspect of their roadmap.

Their initial urgency came from feeling stressed about the upcoming process rather than a pressing need for insights next week. Now, we’ll be able to deliver quality insights by doing thorough research and not trampling over other projects that are in the works.

Overall, there is a lot of variation between stakeholders. Still, a big and important lesson I’ve learned is to constantly evaluate the effectiveness of my initial meetings with stakeholders. Though these meetings become routine for the average researcher, I always find small tweaks to the process that can increase our chances for success and impact later on.

Written by Cori Widen, User Research Team Lead, Lightricks. Cori leads the UX Research team at Lightricks.  She had worked in the tech industry for 10 years in various product marketing roles before honing in on her passion for understanding the user and transitioning to research. Outside work, Cori is busy reading books of all kinds, hanging out with her husband and two kids, and traveling.