Consultative Discovery and Requirements Gathering Questions

Direct answer

I spend the stakeholder's (the person with a stake in the outcome whose input I depend on) scarce time only on questions that are expensive to get wrong, make them easy to answer, and keep working on everything else using written assumptions. Then I tell them plainly what I am assuming, what it costs if I am wrong, and by when I need a yes or no. Progress and risk are both visible, so I do not stall and I do not guess silently.

How I balance asking with moving forward

1. Sort my questions by cost of being wrong. If a wrong guess can be undone in an afternoon, I decide and note it. If it would force weeks of rework or produces a wrong number in front of leadership, it goes on the list for the stakeholder.
2. Batch and shrink the ask. One message with at most five questions in priority order, each phrased so the reply can be one word, and each with my proposed default: "I plan to include refunds in revenue (net). Reply 'ok' or tell me what you prefer."
3. Look for a proxy. A deputy, a long-serving analyst or a prior document can answer many questions. Ask the stakeholder to name that person once, instead of asking them every time.
4. Ask for a standing slot. A 15-minute weekly checkpoint beats ad hoc interruptions.

What I write down: an assumptions log

I also record the date each question was asked and any reply, so the trail shows I tried.

How I communicate the risk

One short message to the stakeholder and, if the decision matters, their sponsor: "I am proceeding on these three assumptions (listed). If A is wrong, the cost is roughly two days. If B is wrong, we would have to rebuild the data model, so I need your answer on B by Wednesday. If I hear nothing, I will carry on with the stated default and flag it clearly in the draft." Then I mark the assumption visibly in the deliverable, so nobody mistakes a guess for a confirmed fact.

Worked example

A business-intelligence analyst is building a weekly sales dashboard and the finance lead answers messages once every few days. Of eight open questions, six are reversible formatting and labelling choices, so the analyst decides and logs them. The two that matter (refund treatment and fiscal calendar) go in one message with defaults. The finance lead replies "ok" to one and corrects the other in a two-minute reply. Nothing waited for a meeting.

Trade-offs and pitfalls

• Asking nothing is as risky as asking everything: it leaves hidden bets in the work.
• A stakeholder's silence is not approval. State the default and the date, and escalate when the downside is large.
• Do not hide the risk in a long status report; put it in the first sentence of the message.
• If a wrong assumption would cause real harm (money, compliance, customer-facing numbers) escalate to the sponsor rather than proceed on a guess.

Direct answer

A request is too ambiguous to start on when I cannot state, in three sentences, what is wanted, for whom, and how we will know it worked. I look for six signals, and for each one there is a question that resolves it and a fallback if the answer does not come.

A stakeholder is anyone with a stake in the outcome who can ask for, approve or be affected by the work.

The six signals

When a ticket turns out to be under-specified

When a reviewer, a teammate or a retrospective points that out, I read it as a free checklist: which of the six signals was missing? I add the answers to the ticket, written as assumptions with a name to confirm them, and give acceptance criteria (the conditions that must be true for the work to count as done). From the engineer's side, I take this list to the product manager before sprint planning rather than after the build.

Worked example (illustrative)

Ticket: "Make search faster."

• Owner: the product manager for the support tool.
• Measure: "95 of every 100 searches return within 1 second, measured at the server over one week" (the 95th percentile).
• Vague term fixed: "faster" now has a number and a place of measurement.
• Timeline: the quarter-end demo; the smallest useful piece is the catalogue search.
• Audience: support agents, who need the catalogue search first.

Trade-offs and pitfalls

• Ambiguity is normal; waiting for perfect clarity stalls work. The rule is: stop when a wrong guess is expensive, and build the smallest slice when a wrong guess is cheap.
• Ask in writing and say "I will proceed on this assumption unless you object by Thursday". Silence is then an answer.
• Do not ask every question at once. Choose the signals that would change the plan the most.

Direct answer

Pick one real story where the request was one line and you made it concrete. Say what you asked, which assumptions you wrote down, and how someone confirmed them. The strongest stories include a moment where an assumption was wrong, caught early.

What to put in each STAR part

STAR means Situation, Task, Action, Result.

• Situation: the vague request, who made it, why it mattered. One or two sentences.
• Task: what you were responsible for delivering and by when.
• Action: three parts. The questions you asked (and why). The assumptions you made explicit, written down with a name against each. How you confirmed: a read-back, a mock-up, or a walk-through with the people affected.
• Result: what shipped, what was avoided, and one thing you would change.

Worked example (a story skeleton; replace the details with your own)

• Situation: a support lead said, "We need a better way to track escalations." No format, no date.
• Task: deliver something usable within two weeks.
• Action, questions: I asked to see the last three escalations that went wrong. They were not lost in tracking: they stalled at the handoff between first-line and second-line support. I asked who needed to see what, and how they would know a handoff had worked.
• Action, assumptions: written on one page, each with an owner: (1) the existing ticket tool is where both lines work; (2) volume is small enough for a daily list; (3) no new personal data is stored.
• Action, confirming: I built a mock spreadsheet, a one-page scope with what was in and out, and walked the support lead and the second-line lead through a real escalation. The second-line lead corrected assumption 1: they worked in a separate tool.
• Result: I added a required handoff field and a daily "unclaimed after 48 hours" list in the tool second line used, and skipped the dashboard first imagined. Support lead's feedback: it was what they meant. Measure I would track: the count of escalations unclaimed after 48 hours, before and after (I would only quote real numbers I had).
• What I would do differently: show the mock-up in the first meeting instead of the second.

Trade-offs and pitfalls

• Generic virtue ("I always ask lots of questions") with no specific question. Name one.
• Hiding the wrong assumption. A caught mistake is evidence of the method.
• Quoting invented percentages. If you have no hard number, describe the outcome plainly.
• Making the stakeholder (anyone with a stake in the outcome, here the support lead and the second-line lead) look foolish. Credit them for the correction.

Direct answer

Features describe what the portal does. Non-functional requirements (NFRs) describe how well it must do it and under what constraints: speed, availability, security, privacy, accessibility, growth and supportability. A sponsor rarely mentions them, so I ask by category, and for each answer I request evidence that turns an opinion into a number.

Questions by category (six), the evidence to request, and a resulting requirement (illustrative)

I also ask "Is there a past incident or complaint that taught you what matters here?" Real stories surface requirements that questionnaires miss.

Worked example: "the API should be more secure"

I would ask three groups of questions.

• Technical: who calls the API (internal, partners, public)? What would a breach expose? Is there a past attack?
• Legal: which rules or contracts apply, for example data protection law, payment standards, or customer security clauses? Is breach notification required?
• User-facing: how much friction is acceptable (multi-factor sign-in, session timeouts)?

A minimal control set for a first release, in priority order:

1. First: authentication using a standard protocol such as OpenID Connect (a sign-in layer built on OAuth 2.0, which is itself a delegated-authorization standard: it lets an app act for a user with limited access without ever holding the user's password; OAuth 2.0 alone grants access and does not prove who the user is), a permission check on every resource (stops one customer reading another's records), and encryption in transit using TLS (scrambles traffic so it cannot be read on the way).
2. Next: input validation (rejecting malformed or malicious input), rate limiting (capping calls per client per minute, which blunts password guessing and overload), and audit logs (a record of who did what and when, used to investigate incidents).
3. Before launch: secrets (passwords and keys) kept out of code, and a security test.

Check that the targets agree with each other

An availability figure and a recovery time must be consistent. A 99.9% monthly target allows about 43 minutes of downtime (43,200 minutes x 0.001 = 43.2), but a recovery time objective of 4 hours is 240 minutes, so a single incident that used the full 4 hours would use up the monthly allowance about five and a half times over (240 / 43.2). The two numbers in the table are illustrative and must be reconciled with the sponsor: either the 4 hours applies only to a rare disaster and the availability target excludes it, or a 4-hour recovery is acceptable and the honest availability target is about 99.4% (240 / 43,200 is 0.56% downtime), or the recovery time must shrink to well under an hour. Asking the sponsor which of these is true is exactly the kind of question that surfaces a real requirement.

What I write down

Each requirement with a number, a measurement or verification method, an owner, and anything still unknown flagged as an open question. For the security and privacy rows in the table the "number" is a checkable condition rather than a figure, for example every endpoint refuses plain HTTP, or deletion requests are completed within an agreed number of days, and an owner and a verification method (a scan, an audit, a test) are added to each row before it counts as written down.

Pitfalls

• Accepting "secure" or "scalable" as written.
• Asking only IT, when legal and support hold the other half.
• Promising numbers before baseline data exists.

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.