Stakeholder discovery interviews fail when they copy the format of user research: asking what someone needs instead of where they stand. A position-focused interview surfaces what would make the initiative fail for that person, who else they answer to, and what winning looks like on their terms — turning polite nodding into a mapped, evidence-backed read of real risk.
Quick Answer: Interview stakeholders like a negotiator, not a pollster. Ask about fail conditions, required allies, and past scars — then log the answers as direct quotes tied to a date and decision, not as paraphrased impressions. That evidence, not a title on an org chart, is what predicts a blocked launch.
The cost of skipping this step rarely shows up at kickoff. It shows up months later, when a stakeholder who nodded along suddenly finds a reason the launch can't proceed. Gallup's long-running research on manager and workplace trust has repeatedly found that people are far less likely to volunteer real concerns to someone who hasn't explicitly invited them — exactly the gap a requirements-only interview leaves wide open.
Why a Requirements Interview Leaves You Blind to the Politics
A requirements interview asks "what do you need from this system," which is exactly right for users and mostly wrong for stakeholders. Stakeholders rarely need a feature; they need the initiative to not threaten their budget, headcount, reputation, or turf. Ask only about needs and you'll miss the objection that kills the launch in month four.
This isn't a knock on needs-based discovery — it's the correct tool for a different job. The JTBD canon covered in the complete guide to Jobs to Be Done is built to uncover what a customer is trying to accomplish, independent of any solution. Stakeholders operate on a different axis entirely: position, not job.
Negotiation theorists Roger Fisher and William Ury, in the Harvard Negotiation Project's Getting to Yes, drew a distinction that still holds up decades later:
- A position is the stated stance — "I need this rolled out by Q3," "Legal has to sign off first."
- An interest is the reason behind it — protecting a budget line, avoiding a repeat of a past failure, keeping a team relevant.
This isn't just theory. PMI's Pulse of the Profession research has for years counted inadequate stakeholder engagement among the top reported causes of project failure, alongside scope creep and unclear requirements.
The contrast is easiest to see side by side. A JTBD question sounds like "what are you trying to get done when you open this dashboard?" A position question sounds like "what happens to your team's headcount if this dashboard replaces the report you currently own?" Both are legitimate discovery — they're just aimed at different risks.
Requirements interviews capture positions at face value and stop there. Position-discovery interviews treat the stated position as a clue and keep digging for the interest underneath — which is where the real risk, and the real leverage, actually lives. This is the missing layer in most kickoff discovery, and it's why the complete guide to stakeholder politics treats interviewing as a distinct skill from requirements-gathering, not a variant of it.
Setting Up the Interview So People Tell You the Truth
The setup determines the data quality more than any single question does. A stakeholder who feels surveyed gives you the sanitized, org-chart-safe version of their opinion; a stakeholder who feels consulted gives you the real one.
Three conditions make the difference:
- Frame it as risk-finding, not requirements-gathering. Say plainly: "I'm trying to find out what could make this fail for you specifically, before it does." That framing gives permission to be honest about politics instead of features.
- Go one-on-one, in private. Group settings collapse positions into whatever the most senior voice in the room says. You want the version someone won't say in front of their boss or their rival.
- Ask before you propose. If a solution is already on the table, people react to it instead of revealing their actual criteria. Interview before the deck exists, not after.
This isn't just etiquette. Amy Edmondson's research on psychological safety at Harvard Business School has long shown that people withhold negative information upward when they don't feel safe voicing it — precisely the dynamic a group interview recreates the moment a senior voice enters the room.
Treat the interview the way a customer journey exercise treats a single touchpoint: not a data-collection formality, but a chance to find the emotional high or low point a survey would flatten out. The customer journey framework maps where a user's experience spikes with frustration or delight.
A stakeholder interview is hunting for the same kind of spike — the moment fear or ambition actually shows up in someone's voice, not in their prepared talking points.
When to Run These Interviews
Timing changes what people are willing to say. Interview before scope is locked, so people are reacting to a direction rather than defending a decision already made in a document.
Three moments call for a fresh round, not just a one-time kickoff pass:
- Before the kickoff deck exists — captures unfiltered positions before anyone has committed to a public stance in front of peers.
- Right after a scope or budget change — a position formed under old constraints can flip once the constraints do.
- Before a go/no-go milestone — a stakeholder who was quietly against it may resurface the same objection right when it's hardest to fix.
Treating discovery as a one-time step done at project start is a common reason a mapped stakeholder later becomes a surprise blocker — their position moved, and nobody re-asked.
The Position-Discovery Question Bank
Four question families do most of the work: what would make this fail for them, who else needs to be onboard, what they've seen go wrong before, and what a win looks like on their terms. Ask all four of every stakeholder who can meaningfully help or block the initiative.
Fail-Condition Questions
These questions locate the trip wire before you step on it.
- "What would make this a failure, from where you sit — even if everyone else called it a success?"
- "If this goes sideways in six months, what's the first thing that broke?"
- "Is there a version of this that technically ships but you'd still consider a loss?"
Coalition Questions
Nobody blocks alone, and nobody champions alone either. These questions map the coalition someone is speaking for, even when they present themselves as speaking only for themselves.
- "Who else has to be comfortable with this before it moves forward?"
- "Whose sign-off would surprise me if I didn't ask for it?"
- "If you supported this but your peer in [adjacent team] didn't, what happens?"
Answers here are raw material for reading the org as a network of influence rather than a hierarchy of titles — the exact exercise covered in reading the org as a graph. A name that keeps recurring across multiple interviews, unprompted, is a power center whether or not it appears on the project's official stakeholder list.
Precedent Questions
Past scars predict future resistance more reliably than any stated preference.
- "What's the last initiative like this that went wrong, and what actually happened?"
- "Has something like this been tried here before? What killed it?"
- "What would you need to see differently this time to trust it'll land?"
Win-Condition Questions
- "What does a win look like for you personally, not just for the company?"
- "If this succeeds, what changes for your team or your role?"
- "What would you want credit for, if this goes well?"
Red Flags in the Answers Themselves
Some answers are diagnostic on their own, independent of their content. Watch for these patterns as you go:
- A rehearsed, uniformly polished answer to a fail-condition question often means the stakeholder has had this conversation with someone else already — worth asking who.
- A win-condition answer scoped entirely to "the company," with no personal stake mentioned, can signal disengagement dressed up as neutrality.
- A coalition answer with no names at all ("everyone would need to agree") is usually vaguer than the real situation — press for at least one name.
None of these prove a position on their own. They're signals telling you where to keep pressing, not conclusions to write down as settled fact.
| Question type | What it surfaces | Strong follow-up |
|---|---|---|
| Fail-condition | The specific trigger for opposition | "What would you do the moment you saw that happening?" |
| Coalition | Hidden allies and blockers, real decision chain | "Have you already talked to them about this?" |
| Precedent | Root cause of latent distrust | "What was different about the team that tried it last time?" |
| Win-condition | The incentive that earns active support | "How would you want that visible to your own leadership?" |
Run this bank against every role a launch typically depends on — sponsors, champions, and advocates each answer these questions differently, and the gap between roles is itself diagnostic. A sponsor who can't name a fail condition hasn't actually thought it through; a champion who can't name a single ally is weaker than their title suggests.
Positions vs. Interests: Reading What's Under the Statement
A stated position is a starting offer, not a fact — treat it as the surface layer of something you still have to excavate. Chris Argyris's ladder of inference, a staple of organizational-behavior research since the 1970s, describes exactly this gap: people act on conclusions built from selectively observed data, then state the conclusion as if it were the data itself.
The interview's job is to climb back down that ladder, one question at a time, until the position resolves into an interest you can actually design around.
A simple test while you're in the room: ask yourself whether you're hearing the observed fact or the stakeholder's conclusion drawn from it. If it's a conclusion, your next question should ask for the observation underneath — not accept the conclusion as the interview's final output.
| What they say (position) | What it might mean (interest) | Probe to test it |
|---|---|---|
| "Legal has to review this first." | Fear of being blamed if something goes wrong later | "What happened last time something skipped that step?" |
| "We don't have bandwidth this quarter." | The initiative doesn't visibly help their own metrics | "If this moved your number too, would bandwidth still be the blocker?" |
| "I just want it to be simple." | Their team will inherit the support burden | "Who fields the tickets if this ships as-is?" |
| "I'm fully supportive." | Passive non-objection, not active backing | "Whose help would you personally ask for to make this land?" |
A position taken at face value gets logged as agreement or resistance and nothing else. The interest underneath is what actually tells you whether that agreement survives contact with a delayed timeline or a reorg.
Logging Positions as Evidence, Not Gossip
A stakeholder log is only useful if it would hold up if the stakeholder read it themselves. That single test — would this survive being read by its subject — is the difference between evidence and gossip, and it should be the first thing you check before saving a note.
Follow four rules when you write it up:
- Quote, don't characterize. "Difficult about the timeline" is gossip; "said, 'I won't sign off without a security review'" is evidence.
- Attach a date and a decision. A position logged without context ages badly — what someone opposed in January may be moot by March.
- Separate the observed statement from your inference. Write what was said, then write your read of the interest underneath as a clearly labeled hypothesis, not as fact.
- Update, don't overwrite. A changed position is itself a signal. Keep the history instead of replacing the old note.
A log entry that passes all four rules might read like this:
2026-03-14 — VP Legal, re: vendor integration proposal Position (verbatim): "I won't sign off without a security review, and that review takes six weeks minimum." Decision context: raised in response to the Q2 rollout timeline shared that same morning. Inference (hypothesis, not fact): timeline risk seems secondary to being blamed for a skipped step, given the reference to a specific past precedent.
Notice what's absent: no adjective describing the VP, no guess presented as settled fact — just what was said, when, and a clearly labeled read on why.
This is exactly the pattern that feeds an Alignment Debt Score: the score is only as good as the evidence trail underneath it. Evidence built from quoted positions, dated and tied to real decisions, is what makes the score predictive instead of decorative.
Where the Notes Actually Live
Instead of losing the nuance to a delayed, tidied-up write-up, it's captured while it's still fresh. Once it's in, it's searchable evidence for your stakeholder map — not a separate pile of notes you have to remember to dig up later.
Key Takeaways
- Interview stakeholders for position, not requirements — what they need is rarely the risk; what they fear losing is.
- Use four question families: fail-conditions, coalition, precedent, and win-conditions, and ask all four of anyone who can meaningfully help or block the work.
- Treat a stated position as a starting offer, then probe toward the interest underneath using Fisher and Ury's positions-vs-interests distinction.
- Log evidence, not impressions — direct quotes, dated, tied to a decision, with your inference clearly separated from what was actually said.
- A changed position is a signal worth keeping, not a note worth overwriting — history is part of the evidence.
- Coalition questions reveal the real org chart — the names that recur unprompted across interviews are the power centers worth mapping.
Frequently Asked Questions
How is a stakeholder discovery interview different from a user interview?
A user interview uncovers a job to be done: what someone is trying to accomplish, independent of any solution. A stakeholder discovery interview uncovers a position — what would make the initiative fail for that person, who they answer to, and what a win looks like on their terms. It's a political question, not a functional one.
What if a stakeholder won't tell me their real position?
Silence and vague reassurance ("I'm supportive, whatever you decide") are themselves positions worth logging — they usually mean passive non-objection rather than active backing. Ask a sharper probe like "whose help would you ask for to make this land," which forces a more concrete answer than a generic yes.
How many stakeholders should I interview before starting?
Interview everyone whose name recurs unprompted across your first two or three conversations, plus every named sponsor, champion, and blocker on the initiative. Stop expanding once new interviews mostly confirm coalitions you've already mapped rather than surfacing new names.
How do I keep a position log from turning into office gossip?
Apply one test to every entry: would it survive the subject reading it themselves? Quote what was said, attach a date and decision context, and label your interpretation of the underlying interest as a hypothesis — never write a characterization of the person.
Should I interview stakeholders again after the initial round?
Yes — a position logged in month one can shift by month three as budgets, reorgs, and priorities change. Treat the first round as a baseline and re-check with key stakeholders at major milestones, keeping the old entries rather than overwriting them so the shift itself becomes visible.