How to conduct stakeholder interviews: a practical UX guide with AI prompts

A stakeholder interview is a one-on-one conversation with someone who has a vested interest in a project — a product manager, executive, developer, or subject-matter expert — conducted to gather business context, define success metrics, uncover constraints, and align expectations before research or design work begins. Unlike user interviews, the participant shapes the project rather than uses the product.

This method works best at the start of any initiative, when joining a project mid-stream, or when multiple departments are involved and their priorities may conflict. Running stakeholder interviews early surfaces misalignment before it causes expensive rework.

What you learn

What success looks like for this project from the business side
What constraints — technical, legal, budgetary, political — will affect the design
What has been tried before, and why it succeeded or failed
Where different stakeholders disagree on priorities or vision
What stakeholders already know (or assume) about the users

What you get

Stakeholder map: a visual showing who influences the project, their roles, and how they relate to each other
Alignment matrix: a summary of where stakeholders agree and disagree on goals, priorities, and success criteria
Constraints inventory: technical, legal, budgetary, and timeline constraints gathered from across the organization
Success metrics: how each stakeholder defines success, distilled into shared measurable outcomes
Research brief input: questions and hypotheses that stakeholders want the user research to address
Communication plan: each stakeholder’s preferred level of involvement and communication frequency

When to use (and when not to)

Use stakeholder interviews when:

Starting a new project or initiative, before research planning begins
Joining an existing project mid-stream, to catch up on history and dynamics
Multiple departments are involved and their priorities may conflict
You need to write a research plan and want it to address real business decisions
A major organizational change has shifted project priorities
A project has stalled and hidden blockers may be the cause

Do not use stakeholder interviews when you need to understand end users (use user interviews or contextual inquiry), when you need to evaluate a design (use usability testing), or when the project is so small that a quick conversation replaces the need for a formal interview.

Participants and timing

Interview 5-10 stakeholders, depending on project size. For a typical product team: product manager, engineering lead, design lead, 1-2 business stakeholders (marketing, sales, customer success), and 1-2 executives or sponsors. Beyond 15 stakeholders, a survey may be more practical for initial screening, with follow-up interviews for the most influential voices.

Each session runs 30-45 minutes. Executives often have only 30 minutes; individual contributors can go longer. Do not exceed 60 minutes.

Plan for 1-2 weeks total: 2-5 days for scheduling (stakeholder calendars are hard to pin down), 3-5 days for interviews (2-4 per day), and 1-2 days for analysis and synthesis.

How to conduct stakeholder interviews

1. Define the interview goal

Write down what you need to learn from stakeholders as a group and what each individual is uniquely positioned to tell you. Specific goals: “Learn what technical constraints engineering sees for the redesign,” “Understand how marketing defines success for the new feature,” “Find out what the CEO expects in Q3.”

2. Identify and prioritize stakeholders

List everyone with influence over or interest in the project. Prioritize by two dimensions: how much power they have over decisions and how much they are affected by the outcome. Interview high-power and high-impact stakeholders first. For the rest, consider email questions or a brief survey.

3. Research each stakeholder before the interview

Unlike user interviews, stakeholder interviews allow preparation. Check their role, recent work, public statements, and relationship to the project. This lets you ask sharper questions and avoid wasting their time on basics you could have looked up. Phil Morton recommends using AI to create tailored discussion guides for each stakeholder based on their profile.

4. Create a tailored discussion guide

Prepare a base guide covering four areas: success metrics, priorities, history and constraints, and process preferences. Then customize 2-3 questions per stakeholder based on their specific role and expertise. A customer success lead gets different questions than a CTO. End with “Who else should I speak to?” to discover stakeholders you may have missed.

5. Conduct the interview

Schedule one-on-one sessions — stakeholders speak more honestly when peers and superiors are not in the room. Frame the conversation as collaborative. Listen actively. Note both what they say and how they say it — strong emotions, hesitations, and contradictions are as informative as the words. If they make a claim about users, note it as a hypothesis to validate in user research, not as a fact.

6. Build a knowledge base incrementally

After each interview, write a brief summary: 3-5 key points, any surprises, and open questions for the next interviews. Unlike user research where you analyze all data at once, stakeholder insights are best processed as you go — each conversation informs the next.

7. Synthesize across interviews

Map where stakeholders agree and where they contradict each other. Which constraints appeared multiple times? Which success metrics conflict? Build an alignment matrix that makes disagreements visible — these are the decisions the team will need to resolve before moving forward.

Present the synthesized findings to stakeholders. Show them the alignment matrix, highlight where perspectives differ, and propose how to resolve key disagreements. This step is often skipped and should not be — stakeholders who feel heard are more likely to support the project.

How AI changes this method

AI compatibility: partial — AI can assist with preparation (researching stakeholders, generating tailored discussion guides), note-taking, and synthesis across interviews, but cannot conduct the interview itself. Stakeholder conversations involve organizational politics, reading between the lines, and building trust — all of which require a human.

What AI can do

Tailored discussion guide generation: Given a stakeholder’s role, background, and the project context, an LLM can draft a customized set of questions in minutes. Phil Morton recommends writing a base guide and then prompting AI to adapt it per stakeholder.
Pre-interview research: AI can summarize a stakeholder’s public profile to help the interviewer prepare sharper, more relevant questions.
Real-time transcription and note-taking: Tools like Otter.ai or Fireflies transcribe the conversation, freeing the interviewer to focus on listening rather than note-taking.
Cross-interview synthesis: After multiple interviews, an LLM can identify recurring themes, contradictions, and gaps, producing a first draft of the alignment matrix.
Communication drafts: AI can draft follow-up emails, summary documents, and stakeholder briefings based on the interview notes.

What requires a human researcher

Conducting the interview: Stakeholder conversations require navigating organizational politics, reading non-verbal cues (evasion, frustration, enthusiasm), and adjusting questions on the fly. Trust-building cannot be delegated.
Interpreting political dynamics: When a VP says “That’s not a priority right now” it may mean the project has no executive support, or it may mean “convince me.” Only a human who understands the organizational context can read this correctly.
Resolving conflicting stakeholder views: The alignment matrix identifies disagreements, but resolving them requires facilitation, compromise, and sometimes difficult conversations that AI cannot mediate.

AI-enhanced workflow

The biggest change AI brings to stakeholder interviews is in preparation and synthesis. Before AI, a researcher would spend 30-60 minutes per stakeholder reading their background and writing tailored questions — for 10 stakeholders, that is 5-10 hours of preparation. With an LLM generating draft discussion guides from a base template and a stakeholder profile, this drops to 15-20 minutes per person, mostly spent reviewing and refining the AI output.

Synthesis also compresses. Instead of manually reviewing 10 sets of notes, tagging themes, and building the alignment matrix from scratch (typically a full day of work), a researcher can feed all interview summaries to an LLM and get a draft matrix in an hour. The researcher then verifies it against their own session notes and adjusts where the AI missed nuance — especially around political dynamics communicated through tone rather than words.

The interview itself does not change. A 30-minute conversation with a VP remains a 30-minute conversation with a VP, and the interpersonal skills required to make it productive remain entirely human.

Tools

Scheduling: Calendly (self-scheduling links reduce back-and-forth), Google Calendar (if within the same organization)
Recording and transcription: Otter.ai (real-time transcription with speaker labels), Fireflies.ai (automated meeting notes), Zoom (built-in recording + transcription)
Note-taking: Notion (structured interview note templates), Google Docs (collaborative notes), Miro (for building stakeholder maps live)
Analysis and synthesis: Dovetail (coding and tagging across interviews), Miro (alignment matrices, stakeholder maps), FigJam (visual synthesis boards)
AI-assisted: ChatGPT or Claude (tailored discussion guides, cross-interview synthesis), NotebookLM (query across all transcripts)
Stakeholder mapping: Miro stakeholder map template, Xtensio (stakeholder persona cards), a simple 2x2 power/interest grid in any whiteboard tool

Works well with

In-depth interviews reveal what users need; stakeholder interviews reveal what the business needs. Running both ensures the research plan addresses both sides.
Surveys capture stakeholder perspectives at scale when there are too many to interview one-on-one (15+), with follow-up interviews for the most influential voices.
Journey mapping validates whether users agree with the touchpoints stakeholders consider critical, and where the real friction lies.
Desk research before stakeholder interviews arms the interviewer with market, competitor, and internal metric context to ask better questions.
Persona building benefits from documenting stakeholders’ assumed personas during interviews, then validating or refuting them through user research.

Example from practice

A fintech company was redesigning its mobile banking app. The design team planned to start with user research, but ran stakeholder interviews first. They interviewed 8 people: the head of product, the head of engineering, two compliance officers, the customer support lead, the marketing director, the CEO, and a branch manager.

The interviews uncovered a constraint that would have derailed the project: the compliance team was implementing new regulatory requirements that would change how account information could be displayed. Engineering also revealed that a backend migration, scheduled for the same quarter, would make certain features temporarily unavailable. Neither constraint was documented anywhere the design team could access.

The alignment matrix showed that the CEO wanted a “bold redesign,” the head of product wanted incremental improvements to reduce support tickets, and the compliance team wanted minimal changes until regulatory requirements were finalized. The team used these findings to scope the redesign into two phases: a first phase addressing the top support-ticket issues without touching regulated screens, and a second phase after compliance and backend work was complete. This phased approach satisfied all three perspectives and avoided designing screens that compliance would later reject.

Beginner mistakes

Treating stakeholder interviews like user interviews

Stakeholder interviews are not about discovering needs through open exploration — they are about gathering specific organizational knowledge. The interviewer should research each stakeholder in advance, tailor questions to their role, and enter the conversation already knowing the basics. Asking a CTO and a marketing lead the same generic questions wastes both their time and yours.

Interviewing stakeholders in a group

Group interviews cause stakeholders to defer to the most senior person in the room. A VP’s opinion will suppress a team lead’s honest concerns. Always conduct stakeholder interviews one-on-one to get unfiltered perspectives. If a group workshop is needed to resolve disagreements, it should come after individual interviews.

Taking stakeholder claims about users as facts

Stakeholders often say things like “Our users want a mobile app” or “Customers care most about speed.” These are hypotheses, not research findings. Note them carefully, but do not act on them without validation through actual user research. The alignment matrix should have a dedicated section for “user assumptions to validate.”

Skipping the feedback loop

Many teams conduct stakeholder interviews, extract what they need, and move on without sharing findings. Stakeholders who feel unheard become obstacles later. Always close the loop with a briefing document or a short presentation showing how stakeholder input shaped the research plan and project direction.

Waiting too long to start

The most common mistake is beginning stakeholder interviews after the research plan is already written or after design work has started. At that point, the interviews become a formality rather than a genuine input. Run stakeholder interviews at the very beginning of a project.

AI prompts for this method

4 ready-to-use AI prompts with placeholders — copy-paste and fill in with your context. See all prompts for stakeholder interviews →.