Stakeholder Discovery and Interviewing

What discovery is, and what it is not

Discovery is the first thing an FDE does on a new engagement and the first thing they get wrong. Most engineers, dropped into a customer site, default to one of two failure modes:

1. Premature solutioning — they hear “we have a data problem,” reach for the platform they know, and start building Monday afternoon.
2. Eternal listening — they take notes for three weeks, never converge, and the customer loses faith.

Discovery is the disciplined practice of avoiding both. It is a short, intense period — usually 5 to 10 working days — in which you build enough understanding of the customer’s organization, workflow, and constraints to commit to a single, specific, defensible first thing to build.

Discovery is not a feature spec. It is not requirements gathering. It is closer to investigative journalism: you arrive ignorant, you talk to many people, you discount everyone’s first answer, and you converge on a story you can defend.

The stakeholder map

Before you can interview people, you need to know who exists. In your first 48 hours you should draw — on paper or a whiteboard — a stakeholder map of the customer’s relevant org. Three concentric rings:

     ┌─────────────────────────────────┐
     │      Sponsors (the why)         │
     │  ┌───────────────────────────┐  │
     │  │   Users (the what)        │  │
     │  │  ┌─────────────────────┐  │  │
     │  │  │ Gatekeepers (the    │  │  │
     │  │  │ no)                 │  │  │
     │  │  └─────────────────────┘  │  │
     │  └───────────────────────────┘  │
     └─────────────────────────────────┘

Sponsors — the people who care if you succeed

Usually one or two executives. They have a number they need to move. They signed the contract or championed it. They will not use the software you build, but they will fund the next phase if it works.

For Northbound Freight: the VP of Operations (whose on-time delivery KPI is at 78% and needs to hit 92%) and probably the CEO behind her.

Users — the people who will (or won’t) use what you ship

The operators. They know the workflow better than anyone. They are often suspicious of you, sometimes correctly. Their adoption is the deliverable.

For Northbound: the dispatcher (3 of them, working in shifts), the drivers (40 of them, mostly indifferent to anything that happens in an office), and the ops admin who runs the daily kickoff meeting.

Gatekeepers — the people who can quietly kill the project

IT, security, procurement, legal, finance, sometimes a senior architect with a competing project. They will not appear on the kickoff agenda. You have to find them.

For Northbound: the IT director (whose team owns the SAP integration and is overworked), the InfoSec lead (who has not approved a new SaaS vendor in 18 months), the finance manager (who wonders why the contract is structured the way it is), and a senior developer (who has been quietly building an in-house version of what you propose to deliver).

If you skip any ring, you fail in a predictable way:

Building the map

Your first day on site, ask three people from three different parts of the org: “If we are going to build this thing in 8 weeks, who do I absolutely need to talk to?” Each will give you 4–6 names. Cross-reference the lists. The names that appear on all three are your gatekeepers — and the ones nobody mentioned but you can guess exist (InfoSec, procurement) you flush out yourself.

By end of day 3 you should have a one-page list of every person you intend to interview, grouped by ring, with the next interview booked for each.

The three interview types

Each ring takes a different interview. Trying to run the same script on all three is the most common discovery mistake.

Sponsor interviews — get the why

Goal: understand the business outcome they are buying. Confirm the number. Surface the political context.

Length: 30–45 minutes. Executives do not give you more.

Question shape:

• “What does success look like in 90 days?”
• “What is the metric I will be measured on at the end of this?”
• “Who else inside the company has tried to solve this, and what happened?”
• “What would cause you to pull the plug on this engagement?”
• “Who, when this works, becomes a hero — and who looks bad?”

That last one is the political question. Always ask it. The answer tells you who will quietly cheer for you and who will quietly root against you.

User interviews — get the what

Goal: understand the actual workflow. Identify the friction. Map the tools they really use (not the ones IT says they use).

Length: 45–90 minutes. Schedule generously — users have more to say than they will tell you in the first 20 minutes.

Question shape:

• “Walk me through what you did this morning, step by step.” (Do not interrupt for the first 5 minutes.)
• “Show me the screens you used.” (Have them share their actual screen, not a clean test environment.)
• “What is the worst day you’ve had in the last month? What happened?”
• “If you had a magic wand, what would you change?” (The answer is usually wrong. But the question opens them up.)
• “What part of the job did you hate teaching the new person on your team?”

The “walk me through this morning” question is the most valuable single tool in your kit. Concrete, recent, specific. People narrate accurately when they are remembering. They confabulate when they are generalizing.

Gatekeeper interviews — find the no

Goal: learn what will stop the project, and start de-risking it before you need to.

Length: 30–60 minutes. They are busy and suspicious. Be respectful of their time.

Question shape:

• “What’s your team’s involvement in projects like this typically?”
• “What standards / controls / approvals does anything new have to pass?”
• “What recent projects have or haven’t passed?” (You want the failure stories.)
• “What is your biggest concern about this engagement?”
• “What can I do this week to make your life easier in 8 weeks?”

That last one matters. Gatekeepers are usually willing to help — they just are not used to anyone asking. A two-minute task you do for the IT director in week 1 may buy you a smooth deployment review in week 8.

How to actually run an interview

A few craft rules, learned painfully:

Use a paper notebook

People talk more freely to someone with a pen than someone behind a laptop. Type your notes up at the end of the day. If you absolutely must take notes on a laptop, sit so the customer cannot see the screen — and warn them you are taking notes, not multitasking.

Two ears, one mouth, and a clock

You should talk for roughly 20% of the interview. Junior FDEs talk for 60%. This is the single biggest fix to make.

A useful self-check: every 10 minutes, glance at the clock. If you have not asked an open-ended question in the last 5 minutes, you are talking too much.

Ask “and then what?” relentlessly

The most useful follow-up question in the world is “and then what happened?” It pushes a story past the surface narrative into the actual mechanics of how things go wrong. Use it liberally.

Echo, don’t summarize

When someone says “the SAP integration is unreliable,” do not respond with a paraphrase (“so SAP is broken?”). Echo a piece of their phrase back as a question: “Unreliable how?” This gets you their specific story, not your interpretation of it.

Capture verbatim quotes

When someone says something striking, write down the exact words. Verbatim quotes are 10x more persuasive in your week 1 readout than your paraphrase will be.

End with two specific asks

Before you leave: (1) ask for one document/system/dataset you should look at next, and (2) ask for one other person you should talk to. You are building the map as you go.

The 30-minute write-up

After every interview, before your next one, you write a 30-minute write-up:

• Date, person, role
• 3 most important things they said (verbatim where possible)
• 1 thing that surprised you
• 1 thing that contradicts what someone else said
• 2 follow-up questions for next time
• New names / systems / docs they mentioned

Write it the day of the interview, not the next morning. Memory decays fast.

By end of week 1 you should have 6–10 write-ups, totaling maybe 15 pages of notes. This is the raw material for your problem statement.

The lies you will hear (and the truths beneath them)

People do not lie to you on purpose. They tell you the version of the truth that is easy to say. Your job is to triangulate to what is actually going on.

None of these are character flaws. They are normal organizational defenses. Triangulate. Cross-reference. Trust the user’s behavior over their words.

A Northbound interview — worked example

You are in week 1 at Northbound Freight. You have 60 minutes with Maria, the senior dispatcher.

You: “Walk me through what you did this morning, starting when you sat down.”

Maria: “OK, so I came in at 5:30. I open Lotus Notes, then I open the SAP load board, then I open my spreadsheet. The spreadsheet is the master.”

(You write down: SAP, Notes, spreadsheet-is-master. You do not interrupt.)

Maria: “I check the overnight loads — there were 47 last night. I look at each one in SAP, copy the load ID and ETA into the spreadsheet, then I check the GPS portal — it’s a different system — and update the ETA if the truck isn’t where SAP says it is.”

You: “And then what happened?”

Maria: “Then I call Doug. Doug runs the east hub. If any of his loads are slipping he wants to know before 7 so he can re-staff. I call him every morning at 6:45.”

You: “Are there mornings when something goes wrong?”

Maria: “Tuesday this week was a mess. The GPS portal was down. I called the drivers directly. Three of them didn’t pick up. I had to guess on their ETAs and tell Doug to plan for two extra people.”

(You write down: GPS portal SPOF, manual driver calls, Doug needs ETA delta by 6:45, “guess on ETAs” = high-cost moment.)

You: “When you say guess — how do you make that guess?”

Maria: “I look at when they checked in at the last hub and where they are supposed to be next. I know most of them. Some of them are always late, some always early.”

(You write down verbatim: “I know most of them.”)

You: “If you had a magic wand?”

Maria: “I’d just have one screen. One. And I’d have it tell me by 6:30 which loads are slipping enough that Doug needs to know.”

(You write down: “one screen by 6:30.”)

Three things you now know that no spec writer would have given you:

1. There is a morning batch ritual at 6:45 that anchors the dispatcher’s day.
2. There is a tacit ranking of driver reliability that lives in Maria’s head and nowhere else.
3. The GPS portal is a SPOF whose failure forces a manual fallback.

Any one of those three is a candidate problem statement for the first MVP loop.

Converging to a problem statement

By end of week 1 you have stacks of notes. You now compress everything into a single one-paragraph problem statement that you can defend, in writing, to both the VP and to Maria. A good problem statement has:

• A specific person whose work changes (Maria, the senior dispatcher)
• A specific moment where the pain shows up (6:30 AM batch ritual)
• A specific friction to remove (three screens, manual copy, ETA guessing)
• A measurable outcome (which loads are slipping by 6:30; Doug staffs accurately)
• A bounded first step (one screen, dispatcher only, read-only, first slice of data)

The Northbound week-1 problem statement might read:

Every morning, senior dispatcher Maria spends 45 minutes manually consolidating SAP, the GPS portal, and her spreadsheet to identify which loads are slipping ETAs by 6:45, when she calls hub manager Doug. Our first iteration will replace this manual batch ritual with a single, read-only “morning view” screen, available by 6:30 AM, showing all active loads with their live ETA delta against plan, sorted by slip. We will measure success by whether Maria opens it before her Doug call for two consecutive weeks.

That is what discovery produces. Not a backlog. Not a roadmap. One paragraph that the sponsor, the user, and the gatekeeper can all read and agree to.

When discovery should stop

A useful test: at the end of each day of discovery, ask yourself “could I write today’s problem statement?” If yes for two days in a row, stop discovering and start building. You will learn the rest of what you need to know by trying.

A common mistake is treating discovery as a phase you complete before building. It is not — it is a tap you turn down once you have signal, and re-open whenever the build hits a question. Healthy engagements run small discovery threads alongside the build for the entire engagement.

Key terms to remember

• Stakeholder map — the three-ring diagram of sponsors, users, gatekeepers
• Sponsor interview — short, executive-level, focused on outcomes and politics
• User interview — longer, operator-level, focused on actual workflow
• Gatekeeper interview — defensive interview to surface what will stop you
• Walk-me-through-this-morning — the highest-leverage single question
• 30-minute write-up — same-day distillation of each interview
• Problem statement — the one-paragraph artifact discovery produces

What’s next

You now know how to find the right people and extract signal from them. The next step is turning that signal into a typed domain model — moving from prose interview notes to a structured ontology your team can build against. That is domain capture, and it is the FDE’s most leveraged single craft.