Consultative Discovery and Requirements Gathering Questions

Direct answer

I start broad and end narrow, then widen again to close. A broad (open-ended) question invites a story or opinion ("walk me through..."). A narrow (confirming) question checks a specific fact, rule or number that I have a reason to believe but need to verify. Broad questions find what I did not know to ask. Narrow questions pin down what matters for the checkout redesign. I switch when a theme appears or when answers go flat. A stakeholder is anyone with a stake in the outcome, such as the product owner or an engineering lead whose work checkout changes.

A shape for a 45-minute stakeholder interview

Examples of broad questions

• "Walk me through what happens today when a customer checks out."
• "What is the biggest headache with checkout from your team's side?"
• "What would make this redesign a success a year from now?"
• "What worries you about changing it?"

Examples of narrow, confirming questions

• "You mentioned payments time out. Which provider, and how often does that happen?"
• "Is guest checkout something we must keep?"
• "Which payment methods must stay in the new design?"
• "Does the same-day shipping cutoff apply to every region?"

I keep narrow questions neutral. "Don't you think guest checkout should go?" leads the answer, while "Is guest checkout something we must keep?" does not.

When to switch

• Broad to narrow: a theme repeats, or someone names a number, a rule or a dependency worth verifying.
• Narrow back to broad: an answer surprises me, answers become short and rehearsed, or I realise I am confirming my own guess.
• Different audiences: product stakeholders get more questions on goals, metrics and trade-offs. Engineering stakeholders get more on legacy limits, dependencies and what is costly to change.

Pitfalls

Going narrow too early anchors the conversation on my guess, and staying broad for the whole hour leaves me with stories and no verified facts.

Direct answer

I make discovery (the early conversations and research that establish what to build) asynchronous-first, meaning input is gathered in writing or recordings on each person's own time, and use live time only for what needs conversation. Written prompts and short recordings gather most input on each person's own schedule, one-to-one interviews at reasonable local hours replace the big all-hands workshop, and a single shared document holds findings, assumptions, open questions and decisions. Fatigue is managed by capping meeting length, rotating who takes the awkward time slot, and giving every request a clear reply deadline so nobody is left waiting or watching.

Step by step

1. Map people and overlap first. List each stakeholder (anyone who is affected by or can influence the outcome), their location and working hours. Find the real overlap window before scheduling anything.
2. Send a written pre-read. One page: the goal, what you already believe (labelled as assumptions), and 5 to 7 specific questions, each with a one-line reason ("I am asking because the answer decides whether we need a second integration"). Ask for replies within a stated window, for example 48 hours, so async does not become indefinite.
3. Run one-to-one interviews, not one big session. 30 to 45 minutes each, at a time reasonable for the interviewee. One-to-ones also surface views people will not voice in a crowded call. Record with consent and take notes in the shared document straight afterwards.
4. Use one live session only for conflicts. After synthesis (combining what you heard into themes), hold a single short call where stakeholders resolve the points on which their inputs disagree. Record it and write up the outcome the same day.
5. Keep one living document. Sections: findings, assumptions, open questions (each with an owner and a due date), decisions made. Stakeholders comment in it. Say the default out loud: "If I hear no objection by Friday, I will treat this as agreed", and then record it.
6. Close the loop in writing. After each round, send a five-line summary: what we learned, what changed, what is still open, what I need from you.

Worked example (clock times in northern summer, computed)

Stakeholders sit in London, Bengaluru and San Francisco.

• 09:00 London is 13:30 Bengaluru and 01:00 San Francisco.
• There is no overlap in ordinary 09:00 to 17:00 working hours for all three: San Francisco's 09:00 is 17:00 in London and 21:30 in Bengaluru. The least-bad shared window is a narrow band around 16:00 London, where 16:00 is 20:30 Bengaluru and 08:00 San Francisco (15:30 is 20:00 and 07:30; 16:30 is 21:00 and 08:30). I pick 16:00 because it is early morning for one team and evening for the other, rather than night for either. In Bengaluru that is an evening slot (20:30) and in San Francisco an early-morning one (08:00).

So I run that three-way call once, for conflict resolution only, and offer the Bengaluru stakeholders the choice of attending live or reviewing the recording and answering in writing by a deadline. Interviews with Bengaluru are held at 09:00 London time (13:30 in India); San Francisco interviews at 16:00 London time (morning there). If another session is needed, it is the San Francisco team who shift earlier or the Bengaluru team who stay later, in turn, so the burden rotates and is visible.

Keeping people aligned without exhausting them

• Meeting cap: nothing live over about 45 minutes, and no recurring status call; the document is the status.
• Rotate the inconvenient slot and say so openly.
• Send fewer, better-targeted requests: ask each person only the questions they uniquely can answer.
• Make asynchronous input low effort: a short form, or a voice note, rather than a long essay.

Trade-offs and pitfalls

• Async is slower per question, so start earlier and plan two rounds, not one.
• Text loses tone and misses tacit knowledge (things people know but would not think to write down). For the highest-stakes stakeholders, still do a live one-to-one.
• Silence is not agreement. A deadline default helps, but follow up personally with anyone whose input is critical and absent.
• Do not let one time zone always carry the cost: it hurts quality and goodwill.

Direct answer

Discovery is the early research and conversations done before building, and its findings stay identical for every audience; the framing changes. Executives (the people who fund and decide) need the decision, the outcome, the risk and the ask. Engineers (the people who build and run it) need the constraints, the data, the edge cases and the open technical questions. I lead each audience with what they must act on, and I leave out the detail the other audience would have to wade through. I never change a finding to suit a listener; I change its order, its language and its depth.

What changes for each audience

Leave out, by audience

• For executives: the full interview log, tool and schema internals, and every minor finding. Keep them in an appendix, not the story.
• For engineers: market sizing, the political history behind the project, and slides that justify the project's existence (they usually already know they are building it).

One meeting with both audiences

1. Open (2 minutes): one headline slide that both groups can read: the problem, the top three findings, the decision needed.
2. Executive layer first: outcome, risk, ask. Executives get their answer early, then can leave or stay quiet.
3. Engineering layer next: say it explicitly ("Engineers, this is the detail behind finding 2") so each group knows which part is theirs. Use a diagram of the current flow with the problem steps marked.
4. Language: define any term the other group may not know the first time it appears. Say "customers cannot finish setup" before "the import job times out".
5. Visuals: one decision slide, one flow diagram, and an appendix of evidence. Avoid dense tables on the main path.
6. Q&A: take executive questions ("how sure are we, what does it cost, what happens if we wait?") before the engineering ones. Put deep technical threads in a parking lot and a follow-up session so they do not eat the executives' time.

Worked example

Discovery for a rebuilt customer-onboarding flow found three things: (a) new customers wait on manual data imports before they see value, (b) two legacy systems disagree on customer IDs, (c) the support team uses an undocumented spreadsheet to fix failed imports.

• Executive version: "Onboarding stalls on manual imports, which delays the point where a customer sees value. We recommend fixing the import path first. It carries one dependency risk (conflicting customer IDs) that needs a data-owner decision from you by the end of the month. Confidence: high on the delay (every interviewed customer mentioned it), medium on the fix duration (not yet scoped)."
• Engineering version: "Imports fail on the cases the support spreadsheet patches by hand. Here is the list of patches, the two ID formats, and the three questions we cannot design around until answered. Confidence: high that manual imports are the delay (every interviewed customer mentioned it), medium on the fix duration (not yet scoped)."

Same three findings, same confidence levels, different first sentence and depth. The executive version compresses finding (c), the undocumented spreadsheet, into the single phrase "manual imports" and leaves the spreadsheet detail to the appendix, but it does not drop it or change its weight.

Trade-offs and pitfalls

• Two decks can drift into two versions of the truth. Keep one source document, with the executive view as its summary.
• Over-simplifying for executives hides real uncertainty; label confidence instead of removing the caveat.
• Reading the engineering deck to executives is the commonest failure. If an executive asks a technical question, answer in one sentence and offer the detail afterwards.
• Hiding a risk because it is awkward for one audience is a different thing from omitting detail. Omit detail freely; never omit a material risk.

Direct answer

In 30 minutes I anchor the session on one real example, not on abstract requirements: the walk-through (8 minutes) and the edge cases drawn from it (7 minutes) take 15 of the 30 minutes. I spend a few minutes on purpose and audience, then the largest block walking a recent case, then edge cases, then data sources, and I read back what I heard. I ask open questions first and narrow after.

Structure of the session

Questions that surface needs, edge cases and data sources

Needs

• "Walk me through the last time you used a report like this. What did you do with it?"
• "What do you look at first? What do you ignore?"

Edge cases

• "When did the last report surprise you or turn out wrong?"
• "Which customers or periods are treated differently?"
• "What would make you say this row should not be here?"

Data sources

• "Where does that number come from today? Who owns it?"
• "Which source do you trust, and when does it disagree with another?"

Probing a vague answer

"We need it by region." Reply: "Which region definition (sales territory or shipping zone), and what would you do differently when one region is down?"

Turning an assumption into a testable hypothesis

Requests often hide assumptions. Use a small conversion template: request, assumption, hypothesis, test.

Example (illustrative numbers): Request: "Show churn by region." (Churn is the share of customers who stop using or paying in a period. To segment is to split customers into groups, here by region.) Assumption: churn differs meaningfully by region, and regions are managed separately. Hypothesis: at least one region's monthly churn is at least 1.5 times the company average. If the company average is 2%, that means a region at 3% or more (I agree the 1.5x threshold with the expert before looking at data). Test: segment 12 months of churn by region. Pass: one or more regions at 3% or above in most months, so the regional cut is worth building. Fail: every region stays between about 1.8% and 2.3%, so the regional cut adds little and I propose another cut, such as plan type. Anything in between (for example one region at 2.5% in most months) is inconclusive: it neither meets the agreed 3% line nor shows a flat picture, so I agree with the expert beforehand whether that band justifies the cut or whether we look at a longer window or a second cut.

What I write down

The need in one sentence, edge cases with examples, the data sources and owners, assumptions, and open questions. I send them back the same day.

Trade-offs and pitfalls

• Listing features instead of seeing real use.
• Closed questions ("do you need a filter?") get "yes" to everything.
• Running over time with no read-back, so nothing is confirmed.
• Treating the first source named as the only source.

Direct answer

I take notes that separate what people said from what I saw and what I think it means, and I keep a running list of decisions, assumptions, open questions and action items with owners. I send a clean version the same day (at the latest within 24 hours) and ask for corrections by a named date. Notes that sit in a personal notebook cannot be checked by anyone else.

What I capture, beyond the words

Alongside that: decisions made, assumptions I am relying on, open questions, and actions with owner and date. Keep verbatim quotes and inferred needs apart, so a reader can tell the stakeholder's words from my guess.

A findings record (CRM-style, one row per finding)

Customer relationship management (CRM) tools store a structured record for each contact, account or deal, with every interaction logged against it. The same idea works here, with one row per finding: ID, date, source (person and role), the finding, its type (need, constraint or assumption), the supporting quote, confidence, status and owner. Searching "all constraints from finance" is then easy.

For business intelligence (BI) requirements meetings

A fixed template helps: the report's purpose and audience, the metric definitions, filters, refresh frequency, source tables, and who signs off. Add reproducibility notes: which dashboard or data snapshot (with its date) we looked at, the query or its version, and the assumptions behind any number quoted in the room. Someone should be able to rerun what was shown.

Worked example

Said: "Active customer means anyone who ordered recently." (Priya, finance). Observed: she opened a spreadsheet that excludes refunds. Inferred (mine): "recently" may be 90 days, to confirm. Open question: is 90 days the agreed window? Action: I confirm the window with Priya by Friday.

How soon to share

The same day, while people still remember the conversation. Include the line "Reply by Friday if anything is wrong; otherwise I will treat this as agreed." That line covers the recorded decisions and quotes. Items marked Inferred or Open question stay open until the named person confirms them, so silence never turns a guess into a requirement.

Trade-offs and pitfalls

• Transcribing everything instead of marking what matters.
• Mixing quotes and inference, so guesses harden into "requirements".
• Actions without owners or dates.
• Writing in private shorthand nobody else can read.