Prepare Elicitation Sessions with Question Guides and Straw-Man Models

Workflow area: Elicitation & Discovery · Tier: Foundation · Hands-on time: ~20 minutes

An unprepared elicitation session produces vague answers to vague questions. A well-prepared one walks in with two artifacts: a question guide tuned to the stakeholder's role and vocabulary, and a straw-man — a first-draft process sketch or requirements outline that is intentionally incomplete and confidently wrong in a few places. People who cannot articulate their process from a blank page will instantly tell you why your diagram is wrong, and the corrections are higher-fidelity evidence than any open-ended answer. AI makes both artifacts a twenty-minute job instead of an evening one.

When to use — and when not to

• Use it before any structured elicitationstakeholder interviews, requirements workshops, process discovery walkthroughs, especially in a domain you are still learning.
• Use it when stakeholders "don't have time"a session anchored on a straw-man gets to substance in minutes, and busy operators respect preparation.
• Use it when specifying from scratch has stalledif two sessions of "tell me about your process" produced fog, switch to correction mode.
• Skip it for exploratory first conversationswhen you genuinely know nothing, a straw-man built on nothing anchors the stakeholder on fiction; run one open listening session first.
• Skip the straw-man with politically defensive audiencesa stakeholder who suspects the project threatens their team may read a wrong diagram as an accusation. Bring questions only, and build the model with them live.

The recipe

1. 1.

   Gather what you already know. Pull the project brief, any prior notes, org chart context, and the stakeholder's role. Thin input is fine — the straw-man is supposed to be imperfect — but the model should know the industry and the process's rough purpose.

2. 2.

   Generate the role-specific question guide.

   Copy

   You are helping a business analyst prepare a 45-minute elicitation
   session.
   Project: [ONE LINE — e.g. "streamlining claims intake at a mid-size
   insurer"]
   Stakeholder: [ROLE + STAKE — e.g. "claims team supervisor, 12 direct
   reports, measured on cycle time and leakage"]
   What we know so far: [PASTE NOTES OR "very little"]
   
   Produce:
   1. SESSION GOAL — one sentence stating what decision or artifact
      this session must enable.
   2. QUESTION GUIDE — 10-14 questions in interview order: warm-up,
      core process, exceptions and workarounds, volumes and metrics,
      pain and priorities. Phrase questions in the stakeholder's
      vocabulary, open-ended, one topic each. No leading questions.
   3. FOLLOW-UP PROBES — for each core question, one probe to use if
      the answer is vague ("walk me through the last time that
      happened").
   4. LANDMINES — 3 topics likely to be sensitive for this role and
      how to approach each.
   
   Rules: questions must be answerable from lived experience, not
   opinion ("what happens when X?" not "what should happen?").
   

3. 3.

   Generate the straw-man model as text. Ask for a textual process sketch you can redraw in Miro or Lucid in five minutes:

   Copy

   Using the same context, draft a STRAW-MAN model of the [PROCESS
   NAME] process for the stakeholder to correct.
   
   Format:
   - Numbered main flow: actor — step — system, one line per step.
   - EXCEPTIONS: 3-5 exception paths you would expect in this domain,
     each marked (ASSUMED).
   - Mark every step you inferred rather than sourced with (ASSUMED).
   - Deliberately include 2-3 plausible-but-probably-wrong details
     (wrong sequence, wrong owner, missing handoff) and list them
     separately at the end under PLANTED ERRORS so I know which they
     are.
   
   Keep it under 20 steps. This will be shown to the stakeholder as
   "our current wrong understanding — please fix it."
   

4. 4.

   Review the sample output and stage the session. Good output looks like:

   Copy

   STRAW-MAN: Claims intake (current understanding — please correct)
   1. Customer — submits claim via portal or phone — CRM
   2. Intake clerk — checks policy validity — PolicyDB (ASSUMED)
   3. Intake clerk — assigns severity code — spreadsheet (ASSUMED)
   4. Supervisor — approves claims over $10k — email
   
   PLANTED ERRORS
   - Step 4 threshold guessed at $10k; sequence of 2/3 may be swapped.
   

   Redraw the flow in Miro (Miro AI can turn the numbered list into a diagram directly), keep the (ASSUMED) tags visible, and delete the PLANTED ERRORS list from anything the stakeholder sees — the errors work only if they look sincere.

5. 5.

   Run the session in correction mode. Open with the goal, show the straw-man early, and say the magic sentence: "This is our current understanding and parts of it are definitely wrong — where?" Capture every correction verbatim; each one is an elicited fact with an owner. Use the question guide to cover whatever the corrections did not reach, and the probes when answers go abstract.

6. 6.

   Log corrections as findings. After the session, list every correction as: what we thought — what is actually true — who said so. This table feeds straight into pb-01's synthesis and is your evidence trail.

Make it yours

• Claude Project per engagement: keep project context, glossary, and prior session findings in a Project; each new question guide then builds on what previous sessions established instead of re-asking it.
• ChatGPT voice mode for rehearsal: read your questions aloud against the model playing the stakeholder role for ten minutes — awkward phrasings surface immediately (full rehearsal technique is pb-13).
• Miro AI at workshop scale: for group workshops, have Miro AI generate the straw-man directly on the board as sticky-note flows, so participants correct by moving and annotating stickies — the board becomes the finding log.
• Gemini in Docs for shared prep: teams standardizing on Workspace can run the same prompts in a shared Doc so the guide is co-edited by the project team before the session.

Quality check

• Every question is answerable from experiencerewrite anything that invites opinion or design ("should" is the tell).
• The straw-man's assumptions are visible(ASSUMED) tags stay on; a straw-man that hides its guesses becomes accidental misinformation.
• Planted errors are tracked privatelyyou know exactly which details were bait, so an uncorrected planted error becomes a follow-up question, never a fact.
• Nothing invented survived unchallengedafter the session, any straw-man step the stakeholder did not explicitly confirm or correct stays (ASSUMED); silence is not validation.
• Corrections were captured with attributioneach one traces to the stakeholder who made it, ready for pb-01's citation discipline.