Consultative Discovery and Requirements Gathering Questions

Direct answer

A requirements checklist records what people say they want. Real discovery (the early phase of investigating a problem before deciding on a solution) works out the problem behind the request: who has it, why it matters, what constraints surround it, and what nobody has said out loud. In discovery you leave with a shared, written understanding that the stakeholders have confirmed, not just a list. Analogy: a doctor does not hand you a menu of treatments. She asks about symptoms, history and goals before prescribing.

Checklist versus discovery

Who to involve

• The sponsor or decision-maker (who pays and signs off).
• End users (who live with the problem daily).
• Subject-matter experts, or SMEs (people who hold deep knowledge of the process or rules).
• Operators and support (who run and fix it).
• Technical owners and gatekeepers (people who control access or approval, such as security or IT).
• Downstream consumers of the output (people or systems that use what the work produces, such as a finance team reading exported numbers).

Outcomes I aim to leave with

1. A one-sentence problem statement and how success will be measured.
2. Confirmed shared understanding, played back and agreed.
3. Acceptance criteria (conditions the delivered work must meet to be accepted) that the stakeholders have validated.
4. Assumptions and open questions, each with an owner.
5. Knowing who decides, and where stakeholders disagree.
6. Whether the work is worth pursuing at all: a shared picture of the problem, its size and its constraints, enough to say go, reshape or stop. The emphasis shifts with the role. A sales engineer (a pre-sales technical specialist who helps a customer judge whether a product fits) leaves with enough of the customer's problem to judge whether the product fits. An account manager (who owns the ongoing relationship with a customer) leaves with the validated acceptance criteria from outcome 3 and the sign-off owner from outcome 5, so the customer relationship is not surprised later.

Worked example

A manager asks for "a dashboard with 12 charts". A checklist would list the 12 charts. In discovery I ask what decision the dashboard supports and learn the real need is a weekly staffing call that depends on 3 numbers. We confirm those 3 numbers, how fresh they must be, and who looks at them. Twelve charts were a guess at a solution.

What the outcomes look like for this example (illustrative):

• Problem statement: "Operations managers spend about 2 hours every Monday assembling numbers for the staffing call. They need open shifts, overtime hours and forecast demand in one place by 8 a.m. Monday."
• Sample acceptance criterion: "Given it is Monday 8 a.m., when a manager opens the page, then all 3 numbers show and each was refreshed after 6 a.m. that day."
• Playback wording: "Let me check I have this right. The real need is a Monday staffing call that depends on 3 numbers, fresh by 8 a.m., and the 12 charts were a first guess. What have I got wrong or missed?"

Pitfalls

• Treating the first stated solution as the requirement.
• Talking only to the sponsor.
• Ending the meeting without playing back what you heard.

Direct answer

I treat the call as the cheapest place to learn what the client really needs. I do my homework so the call is not spent on basics, I ask for a few documents and the right people in advance, and I plan the last ten minutes so we leave with a shared, written understanding and dated next steps. (A discovery call is an early conversation where you learn the client's goals, constraints and context before proposing anything.)

1. Prepare (before the call)

• Research the client: what the business does, recent news, public product pages, anything from earlier contacts or tickets. Goal: never ask what a search could answer.
• Map the stakeholders (people who care about or are affected by the outcome): the sponsor who owns the goal and budget, the hands-on user, the technical owner, and any gatekeeper such as security or legal. Ask who is attending and why; push for the sponsor plus one real user.
• Set objectives for the call in one line each. Example: "Leave knowing the goal, what is driving the deadline, which systems are involved and who signs off. Do not promise a design or a price."
• Delegate prep to internal teams: ask the account lead for history with this client, the security team for the standard answers to compliance questions, and a colleague who ran a similar project for the typical pitfalls. I arrive with facts instead of guesses.
• Send a short agenda one or two days ahead so people come ready.

2. What I ask for beforehand (pre-reads)

A pre-read is material I read before the meeting. I request: a problem statement in the client's own words; a diagram or description of how the process or system works today; screenshots or sample data from existing reports; rough volumes (users, orders or records per day); any existing requirements, deadlines, budget range or compliance constraints; and the list of systems it must connect to. If they are busy I ask for only the top three. I do not demand a long questionnaire, which delays the call.

3. Running the call: questions in order

Open-ended questions (ones that cannot be answered yes or no) first, each followed by "can you give me a recent example?"

1. "What happens to the business if this stays unsolved this year?" (the real goal)
2. "Walk me through how it works today." (current state)
3. "Who uses it, and who is affected without using it?" (users)
4. "What is driving the date, and what limits us: budget, rules, existing technology?" (constraints)
5. "In six months, what would you look at to say it worked?" (success)
6. "What has been tried before?" (history)
7. "Who decides, and what does their approval need?" (decision process)

4. How I want the call to end

In the last ten minutes I play back three to five things I heard and ask for corrections, list open questions with a named owner and a date, book the next step (for example a technical session), and say when the written summary will arrive (within 24 hours).

Worked example (illustrative)

A regional grocery chain wants "a better ordering portal". Pre-reads requested: the current order flow, last month's order count by channel, and the ERP (enterprise resource planning, the back-office system) name. Closing playback: "I heard the goal is to halve phone orders before the holiday season, store managers are the main users, the ERP integration is mandatory, and budget is unknown. Open question: the budget range, owner: finance director, by Friday. Next: technical session Tuesday."

Pitfalls

• Pitching a solution in the first 15 minutes closes down what you learn.
• Hearing only one person gives you one view of a multi-party problem.
• No written recap means each attendee leaves with a private version of the meeting.

Direct answer

I would build the plan around seven questions, starting with the first because every later choice is judged against it: what the trusted source is for, what each legacy system holds, who owns each field, how customer records match across systems, what each department means by its key terms, which regulatory constraints attach to which data, and what evidence proves "trusted". The outputs are a field-level mapping with owners, a measured match-rate baseline, a metric-definition list, testable compliance requirements and an open-question list. "Trusted" is defined by measurable targets, not by agreement.

The plan as a decomposition

1. Purpose and consumers. Who will use the source, for what decisions? Elicit measurable trust targets: "at least X% of active customers have exactly one profile", "refreshed within N hours".
2. System inventory and profiling. For each system (say A: CRM, B: billing, C: support, all illustrative): fields and types (the schema, meaning the layout of each system's columns), null rate (the share of records where a field is empty), duplicate rate (the share of records that repeat another record in the same system) and update frequency.
3. Ownership. For each field, who is the system of record (the system whose value wins) and who is the accountable owner. Overlapping owners are resolved here.
4. Identity matching. How to tell that records in different systems are the same customer (entity resolution: deciding which records across systems describe the same real person).
5. Definitions. A shared metric layer (one agreed place where a term such as "active customer" is defined once and reused in every report) needs one definition per term.
6. Regulatory constraints. Which fields are personal data, consent, residency (the country or region where data is stored), retention and deletion duties.
7. Evidence. Hand-checked samples that measure match quality.

How the items feed the outputs: items 2 and 3 produce the field-level mapping with owners; item 4 and item 7 produce the match-rate baseline; item 5 the metric-definition list; item 6 the testable compliance requirements; any question left unanswered goes on the open-question list with an owner.

Mapping excerpt (illustrative)

Marketing consent has only one source here, so its rule starts to matter only when a second system records consent. The conflict rule is called a survivorship rule: it says which value is kept when records merge. A surrogate key is a new, meaningless ID the trusted source generates itself, so it does not depend on any one system's numbering; the source IDs stay as aliases, meaning lookups back to each system.

Messy identifiers, worked

One person appears as A: "Maria Gonzalez, m.gonzalez@example.com, 00417"; B: "GONZALEZ, MARIA, maria.gonzalez@example.com, 417"; C: "M. Gonzalez, m.gonzalez@example.com, U-417". A and C match on email. B has a different email, so it needs another key such as billing address or phone, with a human check. The IDs 00417, 417 and U-417 look the same after stripping prefixes and zeros, but do not assume they identify the same person: systems issue numbers independently, so 417 in B could be someone else. Verify with the matching key.

Definitions: the metrics layer

"Active customer" may mean "signed contract" to Sales and "paid in the last 90 days" to Finance. Ask each department for its definition and example edge cases, then agree one named definition per metric with an owner.

Regulatory questions

Which fields are personal data? What consent is recorded, and where must it travel? Where must data reside? Must a deletion request reach all three systems and the new source? Capture each answer as a testable statement, confirmed by Legal or the privacy officer.

Baseline

Match a stratified sample (drawn from each segment, so small segments are not missed) of records that you can afford to hand-check, and report match, no-match and uncertain rates per system pair.

Worked example (illustrative): hand-check 200 record pairs between A and B, 100 from enterprise customers and 100 from small business. Reviewers find 154 matches, 26 no-matches and 20 uncertain, which is 77%, 13% and 10%. At 200 pairs the 77% carries roughly plus or minus 6 percentage points (95% confidence, normal approximation), so it is a baseline to improve on, not an exact figure. Two caveats: the 77% pools two equal-sized strata, so report match rates per segment and weight them by each segment's real share of customers before quoting an overall figure; and the plus or minus 6 points is the simple-random-sample approximation, so treat it as a rough guide for a stratified sample. The 20 uncertain pairs go on the open-question list, and a target such as "exactly one profile for 95% of active customers" is not promised until the uncertain share falls.

Pitfalls

Merging before ownership is settled, assuming IDs are comparable, and designing the target schema before the definitions are agreed.

Direct answer

I do not interpret the law myself. I take specific questions to legal or compliance, get their answers in writing, and convert each into a requirement with a pass/fail test. GDPR (the EU General Data Protection Regulation) applies to the processing of personal data by an organisation established in the EU (wherever the people are), and to non-EU organisations that offer goods or services to people in the EU or monitor their behaviour there (Article 3). Territorial scope is itself a question for legal. HIPAA (the US Health Insurance Portability and Accountability Act) applies to protected health information (PHI) held by covered entities and their business associates. Whether either applies to this feature is the first question.

Terms in plain language

• Data subject: the person the data is about. Controller: the organisation that decides why and how personal data is used. Supervisory authority: the regulator that enforces GDPR in a country. Subprocessor: a vendor that handles the data on the organisation's behalf.
• Covered entity (under HIPAA): a health plan, a healthcare clearinghouse, or a healthcare provider that transmits health information electronically in connection with standard transactions such as billing an insurer. Business associate: a company that handles PHI on a covered entity's behalf.
• PII: personally identifiable information, any data that identifies a person, such as a name or email. Lawful purpose: the legal reason for using the data. Erasure request: a person asking for their data to be deleted.
• Need to know: only people whose job requires the data may see it. Masked: partly hidden, such as j***@example.com.
• Contract test: an automated check that what we send a partner matches the agreed field list.

What I ask legal or compliance

1. Does either regime apply? Where are the data subjects, and are we a covered entity, a business associate, or neither?
2. What exactly counts as personal data or PHI in our data? (Fields, not categories.)
3. What is the lawful purpose, and what may the data be used for?
4. How long may we keep it, and where may it be stored or processed (data residency, covering backups and logs)?
5. What rights must the system support (access, deletion)?
6. What are the breach duties? Under GDPR the controller must notify the supervisory authority without undue delay and where feasible within 72 hours of becoming aware, unless the breach is unlikely to risk individuals.
7. Which third parties (partners, subprocessors) touch the data?

If legal asks for data without naming fields, I ask what purpose they have in mind, then propose a field-by-field list with justification for each and ask them to approve or strike. HIPAA's minimum necessary standard (reasonable efforts to limit PHI to the minimum needed for the purpose, with exceptions such as treatment) is a good lens for that list.

Turning answers into testable requirements

The last row splits an explainability duty into technical requirements (stored inputs, reproducible output) and non-technical ones (the plain-language notice, the human-review route, and how quickly a review must be answered, a period legal sets and the row above leaves to be filled in).

Privacy by design before the policy is final

Design to the strictest plausible reading: field-level controls, configurable retention, minimal collection. Record it as an assumption with an owner and a review date, so loosening later is cheap and tightening is not a rewrite.

When to escalate

Escalate when an ambiguity could change the design, when more than one jurisdiction applies, when a new data category appears, or when engineers and legal read a rule differently. Bring a specific question with two options, not "is this okay?"

Pitfalls

• Treating legal's prose as a requirement an engineer can test.
• Collecting broad fields "just in case".

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.