Consultative Discovery and Requirements Gathering Questions

Direct answer

At kickoff (the first working session of the sprint) I fix the decision the sprint must inform, write the riskiest assumptions down and rank them, and plan who I will talk to and what I will try, day by day. By the end I want each key assumption marked validated, invalidated or still open with a next step, a clear view of who the users are and their top problems, a feasibility read on the hardest technical risk, and a recommendation (go, reshape or stop) with named risks. The cheap experiments are a partner-API spike (a short, time-boxed technical test of an outside company's interface), developer interviews and a low-fidelity prototype (a rough mock-up that is cheap to make).

Kickoff (day 1 to 2)

1. Agree the decision the sprint serves and who makes it (for example, "build in Q3 or not, and in what shape").
2. Write the problem statement and list assumptions. Rank them by impact if wrong times uncertainty. Example: "Developers can integrate in under a day without our help." Illustrative scoring, each factor 1 (low) to 5 (high):

The top two get tested first, and the bottom row can wait.
3. Name user groups and book interviews (illustrative plan: two groups, new-to-platform and experienced integrators, with 5 or 6 developers each, about 12 sessions over days 3 to 6, so 3 a day; enough to hear repeated themes, not statistics).
4. Define success: what would make us stop, what would make us proceed.
5. Set a daily check-in and a written findings format.

Two-week plan (10 working days)

The three cheap experiments

1. Partner-API spike (2 days): get authentication working with sandbox credentials (test keys that touch fake data, never real customers), make real calls, find the documented and the observed rate limits (the maximum calls allowed per minute), pull sample data and compare it with the schema we assumed. Output: a one-page note listing what worked, what surprised us and what is still unknown.
2. Developer-onboarding interviews: ask developers to describe the last time they integrated a platform and where they got stuck (then probe: "What did you try first? How long before it worked? What did you do when the docs did not help?"), then watch two of them attempt a first call from the draft docs. Measures time to first successful call and where they stall. With two observers this is a qualitative signal, not a statistic.

How the top assumptions map to experiments: the "integrate in under a day" assumption cannot be fully tested in a two-week sprint, so it is tested by proxy: the interviews ask how long comparable integrations took and what blocked them, and the two observed first-call attempts show whether the first hour is smooth. The honest end state is usually "plausible, still open", with a follow-up pilot named. The rate-limit assumption (score 16) is settled directly by the partner-API spike.
3. Low-fidelity prototype: a hand-written CLI transcript (a written mock of the commands a user would type in a text-based command-line tool, with the replies) or a mock docs page (no code behind it). In a variation called Wizard of Oz, a person does the work behind a fake interface. Show it to developers and see whether they understand what to do.

What I want at the end (checked against the day-1 list)

For each ranked assumption: validated, invalidated or open, with evidence. A one-page summary: users, top three problems, feasibility finding, recommendation, risks.

Trade-offs and pitfalls

• Building production code in a discovery sprint defeats the purpose.
• Interviewing only friendly developers.
• Treating five interviews as proof; report patterns and their limits.
• Skipping the decision criteria, which makes the readout a debate.

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

"Growth insights" is a topic, not a question. I would spend the hour finding the decision behind the request, what the stakeholder means by "growth", and what data and time we have. I would leave with five things: the decision and its deadline, the growth metric defined precisely, one or two ranked questions I can answer, the data sources with owners, and a dated next step.

The 60-minute agenda

Questions, in order, and why

1. "What decision will these insights feed, and by when?" If the answer is "fund a referral programme next quarter", I build a comparison. If it is "nothing yet, just curious", I shrink the effort.
2. "What made you ask now? What did you see?" The trigger is usually the real question (a dip in a dashboard, a board comment).
3. "When you say growth, which number do you watch?" Probe a vague answer: "growth of what (signups, paying customers, revenue), over which period, compared to what, measured in which report?"
4. "What do you already believe is driving it, and what have you tried?" These beliefs become hypotheses I can test, rather than my own guesses.
5. "Who else reads the result and what will they do with it?" This sets format and depth.
6. "Which data do you trust, and where are the known gaps?"
7. "If the answer came back as X, what would you do? If it came back as Y?" If both answers lead to the same action, the question is not worth the analysis.

What I request in advance

The dashboards they look at today, the last report they found useful, any definitions document, and the attendee list. Then I use the meeting for what only they can tell me.

Worked example

Stakeholder: "We need growth insights." Question 1 reveals a funding decision for a referral programme by the 15th. Question 3 narrows growth to "monthly paying customers". The agreed question becomes: "Do customers who arrive through referrals convert to paying and stay at least as often as paid-ad customers?" Data owner and access date noted. That is something I can answer, unlike the original request.

The same method for other meetings and lengths

• 60-minute chief technology officer (CTO) plus product manager (PM) migration session: 10 min goals and deadline ("What must be true by the cut-over date?"), 15 min constraints and risks (what cannot break, tolerated downtime, dependencies), 15 min user impact (which customers and commitments are affected), 10 min decisions and owners, 10 min read-back. Request in advance: a systems diagram, the integration list and any contractual commitments.
• 30-minute retail operations call: 5 min frame, 10 min walk through a recent busy day and the manual workarounds ("Walk me through last Saturday. Where did you reach for a spreadsheet?"), 10 min numbers and definitions (store count, stock-outs meaning times an item was unavailable, reports used: "How do you count a stock-out, per item or per day?"), 5 min next steps. Request in advance: the spreadsheets they use and one recent problem example.
• 30-minute PM acceptance-criteria session: acceptance criteria are the conditions a feature must meet to be accepted. 5 min recap of the feature's intent, 10 min user scenarios ("A customer pays with an expired card. What should happen?"), 10 min edge cases and "what would make you reject this", 5 min reading back each pass/fail statement, a criterion written so it clearly passes or fails, such as "Given an expired card, checkout shows an error and keeps the basket". Request in advance: the draft story (a short written description of the feature from the user's point of view), mockups (rough pictures of the screens) and known constraints.

Trade-offs and pitfalls

• Talking for most of the hour. I aim to speak a minority of the time, and mostly to read back.
• Opening with a tour of the data before knowing the decision.
• Leading questions ("is churn the problem?"). Ask "what do you think is behind it?" instead.
• Accepting undefined words. If I cannot write the metric as a formula by the end of the hour, I did not finish block 3.
• No written recap. I send one the same day so errors surface while memory is fresh.

Direct answer

A requirements workshop with conflicting departments is not a place to collect wishes. Its job is to make conflicts visible in one room, with the person who can decide present. For an omnichannel inventory project (one live view of stock across stores, the website and warehouses), I would run a three-hour workshop with three objectives: agree the shared outcome and scope, surface each department's needs and where they clash, and leave with a draft requirement list, open questions and named owners.

Objectives

1. Agree what "omnichannel inventory" must achieve (for example, a customer sees true stock and can buy from any location).
2. Capture each department's needs as concrete scenarios, and list the conflicts.
3. Leave with draft requirements, open questions, decisions made, and owners with dates.

Who must attend (and why)

• A sponsor with decision rights (the authority to make the final call on scope and budget), so conflicts get resolved or escalated on the day.
• Store operations, warehouse and logistics, e-commerce, merchandising or marketing, and finance, since each touches stock differently.
• The system owner from IT who knows the integration reality.
• A customer service representative, to speak for the customer's real experience (the voice of the customer).
• A facilitator and a separate scribe. Facilitating and note-taking by the same person fails.
• Compliance or legal only for the sessions that need them. Keep the room to about 8 to 10 people.

How the three hours are spent

Pre-work: each department sends one page with its top three needs and top three fears, with a number where possible.

Handling conflict: a trade-off technique

Example conflict: marketing wants all store stock sold online, store operations wants to hold back two units per item as shop-floor safety stock (spare units kept so a shelf is never left empty), finance wants less stock on hand. Give each department 10 tokens to spread over the contested requirements. Illustrative allocation:

Reading it: the column totals (11, 9, 10) are nearly equal, so no requirement wins by count. The signal is in the rows: marketing put 8 tokens on R1 and none on R2, while store operations put 8 on R2 and 1 on R1. Those two strongly held, opposite positions are the real conflict, and finance's 7 on R3 tightens it because less stock leaves less to share. Where several departments pile tokens on opposite requirements, that is the real conflict. This shows intensity, not a winner: the sponsor decides, informed by it. One outcome might be "online sells down to one unit for the top-selling items only, reviewed after a trial".

Parking-lot rules

Off-topic or unresolved items go on a visible parking-lot sheet. Each gets an owner and a date before people leave. Anything "to discuss later" with no owner is deleted from the wall, not carried as a promise.

Variants of the same design

• Compliance-requirements workshop: the compliance lead walks through the rules, and each rule is recorded as a testable statement: the rule, who is bound, the evidence required, how we would test it. Illustrative example: "Customer order records are deleted 24 months after the last purchase. Bound: the data team. Evidence: the monthly deletion log. Test: a query for records older than 24 months returns zero rows."
• Marketing, operations and finance conflicting goals: the token technique above, run on a one-page list of each team's goal and its measure (for example, "cut shipping cost per order" against "deliver in under two days").
• Cross-functional scoping session: the whole time goes to an in-scope, out-of-scope and "not now" list, agreed by the sponsor.
• Cross-team validation sync (30-45 min): each team reads the draft slice that concerns it and marks each line right, wrong or missing; changes are recorded live.

What we leave with

A one-page shared outcome, a requirements list with a source department per line, a conflicts log with decisions or escalations, an open-questions list, and an owner and date for each.

Trade-offs and pitfalls

• Without the sponsor present, conflicts just move into email.
• Do not use a loud vote to decide. Votes reward volume.
• Too many people turns it into a presentation. Split by topic instead.
• Skipping the read-back means people discover misunderstandings in production.

Direct answer

I sort each unknown with a short sequence of questions. Can anyone change it? If not, it is a constraint: record it and design around it. If it can change, would being wrong change what we build or break the sprint? If not, note it and move on. If yes, can a conversation or a quick data lookup answer it? Then it is an assumption to validate. If it can only be answered by trying something technical, it earns a time-boxed spike (a short, fixed-length investigation that produces an answer, not shippable code).

The decision sequence

1. Fixed or movable? A constraint has an owner outside the team and cannot move this sprint (a contract term, a regulation, a platform limit, a hard date). Challenge anything labelled a constraint: who set it, and can they waive it? Many "constraints" are preferences.
2. Does it matter? Judge impact (what changes if we are wrong) against uncertainty. Low impact: assume and log it.
3. Cheap to check? If a person or a query can answer it in under about an hour, validate it now: ask the owner, pull the data, read the ticket history. If the answer needs scheduling other people (customer calls), it is still an assumption to validate, but it goes on the sprint plan with a date instead of being done on the spot.
4. Needs building to learn? Then use a spike or a prototype. A spike answers a feasibility question ("can the library do this?"). A prototype (a rough mock or clickable flow shown to users) answers an understanding question ("is this what they meant?"), which is how you cut requirement uncertainty before committing.

Worked example (illustrative feature)

Feature for next sprint: email a dashboard as a PDF every week.

Spike write-up: question ("Can the existing renderer produce a readable PDF of our three largest dashboards?"), time box (2 days, fixed), output (a one-page finding plus screenshots), and the decision it unlocks (keep the library, or swap it and cut scope). If the spike is inconclusive at the deadline, say so, take the story out of the sprint and carry the finding forward instead of extending the box.

Trade-offs and pitfalls

• Spike creep: no stated question or decision means it will never end. Cap the number of spikes per sprint so you still ship something.
• Constraint inflation: calling a preference a constraint hides options.
• Assumption drift: write each assumption down with an owner and a check date, or it quietly hardens into a fact.
• Order matters: validate cheap, high-impact unknowns first; they sometimes make the spike unnecessary.