Requirements Elicitation with AI: Interview Guides That Do Not Sound Generic

I used to walk into discovery meetings with a half-finished question list and a lot of confidence that I would "just listen." Listening matters. Showing up underprepared does not.

The other extreme is worse. A twenty-page generic interview guide that sounds like it was copied from a BA textbook. Stakeholders can hear it. They answer in slogans. You leave with notes that feel complete and still do not tell you how the work actually runs on a Thursday afternoon when the usual person is on leave.

AI sits awkwardly between those two habits. Used badly, it gives you more generic questions faster. Used with a real context pack, it can help you walk in with sharper prompts, then leave room for the answers that were never on the script.

What I mean by a context pack

Before I ask a model to draft interview questions, I try to feed it something concrete. Not "we are building a portal." Something closer to the messy pile a BA already collects:

• Project one-pager or charter draft
• Process notes or a rough swimlane
• Known systems and data owners
• Prior tickets, complaints, or audit findings
• Org chart snippets: who decides, who uses, who blocks
• Constraints you already know (compliance, budget, go-live window)

If that material is thin, the interview guide will be thin. Models are good at sounding thorough. They are not good at inventing your company's real friction. When the pack is stronger, often because someone has been doing the boring work of gathering docs and process fragments, the questions get more specific. That is the same discipline behind company-specific knowledge for AI: context in, useful output out.

How I use AI on the pack

I do not ask for "fifty great stakeholder questions." I ask for something I can edit in twenty minutes:

• Questions grouped by role (ops, finance, IT, customer-facing)
• Questions that probe current workarounds, not only the happy path
• Questions that surface decisions, approvals, and exception handling
• Questions that expose data definitions people think they share but do not
• Follow-ups if someone says "it depends" or "the system does that automatically"

Then I cut half of it. Generic openers go. Anything that assumes a solution already exists goes. Anything that would make a senior person feel interrogated by a junior checklist gets rephrased into a peer conversation.

I also ask the model for risks in the guide itself. Where might these questions lead the stakeholder? Where am I fishing for confirmation instead of discovery? That self-critique is often more useful than the first draft.

What the guide is for (and what it is not)

An interview guide is a safety net, not a script. I want enough structure that I do not waste the only hour I get with a busy operations lead. I also want enough flexibility that when they say something odd, I can abandon the list.

Odd answers are usually the ones that change the solution. Someone admits the official process is only for audits. Someone names a spreadsheet that never appears in architecture diagrams. Someone describes a three-day delay caused by a person who is not on the stakeholder list. AI will not hear that in the room. You will, if you are not staring at your printed questions.

A simple prep ritual that tends to work

1. Build the pack from real artifacts, even if incomplete.
2. Draft questions by role with AI, then mark which ones you must ask versus nice-to-have.
3. Add your own "listen for" notes: language people use, places they get vague, topics they avoid.
4. Plan silence. Leave gaps. The unscripted detail often arrives after the tidy answer.
5. Debrief the same day. Capture contradictions and open questions before they blur.

If you want a light place to park follow-ups and owners after sessions, something simple like the free Agile and Waterfall project tool can hold a discovery backlog without turning prep into another heavy tool rollout.

Failure modes I watch for

AI-assisted elicitation fails in predictable ways:

• Context-free polish. Beautiful questions that could apply to any company in any industry.
• Solution smuggling. Questions that assume a chatbot, a portal, or a workflow product before anyone agreed.
• Persona cosplay. Invented user types that nobody in the org would recognize.
• Checklist theatre. You "covered" every topic and still cannot explain a single end-to-end path with real data.
• Overtrust in transcripts. Summaries of the meeting can be handy. They are not a substitute for judgment about what mattered.

When any of those show up, I go back to the pack and to the people. The model is a drafting partner. The BA still owns what gets asked, what gets believed, and what becomes a requirement.

Why this still belongs to business analysis

Elicitation has always been part craft, part discipline. AI does not remove the need for either. It can compress the time from "I have some documents" to "I have a role-aware question set I can defend." That is useful, especially when timelines are short and stakeholders are scarce.

It does not replace sitting with people who do the work. It does not replace noticing when two departments define "customer" differently. It does not replace the uncomfortable follow-up when someone says the process is fine and their metrics say otherwise.

If anything, stronger prep can free you to listen harder in the room. That is the point. Not more questions. Better ones, then the courage to abandon them when the real story shows up. The same BA skills that map to AI delivery more broadly, which I wrote about in why business analysts are built for AI, still apply here: structure first, then judgment.

Walk in prepared. Stay curious. Let the unscripted answer change the design when it should.