Consultative Discovery and Requirements Gathering Questions

Direct answer

A legal or regulatory requirement is an obligation with an external source (a statute, a regulation, a contract clause, or a regulator's binding rule) and a consequence if you miss it (fines, lost contracts, liability). A recommendation is counsel's advice about reducing risk, and you may weigh it against cost and schedule. You tell them apart by asking for the source, the consequence and who can grant an exception, not by how firm the sentence sounds. The difference matters because requirements go into the design as fixed constraints, while recommendations become inputs to a trade-off.

How to tell them apart when recording input

1. Listen for the wording, but never trust it alone. "Must", "shall" and "is required to" often signal an obligation. "Should", "ideally" and "we'd prefer" often signal advice. Lawyers also say "must" about internal policy, so wording is only a prompt to ask.
2. Ask for the source. "Which law, contract clause or policy says that, and can you point me to it?" A real obligation can be named. If the answer is "it's best practice", it is a recommendation.
3. Ask for the consequence. "What happens if we don't do this?" A fine or a breached contract means an obligation. "We would be more exposed" means advice.
4. Ask who can waive it. A regulator or a customer contract cannot be waived by your sponsor. An internal policy can be waived by its owner. The answer also tells you whether you are dealing with an external obligation or an internal policy.
5. Ask about scope. Which data, which countries, which customers, from what date? A true obligation can still apply to only part of the system.
6. Get the classification confirmed in writing by counsel. You are not the lawyer. Record what you were told and who confirmed it.

Worked example (illustrative statements)

Legal says three things about a new customer-data export feature. Recorded:

Row 1 stays provisional on purpose: until Legal names the article, the record says so rather than treating the sentence as proven. Even when it is cited, an erasure duty is rarely unconditional. For example, the GDPR's right to erasure (Article 17) has listed exceptions such as a legal obligation to keep the data or the establishment, exercise or defence of legal claims, so the scope question (which data, which exceptions) goes to counsel too.

The first two become testable requirements ("a deletion request removes the data from every store, verified by an automated check"). The third goes on the trade-off list with its cost, and the sponsor decides.

Trade-offs and pitfalls

• Treating advice as mandatory over-builds, delays delivery and burns trust with engineering when the "requirement" later turns out to be optional.
• Treating a requirement as advice ships a compliance gap that is expensive to fix after launch.
• Do not interpret the law yourself. Your job is to capture and classify accurately and route doubt to counsel.
• Keep the record honest. An "unclear" label with an owner and a date beats guessing in either direction.

Direct answer

I list each assumption, rank by how badly the plan breaks if it is wrong, and test the riskiest first with the cheapest evidence available: real logs, a sample, a read of the documentation, or a short probe. For each I write down in advance what result would prove it wrong. Assumptions that survive stay in the plan with a validation date. Those that do not change the scope while it is still cheap to do so.

Assumption table (illustrative)

Testing traffic growth against spiky history

Suppose the client says peak is 50 requests per second. A log excerpt shows the busiest minute has 3,000 requests: 3,000 / 60 = 50 per second on average over that minute, which matches. But the month-end busiest minute has 4,500 requests: 4,500 / 60 = 75 per second, 1.5 times the claim. I would size to 75 or negotiate a queueing or throttling approach, and note the change to scope.

Validating a problem without data

Take a sample of 30 support tickets and mark how many show the problem. Say 12 do: that is 40%, but with only 30 cases the plausible range (a 95% Wilson confidence interval, a standard way to express uncertainty for a proportion; "95%" means that intervals built this way would contain the true share in about 95 of 100 repeated samples) is roughly 25% to 58%. Computation, with n = 30, 12 hits, p = 0.4 and z = 1.96 (the multiplier for 95%): the centre is (0.4 + 1.96^2 / 60) / (1 + 1.96^2 / 30) = 0.464 / 1.128 = 0.411, and the half-width is 1.96 x sqrt(0.4 x 0.6 / 30 + 1.96^2 / 3,600) / 1.128 = 0.187 / 1.128 = 0.165. So the range is 0.411 minus 0.165 to 0.411 plus 0.165, which is 24.6% to 57.7%. That is enough to say "this is common enough to investigate", not "40% of customers have it". Quick telemetry (usage data the product already records automatically, such as a count from an existing event or table) gives a firmer number if it exists.

Customer team capability, timeline and budget

Within the first two meetings ask for named engineers, their time, the budget owner and approval status. Red flags: no named owner, "we will staff it later", a dependency on a team that is not in the room, budget not yet approved.

Proof of concept or prototype?

A proof of concept (PoC) tests whether something is technically possible and is usually thrown away: for example, call the partner API 75 times per second for 10 minutes on sample data and record latency and errors. A prototype shows how it would look and work so users can react: for example, a clickable mock of the screen shown to 5 users. Pick the PoC for feasibility risk (can the API handle the load?), the prototype for acceptance risk (will people use this?). Write go/no-go criteria before building, for example: "p95 latency (the time within which 95% of requests finish) under 300 ms at 75 requests per second on sample data". The number is illustrative.

Validating a product hypothesis

State it as "We believe X; we are wrong if Y": for example, "if fewer than 8 of 20 invited pilot users complete the task unaided, the plan changes." Fewer than 8 of 20 is under 40% completing, and the threshold was set before the pilot.

Pitfalls

• Testing the easy assumptions and leaving the risky one.
• Choosing a PoC when the real risk is user acceptance.

Direct answer

I assume the stakeholder list I was given is incomplete and look for the rest in three ways: ask the people I already have who else is affected, follow the real process (who touches, approves, pays for, runs, audits and gets paged for the thing), and read the history of earlier similar projects to see who signed off or objected. I then approach each new person as a listener, not a presenter, with a short interview about their work and constraints, and give those who can block the outcome a defined role in review.

Ways to find the people nobody mentioned

1. Referral questions. Ask each interviewee: "Who else is affected by this? Who would be upset if it changed? Who has strong opinions about it? Who did you speak to last time something like this changed?" Names repeated by several people matter.
2. Process walkthrough. Ask someone to trace one real case end to end ("take last month's invoice from creation to payment") and note every person and team that appears. Hidden stakeholders appear at hand-offs.
3. Org and decision questions. "Who has to approve a change to this system? Which reviews does it go through (security, legal, architecture)? Who signs the budget?"
4. Artifacts of past change. Look at old change tickets (records of requested changes to a system), incident reports, project post-reviews (write-ups of what went well and badly after a project) and contract files for names that approved or blocked earlier work.
5. Ask about vetoes directly. A veto is the power to block the project even after everyone else agrees. "Who could stop this even after everyone here agrees?" Typical answers are security, legal, procurement, an architecture board, a regulator-facing team.
6. Holders of unwritten rules. Long-serving operators, analysts running manual spreadsheets, the finance close team, customer support leads. Ask: "Who do people go to when the documented process does not work?"

Keeping it requirements-oriented

I am looking for people who hold requirements (rules, constraints, workarounds) or can veto the outcome. The questions in the numbered list above are for finding people, so asking who signs the budget identifies an approver and is not a request for their budget. Once I am talking to a newly found person, the interview should end in "what does your team need from this, and what must not break?", not in budget or buying-intent questions.

Stakeholder map (excerpt)

The three types of influence used here: unwritten requirement (a rule or workaround only they know), veto (can block the outcome), and knowledge and impact (they know the pain or live with the results).

How to bring them in

• Ask the sponsor (the executive who funds and backs the project) to introduce you, framed in their terms: "I want to make sure we do not break anything your team depends on."
• Open with questions about their work, not a project pitch.
• Give a veto-holder an early look at the requirements that touch them, so objections arrive in week two, not week twelve. For example: "Before we finalise anything, could you look at the three requirements that touch security? I would rather hear objections now than in week twelve."
• Share back what you recorded, so they see their input counted.

Worked example

On a project to replace an analytics platform at an insurer, the sponsor lists four stakeholders. Asking the data platform lead "who else uses its outputs?" produces a name from claims reserving, who pulls a monthly extract and corrects it by hand (claims reserving is the team that estimates how much money to set aside for claims not yet paid). Tracing last month's close reveals the finance controls team, who must sign off on any change to numbers used in filings (reports submitted to regulators, where errors carry penalties). Neither was on the list. Both would otherwise have appeared late.

Trade-offs and pitfalls

• Each name adds time. Stop adding when new interviews return mostly names you already have (a practical sign you are close to complete, not a guarantee).
• Going around a sponsor to reach people can damage trust; ask for the introduction first.
• Treat a quiet person who can block you as higher priority than a loud one who cannot.

Direct answer

Treat "we need an API" as a proposed solution, not yet a problem. In fifteen minutes I would find out what goes wrong today, which data moves in which direction, how fresh and how large it must be, and what has to happen when a transfer fails. I would hold back the technology choice, an estimate and a date until I have those answers, because the first few answers may show that an API is not the right shape at all (a nightly file or a vendor-supplied connector might do).

A CRM (customer relationship management system) is where sales and support record customer details. The billing system is where invoices and payments are produced. A stakeholder is anyone affected by the result or with a say in it, such as the sales lead who asked for this.

The questions, in the order I would ask them

1. "What happens today that made you ask? Tell me about the last time someone needed customer data in both systems." This finds the real pain (re-keying, wrong invoices, delays) and the cost of doing nothing. If the answer is a one-off migration, a one-time export beats a permanent integration.
2. "Which customer fields, and which system is the source of truth for each?" The source of truth is the system whose value wins when two copies disagree. One-way copying is small; two-way syncing needs conflict rules and is a much bigger project.
3. "How soon after a change in the CRM must billing see it, and roughly how many changes a day, including the busiest day?" If they say "real time", probe: "What breaks if billing sees it an hour later? The next morning?" The answer decides between a nightly batch and change-by-change delivery.
4. "What should happen when a transfer fails, or arrives twice?" The business consequence (an invoice to an old address, a duplicate customer) drives retries, duplicate protection (idempotency: repeating the same message has no extra effect) and who is alerted.
5. "Who owns each system, who else will read this data, and who signs off?" A third consumer, such as a partner company, changes authentication, usage limits and accountability.
6. "Does any of this count as personal or payment data, and is there a compliance rule?" PII (personally identifiable information) such as names and addresses changes encryption, access logging and which fields may move at all.
7. "What does done look like, and what is the deadline tied to?" This sets the MVP (minimum viable product, the smallest version that lets you test whether it solves the problem) and tells me whether to phase the work.

If the corridor only fits four, I ask 1 to 4 and book thirty minutes for the rest.

What I deliberately hold back

• The style of solution: a request-response API (one system asks another and gets an immediate answer, like looking up a customer record), event notifications (small messages the source sends whenever something changes), or a scheduled file (a batch of changes dropped at a set time and picked up later).
• Tools and vendors.
• A build estimate. In a corridor an estimate is heard as a promise.
• A delivery date.
• Any statement that "yes, we will build the API".

Integration-contract checklist, once the problem is clear

I confirm four things before design: auth (who may call it and how they prove identity), payload (fields and formats), throughput (calls at the busiest moment) and error handling (what the caller sees on failure and the retry rules).

Worked example (illustrative answers)

• Pain: finance reissues invoices a few times a month because billing holds old addresses.
• Fields: legal name, billing address, plan. The CRM is the source of truth, one-way to billing.
• Freshness: changes must land before the nightly invoice run at 02:00. Volume is modest, higher at month-end.
• Failure: if the nightly sync fails, finance operations is alerted before the 02:00 invoice run (for example at 01:30) so they can hold the run, because a failure found only the next morning would mean invoices already issued to old addresses, which is the original pain. A failed run is retried, and a repeated transfer must not create a duplicate customer.
• Owners: sales operations owns the CRM, finance engineering owns billing. Nobody else reads it.
• Sensitivity: name and address are personal data; no card numbers move.

I would write it back as: "By 02:00 each night, billing holds the current legal name, billing address and plan from the CRM, one-way, with a failed sync flagged to finance operations before the 02:00 invoice run." That needs a nightly sync, not a real-time API.

What I write down: assumptions (the CRM is the only source of truth), open questions (volume at month-end, owner for failure alerts) and the problem statement above, then I send it to the stakeholder to correct.

Trade-offs and pitfalls

• Firing seven questions at once feels like an interrogation. Frame it as "so I can give you a realistic answer", and ask the top four first.
• Proposing the solution "to be helpful" locks in a design nobody examined.
• "Real time" usually means "sooner than today". Ask what a delay would cost before accepting it as a requirement.

Direct answer

I choose questions by asking which answer would most change what gets built or whether it gets built, and which is cheapest to ask. That gives six groups, in this order: purpose, users and context, outcome and success, scope, constraints, and ownership and risk. Early questions can make the request unnecessary, so they go first.

The six groups, with one example each

How I decide what to ask first

I start with purpose and users, since their answers decide which of the other four matter. If a request mentions a regulated area, constraints jump to second. If the deadline is fixed, scope comes up early. I ask the group of questions that could change the plan most, not a fixed script.

Worked example (illustrative)

Request: "Add a share button to reports."

1. Purpose: "What happens today when someone wants to share a report?" Answer: they screenshot it and the numbers go stale.
2. Users: "Who shares, and with whom?" Answer: managers, with people who do not have accounts.
3. Outcome: "How will we know it worked?" Answer: fewer screenshots in team chat; maybe a count of shares.
4. Scope: "Smallest useful version?" Answer: a link that opens a read-only view.
5. Constraints: "Any data that must not leave the company?" Answer: yes, customer names.
6. Ownership: "Who decides what is shareable?" Answer: the data owner.

A "button" request turns out to be about stale screenshots and access to data, and the constraint about customer names changes the design.

Trade-offs and pitfalls

• A checklist applied identically to every request is slow and annoying. Pick the groups by risk.
• Asking about solutions ("should it be a popup?") before purpose.
• Stopping at one answer per group. A good follow-up uses the stakeholder's (the requester's) own words.