What kind of interviews don’t vampires like? Stakeholder interviews.

File Under: Essential Discovery Techniques

The Delicate Art of Interviewing Stakeholders

There are users — the people who will use your product.

There are collaborators — the people with whom you will build the product.

And then there are stakeholders — the people who perhaps don’t have a clear role, but do have an interest in your work.

Someone is a stakeholder when they care about the outcome of your project. They may be accountable for its success or failure. They may contribute to the care and maintenance of the product. On the other hand, they may be the resident expert.

Because of their interest, interviewing stakeholders is crucial for designers. I take nearly as much time preparing the stakeholder interview script as I do scripts for user interviews.

Here are some questions I typically include:

“Describe the purpose of this project in your own words.”

My first question is generally along these lines. Depending on how well they can articulate a purpose, it reveals just how engaged they are. My colleague Chris learned in the first week that no stakeholder besides his sponsor thought the project was a good idea. On the flip side, engaged stakeholders with nuanced differences in their responses reveals differing priorities and concerns.

“What’s the most important thing for us to get right?”

This question helps me establish priorities, and gives me some insight about the stakeholder’s main concern. It’s kind of like asking “what’s most important” and “what keeps you up at night” all rolled into one.

“How would you characterize the target audience?”

I like using the word “characterize” because I think it helps them think of the audience as an actor, as users of the product. It also nudges them to describe users in terms of their goals, not demographics, which aren’t as interesting to me.

“If you could ask users one thing, what would it be?”

What I’m really asking here is, “what are your assumptions about users” or “what are your blind spots”. By asking them to give me a single question, I get them to focus on something tangible.

“How will you know if this is successful?”

Here I’m trying to learn how this effort fits into their overall business. If they can articulate its success relative to the other parts of their world, I feel more confident that the project will get attention. Good answers to this question also start to feed into a product vision.

If interviewing a user is journalism, then interviewing a stakeholder is going on a first date. You’re earnest about learning something from this person, but you also want to learn about this person. You may even be picturing yourself in a long-term relationship with this person, so to speak, and aware of the impression you’re making.

This is the challenge: the agenda is multifaceted. On the surface, your questions are meant to learn what you can from them. What sits behind the questions is your need to understand what it’s like to work with them and what it takes to keep them engaged.

Don’t Expect All the Answers

Suppress the urge to ask directly about specific design artifacts like requirements or user profiles. I must have learned somewhere along the way that this approach doesn’t work. They usually don’t yield useful answers. Or maybe I just find them boring.

So, no, you won’t get a well-crafted vision or clear project goals or predefined user profiles. Few, if any, stakeholders have these answers at their fingertips anyway. Besides, these artifacts are the domain of the team.

Instead, what you do get is the fodder to help you build them. Stakeholder interviews produce raw materials for the design process. Their answers inform activities that move the project forward.

Lines of Questioning

With these expectations in mind, I build a script around three lines of questioning:

Domain questions

My projects right now involve architectural licensing, higher education marketing, and process management for a large multi-lateral. Even my well-regarded liberal arts degree didn’t encompass any of these subjects. Interviewing stakeholders gives me a crash course in the domain. I go into these conversations with the posture that they’re the domain experts, but knowing that every domain has myriad perspectives.

Audience questions

Speaking of perspectives, how an organization conceives its target audience is almost as interesting as the audience itself. A mythology has built up around their users, entrenched in the long-standing labels used throughout the company to talk about them. In interviewing stakeholders, I want to hear this mythology–the stories the organization tells itself about the people presumably benefitting from its good works.

Constraints questions

No product exists in a vacuum, and this line of questioning uncovers what that means. Stakeholders, with their unique vantages in the organization, can expose constraints — technical, operational, political — that inform the design process. These questions may be personal since some stakeholders play a role in supporting and maintaining the product.

You might be thinking: Where do you ask about pain points? About challenges? About goals? Where do you uncover assumptions? Surface requirements? All those are embedded in these lines of questioning. These three areas help me focus on tapping into the stakeholder’s knowledge and expertise, and they approach the product from their perspective. Pain points, assumptions, requirements: that’s product development jargon.

Asking the Right Questions

Mindset is an attitude through which we interpret the world and react to it. There are three creative mindsets —curiosity, skeptcism, and humility — attitudes that help designers do their jobs better. You can embody these three mindsets in how you ask questions.

Curiosity Mindset

When you’re curious, you’re genuinely interested in new information. You ask questions not because you have to, but because you’re sincerely interested in the answer. This attitude elevates your script from to-do list to interview. When you look at your script, you can ask yourself whether a question there will produce a meaningful response, or whether you just carried it over from the last script.

• Before: “What are your pain points?”
• After: “Walk me through the process of applying for a reciprocal license.”

Skepticism Mindset

With a dose of skepticism, curiosity goes from merely asking questions to uncovering assumptions. Skepticism gives you permission to go off script to make sure both you and the stakeholder truly understand what lies at the root of their responses. With this attitude, you see most organizational norms not as self-evident, but as in need of validation.

• Before: “Describe the main users of this product.”
• After: “Why does the organization refer to this group as ‘power users?’”

Humility Mindset

Embodying humility in an interview means not assuming you immediately understand everything the stakeholder is saying. The prying of skepticism is married with a sort of confident ignorance. Phrases like, “Can you say that again so I can make sure I get it right” help people understand you’re not taking their time or knowledge for granted.

• Before: “We’re out of time. Thanks for participating.”
• After: “We’ve got 10 minutes left, so I want to ask, is there anything we didn’t talk about that you feel we should?”

A few weeks ago, I spoke with the good people at Mule Design in San Francisco. Erika Hall said that the stakeholder conversations are the most important ones we have on any project. It’s in those conversations, she said, we come to understand not just what we’re designing, but how we’ll need to design it. Different stakeholders influence the process differently, and you can’t plan for those vectors if you’re not aware of them. As a designer you don’t just determine the right path toward the project’s goals. Owning the design process means acknowledging every factor, every influence, every input that shapes that path.

Thanks for reading! I wrote a whole book on the design discovery process. You should check it out!

You can download a sample chapter from A Book Apart. The book puts techniques like stakeholder interviews into context, explaining how an entire discovery phase comes together. If you pick up a copy, all my dreams will come true!

Need help doing discovery for your digital product? EightShapes can advise or drive projects to get you to a product definition and vision. Find out more at eightshapes.com. Please get in touch!