Consultative Discovery and Requirements Gathering Questions

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

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

Spend the hour on four groups of questions: the business decision and the cost of being wrong, how the outcome is defined and when you learn it, how the score will be used in daily operations, and the legal and data constraints. A credit-risk model estimates how likely an applicant is to fail to repay (to default). The answers that most change what you build are: which decision the score drives, what a bad loan costs compared with a lost good customer, when outcomes become known, whether every decline must be explained, and how fast the score must return.

Suggested hour: 60 minutes

Business 15 + risk 15 + operations 15 + constraints 15 = 60. Legal and infrastructure people are often not in the room, so ask the constraints questions of whoever is present and name an owner for each unanswered one.

Questions, and what the answer changes

Worked example: why "accuracy" is the wrong ask

Suppose 5 of every 100 applicants default (illustrative). A model that approves everyone is wrong on 5 and right on 95, so it is "95% accurate" and useless. This is why the cost question and the cutoff question come first.

Worked example: choosing the cutoff by cost (illustrative)

Suppose a good loan earns 100 in margin and a default loses 1,000, so a default costs 10 times the margin. Expected profit per approved applicant with default probability p is (1 - p) x 100 - p x 1,000 = 100 - 1,100p, which is break-even at p = 100 / 1,100, about 9.1%.

Approving bands 1 to 3 earns 49,200. Approving band 4 too drops it to 36,200, so the cutoff sits between bands 3 and 4. If a default cost only twice the margin, break-even would be 100 / 300, about 33%, and every band would be approved, which is why the cost question changes the build.

If time runs short

Ask three questions first: which decision the score drives, what a bad loan costs against a lost good customer, and whether every decline must be explained and which inputs are forbidden. They set the model type, the cutoff and the allowed inputs. The rest can go to written follow-ups.

The requirement I would write down (illustrative numbers)

"Score each new application within 1 second at decision time, using only fields available then. At the same approval rate as today's policy, the bad-loan rate among approved applicants on held-back applications old enough for the outcome window to have matured (for a 12-month window, applications at least 12 months old; for newer ones, the early-warning proxy label) (past applications set aside, not used for training, so the model can be tested on cases it has not seen) must be lower than today's policy, and every decline must carry reason codes."

Pitfalls

• Discussing algorithms before the decision and error costs are agreed.
• Skipping the operations team, then discovering the score arrives after the decision is made.
• Treating one hour as enough: record open questions with owners and dates.

Direct answer

I build trust by making the conversation about her goals and her language, not about my systems. I ask about her campaigns, deadlines and worries in business terms, then translate each answer into the technical consequence myself, so she never has to read jargon. Afterwards I confirm the translated requirement with her in her words and with engineers in theirs.

The first five minutes: rapport

• Say why we are meeting and what I will do with the answers.
• Start with her goals ("What does a great quarter look like for your team?") before any system question.
• Use her vocabulary (campaign, list, send, launch) and adopt her terms for things.
• Paraphrase back: "So the sale email has to land the moment the sale starts."
• Admit what I do not know about marketing. It signals respect and invites correction.

Questions in business terms that expose technical consequences

The right-hand column is engineering vocabulary, so here are plain-language translations I would give her if a term comes up: peak traffic is the busiest moment of visitors on the site; a change freeze is a period when engineers are not allowed to release changes; consent handling is recording and honouring what people agreed to, such as unsubscribing or refusing tracking (being followed across the site for marketing); integrations are the connections between her tools and ours; the source of truth is the one report everyone agrees is the official number.

Avoiding jargon

Use plain analogies ("the site is a shop doorway: too many people at once and they queue or leave"), and define a term the first time I must use it. Never test whether she knows an acronym.

Converting a business answer into a requirement (illustrative numbers)

She says: "The sale email must go to everyone right when the sale starts." I draft: "Send the 'sale live' email to the whole list within 15 minutes of 9:00." Suppose the list holds 400,000 contacts. Then 400,000 / 15 is about 26,700 emails per minute, roughly 440 per second, which is what engineering must confirm the email provider can sustain. I check both sides: with her, "Is 15 minutes fast enough, and what happens at 45?", and with engineers, "Can we sustain that rate?" The requirement is confirmed only when both agree.

Pitfalls

Talking down, over-simplifying until the constraint disappears, firing a long list of questions, and leaving the meeting without reading the requirements back to her.

Direct answer

I would not start pulling data yet. In the first conversation I would pin down what "fell 12%" means, what decision the CFO (chief financial officer) is making with the answer, and how precise it must be. I would write down every assumption, then promise only what I can defend in two weeks: a reconciled, quantified breakdown of the drop on the data that maps cleanly, with a stated coverage figure and a list of what stays unexplained. I would not promise a single root cause or a fully cleaned history.

What I ask, in order

1. Definition. Gross margin is (revenue minus COGS, the cost of goods sold, meaning the direct cost of what was sold) divided by revenue. Is the 12% a relative fall or percentage points? From 40% to 35.2% is a 12% relative fall (40 x 0.88 = 35.2). A 12-point fall would be 40% to 28%. Those are very different problems. Also: compared with which period?
2. Decision. What will she do with it (reprice, renegotiate supplier costs, reset a forecast)? "If I could show you one thing by day ten, what should it be?"
3. Source of truth. Which report holds the official margin, so I can tie my totals to it.
4. Known changes. System migrations, product-code remaps, cost-allocation changes, new discount rules, currency effects, one-off write-offs, and who in finance or IT remembers the code history.
5. Precision needed. Board-ready, or directional enough to decide where to dig?

Assumptions I write down and share on day one

• A1: Margin follows the definition in finance's monthly pack.
• A2: The 12% is a relative fall.
• A3: Legacy product codes map to current product families through a mapping table that finance confirms. Codes that cannot be mapped stay in a visible "unmapped" bucket and are never silently dropped.
• A4: Prior-period figures are not restated (finance has not recalculated old numbers under new rules).

Open question: who signs off the code mapping, and by which day.

What I can honestly promise by the deadline

• Week one: tie totals to the reported margin (reconcile: check that my numbers add up to the official figure in finance's monthly pack, so the CFO trusts the starting point), build the mapping, measure the unmapped share of revenue.
• Day ten: a checkpoint with the CFO, so she can redirect me while there is still time.
• Week two: a bridge from the old margin to the new one by driver (price and discounts, volume, product mix, unit cost including freight, one-offs). A bridge is a table that starts at last period's gross profit, adds or subtracts the effect of each driver, and ends at this period's gross profit, so every dollar of the drop is accounted for.

I commit to: totals that reconcile, a bridge with a coverage statement (how much of the drop is attributed to drivers traced through cleanly mapped codes, plus the share of revenue that could not be mapped, so the CFO sees both how much is explained and how much sits in the unmapped bucket), each driver labelled "confirmed" or "suggested", and next steps. I do not commit to: one root cause, causal claims from correlations, or a clean history.

Worked example (illustrative numbers)

Revenue is flat at $100M while margin goes from 40% to 35.2%. Gross profit falls from $40.0M to $35.2M, a drop of $4.8M.

How each driver number is computed (illustrative)

• Discounting: average discounts rose by 2 points of list price. Applied to the $100M revenue base, 2% x $100M = $2.0M less gross profit. (Simplification: each driver is valued against the prior-period base, so the bridge is an approximation that the reconciliation step tests, not an exact decomposition. Revenue can stay flat while discounts rise if volume or price elsewhere offsets them.)
• Freight and supplier cost (unit cost including freight, meaning what each unit cost us delivered to the customer): in this illustration the whole $1.5M is freight, because freight spend rose from $4.0M to $5.5M and supplier prices were unchanged. If supplier prices had also risen, that increase would be a separate line in the table, computed the same way as price change times volume bought.
• Mix shift (customers buying more of the lower-margin products): $4.5M of revenue moved from a product earning a 50% margin to one earning 30%. That is a 20-point margin gap, and $4.5M x 20% = $0.9M.
• Unmapped or unexplained: the remainder, $4.8M - $2.0M - $1.5M - $0.9M = $0.4M, sitting in product codes I could not map.

Here "confirmed" means the driver's amount traces row by row to source records that tie out. "Suggested" means the pattern fits the data but I could not trace it fully.

Two coverage figures are reported side by side and never substituted for each other: the share of the drop attributed to named drivers (92% here) and the share of revenue that mapped cleanly to current product families.

The sentence for the CFO: "About 92% of the $4.8M drop is explained (4.4 of 4.8). The remaining $0.4M sits in codes I could not map, and here is what closing it would take."

The same pattern on other messy-data asks

The same habit carries over to other messy-data asks: say what you can measure, and label the rest.

• Lifetime-value (LTV) uplift with thin tracking: give a range with the assumptions that drive it, not one number.
• Marketing return on investment (ROI) with inconsistent tracking: report the share of spend and conversions you could trace, and say what is untraceable.
• Partial attribution (crediting a sale to the channel that caused it, when only some channels are tracked): say which channels are measured and present results as "at least", not "total".
• Free-text support tickets: hand-label a small sample to check how well categories fit, then report categories with that sample size.

Pitfalls

Silently dropping unmapped rows, mixing relative and point changes, and presenting a hypothesis as the cause.