How to Run a Stakeholder Interview: A Step-by-Step Guide
Most people learn stakeholder interviews by being dropped into one. An hour appears in the calendar, a list of questions gets written the night before, and the conversation produces a description of how the process is supposed to work. How it is supposed to work is rarely how it works. The difference between the two is usually the point of the interview, and getting to it is a matter of sequence rather than charm.
What to settle before you book the first conversation
Three things need to be decided before any invitation goes out: who you need to speak to, what you are trying to learn, and what the conversation must not turn into. The first is a mapping problem. Sketch the service as you currently understand it, then ask who touches each part of it, who decides when it stalls, and who absorbs the consequences when it goes wrong. That list will include people whose names do not appear on any project page.
It will also include people who have no particular reason to make time for you. The people who reply to a calendar invitation first are rarely a representative sample. Volunteers tend to be the engaged, the senior, the recently arrived and the people with a case to make. The person handling exceptions in a back office is the one who knows where the service actually bends, and they will not put themselves forward. Go and ask them directly.
Then write down what you are trying to learn, as three or four things you cannot answer from documentation. Not topics, questions: what happens when an application arrives incomplete, who is allowed to make an exception, where does a case wait and for how long. This is also the moment to be clear about what the hour is not. A stakeholder interview is not a requirements-gathering exercise. If you go in collecting feature requests, you will get a list of features, and you will have spent the access you had on the wrong thing.
How to open the conversation so you get the truth
The first five minutes set the register for the whole hour. Say plainly what the work is for, who else you are speaking to, what will happen to what they tell you, and whether anything will be attributed. Do not promise a confidentiality you cannot hold. If a direct quotation might end up in a readout their director reads, say so now rather than discovering it later, because a single broken assurance travels through an organisation faster than any research finding.
Then start somewhere concrete and low stakes, on their own work rather than on the service in the abstract. Abstract openings invite abstract answers, and an abstract answer is the official version by default. Useful first questions include:
"Can you walk me through what you did yesterday, from the first thing you picked up to the last?"
"How long have you been doing this, and what has changed in that time?"
"Which part of your week takes longer than anyone outside your team would guess?"
Everything about your manner in that opening either signals that you are there to understand the work or that you are there to assess it. Take notes visibly, do not react to anything as though it were a revelation, and let silences run a little longer than feels comfortable. People tell the truth to someone who is clearly not scoring them.
How to ask about the work rather than about opinions
The single biggest improvement most people can make is to stop asking what someone thinks and start asking what happened. Opinions produce policy statements, and policy statements are already written down somewhere. Specific past events produce evidence: sequences, delays, workarounds, the name of the person who had to be phoned. Anchor almost every question to a real occurrence, and where possible to the most recent one.
"Tell me about the last time an application reached you with something missing. What did you actually do?"
"When was the last time you had to phone someone rather than use the system? What had gone wrong?"
"Walk me through the last case that took far longer than usual."
"Who did you have to speak to before that case could move?"
"What do you do when the system will not let you record what really happened?"
"What is the most common reason work comes back to you a second time?"
Expect the first account of any process to be the documented one. That is not evasion, it is how people describe their own work to an outsider. The follow-up matters more than the question: ask how often it goes exactly like that, and what happens when it does not. Then ask for the last time it did not. The gap between the documented process and the described process is usually where the finding is.
What to do when someone starts defending their team, and how to end well
At some point in a run of interviews, somebody will hear a question as an accusation. The signs are recognisable: the voice shifts into the passive, the answers become a timeline of previous initiatives, and you are told that this was all looked at two years ago. It is a reasonable response. People who have been reviewed before know that a redesign can arrive as a judgement about their competence, and they are protecting colleagues rather than obstructing you.
Pressing harder does not work, and neither does a vague reassurance that nobody is being blamed. What works is moving the question away from behaviour and towards constraint, and away from why towards what. Try "what would have to be true for that to work differently?" or "what has already been tried here, and what stopped it?" Those questions are worth asking with genuine curiosity, not as a technique for getting back on script, because the history of failed attempts is often the most useful thing in the hour.
Leave the last few minutes for closing questions rather than for one more topic. Ask "what have I not asked about that I should have?", "if you could change one thing about how this works, what would it be and who would have to agree?", and "who else should I speak to, and what will they tell me that you have not?" Then say what happens next, when they will hear from you, and what you will do with what they said.
What to do in the twenty minutes afterwards, and across the whole set
Protect twenty minutes after every interview before the next thing in the diary. Use them to write what you would not be able to reconstruct later: the exact phrases someone used, where they hesitated, what genuinely surprised you, and what you would ask differently next time. A recording is not a substitute for this, because a recording preserves the words and loses the reading. Memory of a conversation degrades far faster than anyone plans for.
Across a set of interviews, the temptation is to produce one agreed account of how the service works. Resist averaging. When two people describe the same handover in incompatible ways, that is a finding about the service, not an inconsistency to tidy up. It usually means the handover has no shared definition, which is precisely the sort of thing that fails quietly at scale. Keep contradictions as explicit pairs, with the role attached to each side.
A practical method: cluster observations by what they concern rather than by who said them, keep the source visible on every observation, and mark each cluster as agreed, contested or single-source. Service-dominant logic, developed by Stephen L. Vargo and Robert F. Lusch, describes value as co-created among actors who each bring different resources and work to different logics. On that reading, disagreement between two accounts is close to expected. Flattening it is the one thing synthesis should never do.
Where to start if this is your first one
Choose five or six people who span the frontline, the decision points and the parts of the organisation the service depends on but does not control. Write down four things you cannot learn from documentation. Ask about events, not opinions, and follow every tidy answer with a request for the last time it did not go that way. Keep the twenty minutes afterwards, and keep the disagreements.
The method is simple enough to describe in a paragraph, and the discipline is the difficult part. What you are after is not a set of views about the service. It is an accurate picture of how the work is really done.