Why you should talk with stakeholders before talking with customers

Preparing for customer interviews in a way that fosters trust among stakeholders

Riikka Iivanainen
Bootcamp
Published in
6 min readJun 19, 2023

I was once asked in a job interview how I prepare for customer and user interviews. I said I book the conversations well in advance, do some background research, craft the interview guide carefully but with room for improvisation, write and practice my “lines” for the introduction, send reminders, and take a few deep breaths just before I begin.

These are all sensible things to do. But if I was asked this question today, I might add a few points. Points that have less to do with the act of interviewing itself.

For some organizations, interviewing is a novel and unfamiliar practice, which is why it can provoke many questions: Why would you want to talk to customers when the sales and customer success teams are already doing it? Could you also ask them about how they liked our latest webinar? You’re not going to blurt out any information about upcoming features, are you?

If you want to foster clarity and trust among stakeholders, you need to address these concerns and wishes while preparing for customer interviews. It’s your job to help people understand what interviews are all about, what they can expect, and why they don’t need to worry.

So how can you do this?

I’ve adopted a few stakeholder-aware practices while working as a service designer and user researcher over the past three years. Next, I’m going to share my three favorite ones as well as the reasoning behind them.

Three people sitting and talking around a wooden table in a well-lit office room with house plants.
Don’t just talk with users and customers. Talk with stakeholders, too. Photo by airfocus on Unsplash.

1. Clarify objectives and discuss the research plan together with your team (or whomever has asked for your help)

In my previous job at a health tech company, I was once asked to conduct research for a product team that developed digital care plans. I set up a meeting with the product manager to discuss what she wanted to learn from our customers and users. She listed multiple things of varying magnitudes from how a specific feature was currently used to whether it made sense to develop an alternative logic to the entire care plans functionality. I was happy that she saw talking with customers as a way to tackle all these issues. But I wasn’t sure we could cover them all in one set of interviews.

“Having varying objectives isn’t a problem. But having varying expectations on what you can accomplish in a couple of interviews is.”

Having varying objectives like in this isn’t a problem. But having varying expectations on what you can accomplish in a couple of interviews is.

That’s why — before writing down a single interview question — I like to set up a 30-minute meeting with the team or person who has asked for my help and discuss what we’re trying to learn by talking to customers or users. I take good notes and turn them into a preliminary research plan (or plans if I think I can’t meet all the objectives with one research effort).

Then, I set up another meeting to go over the plan. This is the equivalent of labeling in good conversations (“If I understood correctly, what you meant was. . .”); by writing things down and showing them to the people who’ve asked for your help, you avoid misunderstandings. I recommend doing this every time you start a new project.

Setting up a few meetings just to define the research plan may sound time consuming. But it shouldn’t take longer than 2 h in total (especially if you do silent meetings): 30 min for the first meeting + 30 minutes for creating the research plan + 30 min for the second meeting + 30 min for revisions. And if the people you want to discuss the research plan with come to the office regularly, you may be able to have the necessary conversations more organically. In any case, reserve some time on this.

2. Meet with key stakeholders in advance

You could probably tell by my introduction that I’ve come across some doubtful and concerned stakeholders over the years. Initially, I didn’t think much of it; I just haphazardly answered their questions. But over time, I adopted a more proactive approach: identifying the employees who regularly interact with the customer or who know most about the context or market in question — account executives, sales team members, and customer success managers for the most part — and setting up brief meetings or coffee dates with them.

What I do in these 15–30 minute meetings is simple: I tell them about the research plan and ask if there’s anything I should know about the customer or their business in advance. I also inquire about which customers they recommend contacting (these people tend to be gatekeepers as well), because, at this stage, I usually haven’t booked all the necessary interviews yet.

“When stakeholders get to share advice, they don’t need to worry that you’ll ruin the hard work they’ve put into building good relationships and managing expectations.”

This practice fosters trust. When stakeholders get to share advice, they don’t need to worry that you’ll ruin the hard work they’ve put into building good relationships and managing expectations. And if you sneak in a few sentences on your interviewing approach, they may become more confident in letting you go out and talk to customers, for example, because they know you’re not planning to discuss upcoming features.

The practice has some direct benefits to your preparation process, too.

You may get recommendations for background research:

“Because they work so closely with us, they expect us to be experts on the content they’ve put into the product. So even if you’re a user researcher, they probably won’t see the difference. So it’s a good idea to carefully study the content and the materials in their customer folder in advance.”

“I’ll send you the link to the Miro board so you can look at what we’ve already found out about the knee operation care path.”

Or tips (or warnings) on the user group or customer:

“Just so you know, they can be quite chatty — many of them are already retired.“

“He’s had quite a bit of complaints about the booking feature, and since we don’t know when it’ll be fixed, try not to get into it too much.”

These recommendations, tips, and warnings can help you prepare better, at least mentally.

3. Consider the stakeholders’ wishes, but use discretion (and your creativity)

Now you’re ready to craft the interview guide (or guides, if you identified several unrelated objectives). Divide a document into sections based on the research questions, and then turn the research questions into interview questions. Done!

Well, almost.

“In a less design-mature organization, considering stakeholders’ wishes may be what it takes to even get permission to interview users.”

While talking with your team and key stakeholders, you’ve probably gotten some wishes for what to ask or not to ask. If you want to foster trust, and especially if someone has asked to check your interview guide before you venture out, you need to consider these wishes. In a less design-mature organization, this may be what it takes to even get permission to interview users (I know it’s sad, but it happens).

Here’s what I do: I often add a few of the requested questions to the interview guide even if I don’t think they’re very good or relevant (let’s face it, this is often the case). To keep them from negatively impacting the interview, I tweak the formulation and choose the location wisely. Alternatively, if I’m bringing along a team member or stakeholder to the interview,* I might tell them that they can ask one or two of their questions at the end.

Adding a few extra steps to your interview preparation process may feel like a drag. But if those steps foster clarity and trust among stakeholders, you may save yourself from some future head-banging: Your team members and stakeholders become more comfortable with letting you speak to customers and users, making your job easier to do. You prevent misunderstandings, improving efficiency. And you may even get a few people excited about what you do, opening doors to further conversations.

*If you want to learn more about why I often bring along team members or stakeholders to user interviews, check out my article Never interview users alone: Interviews as the Trojan Horse of a human-centered approach. For the opposite perspective, check out On going solo: Four reasons for interviewing users alone.

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

Bootcamp
Bootcamp

Published in Bootcamp

From idea to product, one lesson at a time. Bootcamp is a collection of resources and opinion pieces about UX, UI, and Product. To submit your story: https://tinyurl.com/bootspub1

Riikka Iivanainen
Riikka Iivanainen

Written by Riikka Iivanainen

Writer, content designer, and user researcher fascinated by the human mind and behavior. I study (social) psychology for fun and love telling stories.

Responses (1)

What are your thoughts?