Run Your First Stakeholder Interview — Requirements Engineering, Part 1
Updated: 3 days ago
Nobody hands you a requirement. They hand you a solution they already picked, and if you write it down exactly as stated, you will build it correctly and still be wrong.
A stakeholder interview is not requirements gathering. Gathering implies they already exist and someone is holding them. They don't — they get manufactured in the room, out of a workflow the person performs without thinking and numbers they've never written down. In the reviews I've sat in, the decisive error is older than the code: someone recorded what was asked for instead of what was needed.
This tutorial produces a validated interview record in about 90 minutes: 20 to prepare, 45 in the room, 25 to write up and check.
Illustrative composite introducing the support-tooling example continued in Parts 2–10. Figures are illustrative, not measured.
Before You Start
One named process with a real decision behind it — not a survey of everything.
One person who performs the work weekly, and 45 minutes of their calendar.
25 minutes blocked immediately after, before the next meeting eats the write-up.
Read-only access to their tool, open before the call.
A notes file with the four channels of Step 7 prepared.
Familiarity with the wider technique set in requirements elicitation techniques that work — interviews are one instrument, not the kit.
What You'll Build
An interview record for one stakeholder: their workflow as numbered steps, a pain list where every item carries a number or an explicit unknown, a want→need ladder, open questions, and a summary they correct.
Step 1: Choose the Person Who Touches the Work (10 min)
Managers describe the process as designed; practitioners describe it as performed. That gap is most of your requirements risk. Ask the sponsor: who does this five days a week?
For the refund queue we booked Dana, support lead for a nine-agent team, who still works it two mornings a week — enough hands-on to describe reality, enough scope to know the exceptions.
Keep the level straight: you want user requirements, not business objectives or system specs. Mixing all three yields a feature list nobody can trace to a reason.
Check: you can name the last time they personally performed the task. If the answer is "she oversees it," you booked the wrong person — book the second interview now.
Step 2: Build a Five-Block Question Spine (15 min)
Write it as three columns. The third is the one people skip — and the one that makes the interview testable.
Block | Question that opens it | How you know it worked |
Background | "Walk me through your morning." | They name a time of day and a tool |
Current workflow | "Show me the last one you handled." | You can redraw the steps unaided |
Pain | "What did you work around this week?" | An instance, not a category |
Desired state | "What would you stop doing if this were fixed?" | An action they'd drop |
Wrap-up | "What should I have asked about?" | An item you hadn't planned |
Keep it on your second screen; don't recite it in order — a recited script produces recited answers.
Check: every block has its third column filled in. A block whose success you can't observe is a topic, not a question.
Step 3: Open by Removing the Sales Pressure (first 5 min)
People perform for interviewers, describing the process as it is supposed to run because they assume an audit. Say the opposite out loud:
"I'm not collecting a feature list. I want to understand how the refund queue actually works today, annoying parts included. Nothing you say commits anyone to building anything."
Camera on if remote. Record only with permission — recording changes what people admit about their workarounds.
Check: within five minutes they've described something that doesn't work, unprompted. Still hearing the sanitized version? Say the "nothing commits anyone" line again.
Step 4: Walk the Whole Workflow Before Discussing Any Problem (15 min)
Get the path end to end, in their sequence, before you touch pain. A problem described without its workflow is an anecdote.
Dana's, in her words: a refund request lands in the queue from email or chat. She opens the order in admin, checks whether it shipped and whether the customer already got a partial credit. Under fifty dollars she approves it herself; over fifty she pings a supervisor, which usually means it sits until after standup. Then she issues it in the gateway, pastes the confirmation into the ticket, and closes it.
The branch points are the rules: the $50 threshold, the shipped check, and the partial-credit check Dana flagged herself (orders paid part gift card, part card, "are the ones that go sideways"). Numbers she knew without looking: about 60 refunds waiting on a normal morning, 240 after the holiday returns window, a 24-hour SLA on first response. That workflow becomes the scenario in Part 2: Document Use Cases.
Check: read the workflow back as numbered steps and they correct at least one. No correction means you captured their summary, not their process.
Step 5: Convert Every Want Into a Need (10 min)
This is the move the tutorial exists for. Dana said: "I want a dropdown to filter by status."
Do not write that down as a requirement. Put it in a wants column and ask "walk me through the last time you wanted that." It was 8:10 on a Tuesday: scrolling the queue for requests near the 24-hour mark, doing the subtraction in her head.
The need underneath: see which refunds are past 24 hours before assigning the morning's work.
The want has one implementation; the need has several — a default sort by age, an overdue badge, a digest that lands before she opens the tool. Record the need; keep the want as evidence for it.
When one "why" doesn't reach the need, a branching Five Whys keeps the ladder honest: write down the other plausible answers at each step and check them against the workflow you just walked, instead of following the first one that sounds right.
They said (want) | Why, in their words | The need you record |
"A dropdown to filter by status" | "To find the ones about to blow the SLA" | See refunds past the 24-hour mark before assigning work |
"Can it remember my last filter?" | "I set the same one every morning" | Queue view state persists across sessions |
"Make the refund button bigger" | "I hit the wrong row twice this month" | The approval action binds unambiguously to its row |
You turn that ladder into testable statements in writing good requirements.
Check: every want has a need beside it, and at least one need has two or more plausible implementations. A need with one implementation is a want in costume.
Step 6: Make Every Vague Statement Carry a Number (5 min)
"It's slow" can't be built against or tested against. Push for four things: when, how long, how often, compared to what. "About three minutes yesterday morning, and most mornings" is verifiable.
Ask for counts they already track, not counts they'd estimate. Dana knew queue depth and the SLA — both sit on a dashboard she opens daily. She didn't know average handling time, so it stayed an open question, not a guess that hardens into a target.
Check: every pain item carries a number the stakeholder stated or an explicit "unknown — needs measurement." Zero blanks. A blank is where an invented number goes later.
Step 7: Take Notes in Four Separated Channels (throughout)
Quotes in quotation marks. Observations in brackets. Your interpretations in parentheses. Open questions starred. Your interpretation is the part most likely to be wrong, so it should be visibly yours — a reviewer can attack it without attacking the stakeholder.
Check: delete everything that isn't a direct quote or a bracketed observation. What remains should still contain the workflow and the numbers — otherwise you recorded your conclusions, not their session.
Step 8: Close, Then Validate Within 24 Hours (5 min + 20 after)
Close with two questions: "Who else touches this queue?" and "What should I have asked?" Dana named the finance analyst who reconciles gateway refunds against the ledger — a second stakeholder with a different definition of done, and a conflict later in this series.
Then send the summary: workflow as numbered steps, top three pains with numbers, the want→need ladder, open questions, and one line — "Where did I get this wrong?" Run the Step 4–7 checks yourself first; outsourcing all validation means they catch your errors, on their time, and only the ones they notice.
Check: the reply corrects, adds, or disputes something. A "looks good!" four minutes later isn't validation — call and read the workflow aloud.
If This Goes Wrong
You only get the sanitized process. Ask for the last exception, not the usual case — "tell me about one you couldn't process normally." Exceptions hold the real rules.
They answer in solutions throughout. Stop asking what they want; ask what happened. Attach "walk me through the last time" to each one and park it in the wants column.
The conversation drifts to another system. Let it run two minutes, then "can we finish the refund path first?" Log it — unprompted drift is scope evidence.
Nobody replies to your summary. Silence isn't agreement. Re-send with one specific question ("is the $50 threshold still current?") and a date you'll proceed on.
You booked the wrong person. Don't abandon it — spend the time on org context and a referral, then rebook.
Common Failure Modes
Recording wants as requirements
Discussing problems before you know the workflow
Numbers you supplied rather than numbers they knew
One interview treated as discovery
You're Done When
Your numbered workflow came back with at least one correction from the stakeholder.
Every want has a need beside it, and every pain carries a number or an explicit "unknown."
Your summary got a reply that changed the record.
Three artifacts leave this room: a workflow, a want→need ladder, and a list of what you don't know yet. Everything later in this series inherits them — errors included.
Before the next build starts, the Requirements Readiness Checklist runs twenty checks on whether the requirements are ready to build from, and its first section is a gate.
Next — Part 2: Document Use Cases
