Stakeholder interviews: ask everyone the same questions, then map the disagreements

Stakeholder interviews are one-on-one conversations with the people inside an organization who have a stake in a project, held at the start so you learn its goals, constraints, history and definition of success before anyone designs anything. Run stakeholder interviews before the kickoff meeting, ask every person the same core questions, and treat the places where their answers disagree as your main finding.

Nielsen Norman Group defines a stakeholder as anyone with an interest in a project or anyone you need to work with to complete it. A user interview teaches you about a topic such as how people use a system. A stakeholder interview asks questions meant to shape the design process, define success metrics and meet the stakeholders' expectations.

This post covers project stakeholders: executives, managers, engineers, support staff and other insiders. If you need to talk to outside market players such as customers, suppliers and channel partners, read market research interviews instead.

1. Interview stakeholders before kickoff, and before user research

Book the interviews in the first week, ahead of the kickoff meeting. The reason is simple: the kickoff is where people commit to a plan, and you want to know their assumptions before they say them out loud in front of their boss.

18F, a digital services team in the US General Services Administration whose blog is now archived, recommended holding stakeholder interviews before the project kickoff, to surface questions and constraints and to build a shared understanding of the problem (18F blog, part 1). Kim Goodwin, in an excerpt from her book Designing for the Digital Age, advises finishing stakeholder interviews before user research, so you know which assumptions and open issues the user research has to test (Boxes and Arrows).

Late is still better than never. NN/g lists three good moments: project kickoff, when a new stakeholder joins, and as a reset when the project has gone wrong.

2. Pick people by what they control, and stop at four to eight per round

Choose each interviewee because they own a goal, a constraint or a piece of knowledge the project depends on. Seniority alone is a weak reason. The support lead who answers the angry tickets often knows more about the current product than the vice president who approved the budget.

Goodwin's sample schedule shows the usual spread: the CEO and vice presidents of sales and products, product managers, engineering leads and engineers, corporate marketing, QA, professional services, support, regulatory staff and a subject-matter expert (Boxes and Arrows). 18F suggested grouping stakeholders by how they get their work done, then picking a few people per group who can show you their workflow (18F blog, part 1).

For size, the 18F author aimed for four to eight people per round, at least 45 minutes each (18F blog, part 1). End each interview by asking who else you should talk to, as NN/g recommends, and check new names with the project owner before you contact them, as Goodwin suggests. (Every list of stakeholders grows by two the moment you show it to anyone.)

3. Talk to one person at a time

Interview each stakeholder alone. NN/g recommends one-on-one sessions, and the reason is easy to picture: in a group, the most senior person speaks first and everyone else edits their answer to fit.

There is one useful exception. Goodwin's example schedule includes a joint session where two product managers walked through the existing system together (Boxes and Arrows). Pair people when they are demonstrating a shared workflow. Keep everything about goals, worries and politics one-on-one.

If you have dozens of stakeholders, NN/g suggests a short survey to cover the long tail, while noting that people tend to respond less fully to a survey than to an individual email (NN/g).

4. Write a one-page guide of topics, with backup questions

Stakeholder interviews are usually semi-structured: you bring topics and a few prepared questions, then follow the conversation. NN/g organizes its guide around four topics: success metrics, priorities, history and expertise, and process and workflow. 18F drafted four to six areas to explore and treated them as flexible (18F blog, part 1). Goodwin keeps her topic list on the inside cover of her notebook so she can glance at it when stuck (Boxes and Arrows).

Here is a core set, paraphrased from NN/g and Goodwin:

1. What is your role on this project, and what did you do before this job?
2. In plain words, what is this product supposed to be, and what is it not?
3. Who is it for?
4. What business result should it produce, and how will you measure it?
5. What would make this a success for you and your team personally?
6. When does it need to ship, and why then?
7. What constraints should I know about (technical, legal, budget, people)?
8. What has been tried before, and why did it work or fail?
9. What worries you about this project? What is the worst thing that could happen?
10. How do you want to be involved from here, and how should I keep you updated?
11. Who else should I talk to?

Goodwin explains why several of these matter. Asking about prior jobs reveals hidden expertise. Asking who the product is for exposes assumptions about users, and conflicting answers tell you the team needs better user data. If someone struggles with business goals, she suggests narrower prompts about revenue, cost savings, brand position and new capabilities (Boxes and Arrows).

For more on structure, see how to write a discussion guide and semi-structured interviews.

Short version: one page of topics, the same core questions for everyone, and room to follow whatever turns out to matter.

5. Ask everyone the same core questions, because the disagreements are the finding

Ask the same questions about goals, users, timeline and success in every interview, even when you think you know the answer. Goodwin notes that in-house teams should ask them too, since a colleague's answer may differ from what you assume (Boxes and Arrows). 18F described the same habit as informal polling: asking one question across many interviews (18F blog, part 2).

Goodwin gives a concrete threshold for one common conflict. Marketing tends to give optimistic release dates and engineering pessimistic ones, and if the answers differ by more than about a month, she raises it with the project owner (Boxes and Arrows).

Here is a made-up example. Priya, a product designer, is asked to redesign the expense approval tool at a 400-person logistics company. She interviews six people: the CFO, two finance managers, the IT lead, the support lead and a regional operations manager.

The CFO says the new tool ships in March. The IT lead says June, because the finance system is being migrated first. That is a three-month gap, well past Goodwin's one-month flag, so Priya takes it to the project owner before kickoff. Better to have that conversation in week one than in week ten.

6. Save worries and involvement for the last ten minutes

Put the sensitive questions late. Goodwin suggests asking about worries and the worst case once the person has relaxed, because the answers show where you can help and where the organization may limit the design (Boxes and Arrows).

Ask how they want to be involved as the final question. Goodwin's reason is practical: it keeps senior people present at key decision points, and when a senior executive says they want to be involved, you can point to that with a middle manager who is reluctant to involve senior management (Boxes and Arrows).

In Priya's made-up case, the operations manager's worry is the useful one: drivers photograph receipts in a truck cab at 5am, with gloves on. Nobody else mentioned drivers at all. That goes straight into the user research plan.

7. Run the session like a conversation, and keep the schedule humane

Open with a short script. NN/g suggests covering who you are and the project's purpose, that you are speaking with others in the organization, that there are no wrong answers, that comments will not be attributed to the person, and how long the session will take.

Then mostly listen. 18F's advice was to ask "how" and "why," then ask them again, to stay comfortable with silence, to write down the person's exact words and reflect them back, and to ask for stories instead of reading the question list in order (18F blog, part 1; part 2). NN/g recommends open probes such as asking for an example, and a calm pace even with long-winded speakers (NN/g).

If you record, ask first. 18F brought a plain-language consent form, asked permission again on the recording, and told people they could pause or stop it (18F blog, part 2). Bring a teammate along, which 18F also recommended because it helps the team learn what you are hearing in real time.

Pace yourself. Goodwin plans no more than six interviews in a day, with a short break after every couple, and her example schedule blocks out a lunch debrief and an end-of-day debrief (Boxes and Arrows). Six is a ceiling. By the fifth interview you will start hearing answers nobody gave.

8. Synthesize into a one-page map of agreement and conflict

Write up each interview the same day, then compare across people. NN/g splits the approach by size: with five or fewer stakeholders, outline the major themes and concerns in a simple shared document; with more, tag notes and quotes with codes and look for concerns, success metrics and ideas that several people raised. Affinity mapping is a practical way to do that coding as a team.

18F added two steps worth copying. First, share transcripts back with each stakeholder so they can correct them, which builds trust and often surfaces more information. Second, hold a team meeting that compares what stakeholders said against the assumptions you wrote down before the interviews (18F blog, part 2).

The output should fit on one page:

Take the conflicts row to the project owner first, then present the page to the group. When you share it, plan for the person who asks how you know; this guide to research readouts covers that.

9. Know when stakeholder interviews are the wrong tool

Stakeholder interviews tell you what the organization believes, wants and fears. They do not tell you what users do, so never let them stand in for user research. Use them to decide what the user research must test, then go do it with customer interviews or broader product discovery.

They also fit poorly when the "stakeholder" is a busy executive who will give you ten minutes at most. In that case, NN/g suggests sending only the four or five most useful questions in writing. Goodwin suggests asking for the documents they rely on, such as memos and presentations, and building relationships with people in their department (Boxes and Arrows).

Sometimes the knowledge you need does not exist inside the company at all, for example how other firms ran the same migration. Then the right interview is with an outside practitioner, such as one of these change management consultants, management consultants or heads of design. On Instant Expert you can invite specific people like these to a short paid call, and you pay only if someone books or answers.

Start today by writing down your own assumptions about the project's goal, users and deadline. Then book four interviews and see how many of those assumptions survive.