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 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.

Direct answer

People rarely recall unwritten rules when asked "what are the rules?", because the rules have become habit. I would get them out by working from real cases: ask the expert to walk through the last report they built, ask where it went wrong or got rejected, and test my understanding with examples. I confirm by predicting outcomes on cases the expert has not seen, and by checking against a written source or a second person.

Steps

1. Prepare. Read what exists: the regulation text, past reports, audit findings. Ask for a past report and its review comments.
2. Walk a real case, thinking aloud. "Show me how you built the March report. What did you check first? What do you do when a number looks wrong?" Watching beats asking.
3. Ask about exceptions and failures. "When was a report last sent back? What was wrong?" Failures reveal the rules that are not written down.
4. Use scenario questions. "If an account was closed on the 29th, does it appear?" and "What would make you reject this row?"
5. Write each rule as a testable statement (a rule precise enough that a sample record clearly passes or fails it) and read it back.
6. Validate with examples. Give the expert 8 to 10 sample records, ask them to predict whether each is included, then run my draft logic and compare. A mismatch means I missed a rule.
7. Cross-check. Compare to the policy text or ask a second person (an auditor or another analyst) the same cases.
8. Get sign-off on the rule list, with a named owner for changes.

Worked example (illustrative)

Rule as first stated: "Exclude closed accounts." After walking the last report, the expert reveals: "Unless closed less than 30 days ago, or the account is under dispute." Rewritten as a testable rule, reading "closed less than 30 days ago" literally: "Exclude accounts closed 30 or more days before the reporting date, unless the account carries a dispute flag." Test case: account closed 12 days ago, no dispute: included. Closed 45 days ago, no dispute: excluded. Closed 45 days ago, under dispute: included. The expert confirms two of the three and corrects the third (dispute accounts are included only until the dispute closes). So far the rules are: (1) exclude accounts closed 30 or more days before the reporting date (my first draft, revised by rule 4 below); (2) a dispute flag overrides that exclusion; (3) the override lasts only until the dispute closes. A fourth rule emerged only because I tested a boundary case: an account closed exactly 30 days before the reporting date, no dispute. My draft excluded it. The expert said it stays in, because the cut-off is "more than 30 days", counted in calendar days from the closure date. Rule 4: an account closed exactly 30 days ago is still included, and exclusion starts at 31 days, so rule 1 now reads: exclude accounts closed more than 30 days before the reporting date. Tracing it again: closed 30 days ago, no dispute, included; closed 31 days ago, no dispute, excluded.

Probing a vague answer

"It depends" is the signal. Reply: "Depends on what? Give me the last time it went each way."

Trade-offs and pitfalls

• One interview rarely suffices. Plan two or three short sessions.
• Do not lead: "Is it 30 days?" gets a polite yes. Ask "What is the cut-off, and how do you know?"
• The expert may be wrong or out of date. That is why the second source matters.
• Without sign-off, a rule is a guess. Keep a log of rules with the date confirmed and by whom.
• Dependence on one person is a risk in itself. Part of the output is a written rule book for everyone.

Direct answer

"Zero downtime in two weeks" is two demands that may conflict. Here the migration means moving a live payment service to new infrastructure, and the cutover is the moment traffic switches from the old system to the new one. Availability is the share of time the service works for users. I would first find out what zero downtime has to protect (which users, which functions, how long an interruption is tolerable), then what two weeks is tied to, then lay out the options with their risk and cost. I would take it back as a choice, not a refusal: "Here is what is achievable by that date and what it costs to go further."

Exploring what it has to mean

• "Which services and users must stay up? Is read-only access during cutover acceptable?"
• "What is the longest interruption nobody would notice or complain about?"
• "What happens at 2 a.m. versus at peak? Are there blackout periods (times when changes are forbidden, such as month-end)?"
• "Why two weeks? A contract, an event, a licence expiry, a cost?"
• "What is the rollback requirement (the ability to switch back to the old system) if something fails?"

Feasibility, with the arithmetic

Availability numbers translate into allowed downtime. For a 30-day month (43,200 minutes):

A 99.999% payment cutover across clouds leaves about 26 seconds in a month. 99.9% is often called "three nines" and 99.999% "five nines". A single failed deployment can use that up, so the plan needs a staged cutover (moving traffic in steps rather than all at once), rollback rehearsed, and real-time monitoring.

Dependencies cap the target. A migration adds dependencies: the new cloud's services, a network link, a partner API. Suppose a client expects 99.99% overall but a dependency fails in 5% of hours (an exaggerated, illustrative figure chosen so the effect is easy to see). If every request needs that dependency, the parts are "in series": the whole works only when every part works, so availabilities multiply. 0.9999 x 0.95 = 0.949905, about 94.99%, so the dependency alone caps the system near 95%. Two independent copies reduce the failure to 5% x 5% = 0.25%, giving 99.75% (this assumes the failures are independent). So the answer is design change (redundancy, fallback, retries), not a promise.

Options I would bring back

1. Phased migration in cohorts (separate groups of users moved in turn; for 100,000 users: first 1,000, then the next 10,000, then the next 50,000, then the remaining 39,000), with the ability to roll back each cohort.
2. Read-only window (a few minutes when users can view but not change data), announced in advance.
3. Full dual-running (old and new systems both live and kept in sync, so traffic can move with no gap), which needs more time and budget.

My recommendation, for the stated two weeks: option 1 or 2 with a fixed agreed maximum interruption, and option 3 only if the VP funds more time. What would change my call: a hard legal or contractual reason for no interruption at all.

Capacity or growth uncertainty

If traffic may grow suddenly (viral growth), a capacity shortfall during the cutover is downtime too. Ask for plausible bounds, not one number. Illustrative: today 200 requests per second, low case 300, expected case 600, high case 2,000. Then agree what degrades first if the high one occurs, for example new signups are queued before payments slow down.

Taking it back to the VP

Use a one-page summary: what "zero downtime" is interpreted as, three options with date, risk and cost, my recommendation, and the decision needed by a given day. Lead with what we can deliver, then what each extra increment costs.

Trade-offs and pitfalls

• Saying "impossible", which ends the conversation.
• Promising the number without a rollback plan.
• Forgetting that dependencies set the ceiling.
• Different people reading "downtime" differently: always agree the measurement point.

Direct answer

"Expand to new markets" and "reduce churn" are intentions, not requirements. I turn each into a specific, measurable statement by asking: what exactly counts, how much, by when, for whom, and measured where. To find the hidden assumptions I ask what would have to be true for the goal to work, run a pre-mortem (imagine it failed and ask why), and restate my understanding for leadership to correct. My first question is which goal wins when the two compete for the same people and budget.

Questions for "expand to new markets"

1. Which markets, in what order, and why those? (Pick named countries or segments.)
2. What does "expanded" mean: live in the country, first paying customer, a revenue target?
3. By when, and what is the target at 12 months (customers or revenue, with a number)?
4. Which customer segment are we targeting there, and do we have evidence they want this?
5. What must change for the market: language, currency, payment methods, regulation, data location, support hours?
6. Who are the local competitors, and what is our reason to win?
7. What are we prepared to give up or delay to do it?

Questions for "reduce churn"

1. Which churn: customers lost (logo churn) or revenue lost? Voluntary cancellation, or involuntary loss from failed payments?
2. What is the baseline today, and what is the target by when?
3. Which segment or cohort (customers who joined in the same period)? Is all churn bad, or are some departures acceptable?
4. Do we know why customers leave, and from what evidence?
5. Who owns the levers: product, support, pricing, onboarding?

Finding the assumptions hiding inside

Techniques: "what would have to be true for this to work?", a pre-mortem, and reading each goal back in my own words until leadership says "yes, exactly".

A pre-mortem for the Germany and France launch (illustrative)

"It is a year later and the launch failed. Why?" Plausible answers: German buyers expect to pay by invoice or direct debit and we offered only cards; support was not staffed in local hours; the team was pulled onto churn work and the launch slipped. Each answer becomes either a requirement (add invoice payment) or an assumption to test before committing.

The conflict question

New-market customers often behave differently early on, which can raise churn while the goal says reduce it. I ask directly: "If these pull against each other, which takes priority, and what is the trade you would accept?"

Resulting requirements (illustrative numbers)

• "Reduce monthly logo churn on the small-business plan from 3.0 percent to 2.4 percent by the end of Q4, measured in the billing system, with failed-payment losses reported separately." This is a drop of 0.6 percentage points, a 20 percent relative reduction (0.6 divided by 3.0).
• "Launch in Germany and France with localized checkout (checkout adapted to the country: language, currency, local payment methods), euro billing and compliant handling of personal data, reaching 50 paying accounts within six months of launch, measured in the billing system as accounts with at least one successful payment, by billing country." Closed-won deals, meaning deals the sales team has signed and recorded as won, are tracked separately as a leading indicator, because a signed deal is not yet a paying account. Compliant handling of personal data is made testable by naming the standard and the check, for example: "legal confirms the data-processing terms and the data-location setting before launch, and the privacy lead signs off the checklist."

Trade-offs and pitfalls

• Leadership may not have numbers yet. Propose a number and ask them to correct it; a wrong proposal gets a faster answer than an open question.
• Do not accept one number without a measurement point: "2.4 percent measured where, by whom?"
• Seniority makes pushback feel risky; frame questions as "so we can plan against it", not as challenges.