Data-Driven Business Decision-Making Questions
Moving from data to a defensible business recommendation and being transparent about the evidence behind it. Covers weighing conflicting or weak evidence sources, including third-party reports and vendor claims, reconciling figures that disagree and checking whether a headline movement can be trusted, documenting assumptions and sensitivity, sizing an impact from limited inputs with stated assumptions, quantifying and communicating uncertainty in business terms, choosing between options when the data is incomplete or a short-term cost trades against a longer-term gain, deciding how much precision a decision needs, making a recommendation reproducible and auditable, defending it to skeptical stakeholders, and revisiting it when later results contradict it. Tests whether a candidate can reach and justify a recommendation from evidence rather than intuition. Building a full business case or financial model, experiment and causal-inference methods, metric definition, query writing, dashboard building, and presentation craft are covered elsewhere.
You are preparing a business case for a new market or partnership, but most of the inputs are assumptions rather than hard facts. How would you build a sensitivity analysis, identify the assumptions that matter most, and use that to sharpen your final recommendation?
Sample Answer
Direct answer
When inputs are guesses, the number matters less than knowing which guess moves the answer. Build a simple model, put a plausible range on each assumption, vary one at a time to see which swing the result most (sensitivity analysis), find the break-even value of the biggest one, and spend your remaining effort on that single assumption before recommending.
Step 1: Model (illustrative market entry)
Annual net = accounts x win rate x revenue per account x gross margin - fixed cost
Base case: 5,000 reachable accounts, 4% win rate, $12,000 revenue per account per year, 70% gross margin, $1.2M fixed cost. That is 5,000 x 0.04 = 200 customers, $2.4M revenue, $1.68M gross profit, and net of $480k.
Step 2: Ranges, one input at a time
| Assumption | Low | High | Net at low | Net at high | Swing |
|---|---|---|---|---|---|
| Win rate | 2% | 6% | -$360k | +$1,320k | $1,680k |
| Reachable accounts | 4,000 | 6,000 | $144k | $816k | $672k |
| Revenue per account | $10k | $14k | $200k | $760k | $560k |
| Gross margin | 65% | 75% | $360k | $600k | $240k |
| Fixed cost | $1.3M | $1.1M | $380k | $580k | $200k |
Sorted by swing, this is a tornado chart (bars ordered widest first). The win rate dominates: it is both the most uncertain and the most powerful.
Step 3: Break-even on the key assumption
Break-even win rate = 1.2M / (5,000 x 12,000 x 0.7) = 2.86%. So the case works if we win more than about 29 of every 1,000 accounts reached. A grid of win rate against revenue per account shows where the decision flips:
| Win rate | $10k | $12k | $14k |
|---|---|---|---|
| 2% | -$500k | -$360k | -$220k |
| 3% | -$150k | $60k | $270k |
| 4% | $200k | $480k | $760k |
Step 4: Sharpen the recommendation
Do not approve the full $1.2M on a guessed win rate. Approve a three-month test at a quarter of the fixed cost ($300k), designed to measure the win rate on real prospects. Gate: proceed if the observed win rate is at least 3.5% (comfortably above the 2.86% break-even), stop if it is clearly below.
Check that the test can tell these apart. The win rate is a proportion, so its uncertainty depends on how many prospects are worked. With 1,000 prospects and 35 wins (3.5%), the 95% interval is roughly 2.4% to 4.6%, which still contains the 2.86% break-even. About 2,200 prospects are needed before a 3.5% result sits clearly above 2.86% (one-sided, 95%). That is nearly half of the 5,000 reachable accounts, so either size the test to reach that many, accept a wider band and treat results between about 2.5% and 3.5% as inconclusive rather than as a pass or fail, or use an earlier signal such as meetings booked as a proxy.
Moving every input to its worst end at once gives -$780k, and its best gives +$2.68M; those joint extremes are unlikely and are shown only to bound the case.
Pitfalls: varying every input by the same percentage hides which one matters; treating the base case as a forecast; and not telling the audience the range is judgement, not data.
Revenue in the data warehouse is 10% above the figure finance reports for the same month, and leadership needs one number for tomorrow's review. How do you work out why they differ, which figure you would stand behind, and how confident do you tell leadership you are?
Sample Answer
Direct answer
Do not pick a number by gut or average the two. Build a bridge (a line-by-line reconciliation from one figure to the other) until the gap is explained. Then stand behind finance's number as reported revenue (it comes from the closed, reviewed ledger), call the warehouse figure a different measure, and tell leadership how much of the gap you have explained. The exception: if the bridge shows finance missed something legitimate, say so and change your position.
Step 1: Pin the definitions
Two correct numbers can differ because they measure different things. Check: revenue recognized (earned under accounting rules) vs billed or booked; gross vs net of refunds, credits, tax and discounts; currency conversion date; time-zone cutoff for "the month"; which legal entities are in scope; and whether finance's figure includes month-end adjustments made after the warehouse loaded.
Step 2: Localize the gap
Compare the two by day, product and region. A gap spread evenly smells like a definition difference. A gap concentrated on one day or one product smells like a pipeline defect or a late adjustment.
Step 3: Test the usual suspects
- Refunds and credit notes in finance but not netted in the warehouse.
- Duplicate rows: an order joined to several payment rows is counted once per payment (a join fan-out).
- Timing: invoices dated in the month but recognized in the next one.
- Test or internal accounts left in the warehouse.
Worked example (illustrative numbers)
Finance reports $10.0M and the warehouse $11.0M, so the warehouse is 10% higher and the gap is $1.0M.
| Bridge item | $M |
|---|---|
| Refunds and credits not netted in warehouse | 0.45 |
| Duplicate order lines from a join fan-out | 0.25 |
| Invoices recognized in the following month | 0.20 |
| Test and internal accounts | 0.05 |
| Unexplained | 0.05 |
| Total gap | 1.00 |
Removing the four explained items takes the warehouse to 11.0 - 0.95 = $10.05M, within $0.05M (0.5%) of finance.
What I tell leadership
"Revenue for the month is $10.0M, the finance close figure. The warehouse showed $11.0M. We have explained $0.95M of the $1.0M gap (95%); $0.05M is still unexplained and I will report back on it. I am highly confident in $10.0M as reported revenue. I am less confident in warehouse-based breakdowns by segment until the double-counting is fixed."
Confidence is stated as how much of the gap is explained plus the size of what remains, not as a vague "fairly sure".
Pitfalls and what would flip the call
- Never hide the unexplained piece inside an "other" bucket.
- Do not blame finance without evidence. If the bridge showed finance had excluded a legitimate entity, I would say finance's figure was incomplete and quote the corrected one.
- Afterwards, fix the warehouse model, add a monthly automated reconciliation check against the ledger, and publish one agreed definition of revenue.
You recommend a product change that cuts short-term revenue by 8% but, per experiments, lifts 12-month retention by 10%. Finance is skeptical. What evidence would you bring, how would you show how robust the case is to your assumptions, and how would you limit the downside if you are wrong?
Sample Answer
Short answer
Bring the evidence in the shape Finance uses: a cash-flow view over a stated horizon, built on the measured effect with its uncertainty, and a sensitivity table showing how much of the lift must be real for the change to pay back. Then cap the downside with a staged rollout and pre-agreed stop rules.
Evidence to bring
- The experiment readout with the lift and its confidence interval (the range of effects consistent with the data), not just the point estimate.
- The retention definition and horizon: was 12-month retention measured, or extrapolated (projected forward from early weeks of data)? If extrapolated, say so.
- The mechanism: why would this change keep customers (usage, switching cost, price perception), supported by behavior data.
- Unit economics (what one customer earns and costs us) on margin, not just revenue, since Finance will ask about cost to serve (the cost of supporting and delivering to that customer).
Showing robustness: a sensitivity analysis
Sensitivity analysis means re-running the model while changing one assumption at a time to see whether the conclusion survives. Illustrative setup: a cohort (a group of customers who start together, tracked as a unit) of 20,000 customers paying $100 a month; baseline 12-month retention 70%; "+10%" read as a relative lift (70% to 77%, about 1,400 more customers at month 12); the 8% revenue cut applies for the first 3 months; constant monthly churn (the same share of remaining customers leaves each month); revenue basis, no discounting.
n, price, base12, lift = 20000, 100, 0.70, 0.10 # customers, $/month, 12-month retention, relative lift
def monthly_net(real, cut_months=3, months=24, cut=0.08):
bm = base12 ** (1 / 12)
nm = (base12 * (1 + lift * real)) ** (1 / 12)
total, out = 0, []
for m in range(1, months + 1):
new = n * nm**m * price * ((1 - cut) if m <= cut_months else 1)
total += new - n * bm**m * price
out.append(total)
return out
def summary(label, o):
pay = next((i + 1 for i, x in enumerate(o) if x >= 0), None)
print(label, "lowest", round(min(o)), "payback month", pay, "month 24", round(o[-1]))
for real in (1.0, 0.5, 0.25):
summary(f"{real:.0%} of lift, 3-month cut:", monthly_net(real))
summary("100% of lift, permanent cut:", monthly_net(1.0, cut_months=24))
lo, hi = 0.0, 1.0
for _ in range(50):
mid = (lo + hi) / 2
lo, hi = (mid, hi) if monthly_net(mid)[-1] < 0 else (lo, mid)
print("break-even share of measured lift:", round(hi, 3))
Output:
100% of lift, 3-month cut: lowest -369842 payback month 8 month 24 2707517
50% of lift, 3-month cut: lowest -410343 payback month 12 month 24 1116644
25% of lift, 3-month cut: lowest -431180 payback month 18 month 24 329391
100% of lift, permanent cut: lowest -691010 payback month 23 month 24 209000
break-even share of measured lift: 0.145
What the code computes, in words
base12 ** (1 / 12)turns "70% survive 12 months" into a monthly survival rate: the number that, multiplied by itself 12 times, gives 0.70. That is 0.9707, so about 2.9% of customers leave each month. It is an assumption (steady monthly churn), and everything below rests on it.bmis that monthly survival rate for the baseline.nmis the same for the new design, with 12-month retention raised bylift * real.realis the share of the measured lift we assume is true: 1.0 is all of it, 0.5 is half.- Each month
m, customers still active aren * rate**m. Revenue is that count times $100, and in the first 3 months the new design earns 8% less.new - baselineis that month's cash difference;totaladds the differences up, so it shows how far ahead or behind the baseline the new design is so far. - Payback month is the first month
totalis zero or higher. The last loop is a bisection: it tries arealhalfway between 0 and 1, keeps the half in which the month-24 total flips from negative to positive, and repeats 50 times to find the break-even share of the measured lift.
Hand check of months 1 to 3 (100% of lift)
Monthly survival is 0.9707 for baseline and 0.9785 for the new design (0.77 ^ (1/12)).
Month 1: baseline 20,000 x 0.9707 x $100 = $1,941,429
new 20,000 x 0.9785 x $100 x 0.92 = $1,800,357
difference = -$141,072
Month 2: difference = -$123,004
Month 3: difference = -$105,766 (running total -$369,842)
The gap narrows each month because the new design loses customers more slowly, and from month 4 the full price returns. That running total of about -$370k is the "lowest" figure in the output.
Reading it for Finance
- The change loses money before it makes money: the cohort sits about $370k to $430k below the baseline at its lowest point, so that is the exposure.
- The case survives even if only a quarter of the measured lift is real: 25% of a 10% relative lift is 2.5%, which moves 12-month retention from 70% to 71.75%, and the cohort is still positive at month 24 (+$329k). Break-even needs about 14.5% of the lift, roughly a 1.5% relative lift (70% to about 71%).
- The assumption that matters most is how long the cut lasts. If the 8% cut is permanent, the case barely clears at month 24 (+$209k, payback in month 23), so I confirm that with the owner of the change.
Limiting the downside if I am wrong
- Roll out to 25% first: the full cohort's first-quarter price cut is at most 20,000 x $100 x 8% x 3 months = $480k (about $460k once customers who leave are allowed for, which is what the model computes); at 25% it drops to roughly $115k. This is the gross revenue given up in the cut, a different figure from the $370k trough above, which is net of the extra customers the retention lift keeps; I show Finance both so the exposure is not read two ways.
- Keep a holdout so real retention can be compared with the extrapolation.
- Pre-agree reversal rules with Finance (for example, early retention indicators below the break-even path at the first checkpoint) and review at a fixed date.
- Give Finance the model so they can change the assumptions themselves.
Your analysis suggests a revenue upside of 5-15%, but the range is wide, and the C-suite will decide on funding based on what you say. How do you structure the presentation so they understand the upside, the downside and the cost of being wrong without the recommendation sounding evasive, and what do you put behind your range?
Sample Answer
Direct answer
Open with the recommendation and what it commits them to, then show three scenarios, the cost of being wrong in both directions, and the single assumption that creates the width of the range. A wide range sounds evasive only when it is presented as vagueness. Presented as "the range comes from one thing we can measure early, and we fund in stages", it sounds like control.
Structured elaboration
Slide flow (five slides):
- Recommendation and ask: approve the first $1.2M tranche (a slice of the total budget released first) now; the rest is released at a gate (a checkpoint where agreed results must be met before more money is released).
- Range with its driver: low, base and high, and the one assumption that moves them.
- Upside, downside and cost of being wrong: both directions.
- What sits behind the range: the evidence and the model checks.
- Stage gates: what we will see by when, and what we will do if it is missing.
What goes behind the range (this is the credibility):
- A driver model: the range comes from a formula, not a gut feel. Upside = eligible accounts x adoption rate x extra revenue per adopter.
- Evidence for each input: where the adoption range came from (for example, the two most similar past launches).
- Interval intuition: I state the 5-15% as an "80% range" (a stated modelling choice): about 8 times in 10 the result should land inside it, with a 1-in-10 chance each of falling below or above. It is not a promise that 10% will happen. The 25/50/25 case weights used below are a separate, simpler device: three representative outcomes (low, base, high) with my judgment of how likely each is, used to get one expected value. They summarize the range roughly; they are not derived from the 80% statement.
- Model uncertainty: the risk that the model itself is wrong. I show a second method (for example, a simple top-down market share estimate: total market size times the share we could plausibly win, rather than building up from accounts) and say whether the two agree.
Worked example
Illustrative inputs: annual revenue $120M, so 5% is $6M, 10% is $12M and 15% is $18M. The program costs $4M. Driver model: 30,000 eligible accounts x adoption x $1,000 extra revenue per adopter per year (an assumption; I treat it as contribution after the cost of serving the account, so it can be netted directly against the $4M program cost). Each adoption rate maps to the revenue range: 30,000 x 20% x $1,000 = $6M, which is 5% of $120M; 40% gives $12M (10%); 60% gives $18M (15%).
| Case | Adoption | Extra revenue | Net of $4M cost |
|---|---|---|---|
| Low (5%) | 20% | $6M | +$2M |
| Base (10%) | 40% | $12M | +$8M |
| High (15%) | 60% | $18M | +$14M |
The entire range is one assumption: adoption. Break-even adoption is $4M / (30,000 x $1,000) = 13.3%. Past launches reached 25% and 45% (illustrative), so even the lower one clears break-even, but we do not know our case is like those.
Cost of being wrong. If we fund everything and adoption is below 13.3%, we lose money: the worst case is the full $4M. If we do nothing and the base case is true, we forgo about $8M net. I weight the three cases 25/50/25, which gives expected gross upside of 0.25 x 6 + 0.5 x 12 + 0.25 x 18 = $12M, or $8M net. These weights are my judgment, so I show them and invite challenge.
Ask: release 30% of the budget, $1.2M, for a 3-month rollout to a subset. Gate: continue only if adoption of eligible accounts in that group is at or above 15%. Maximum loss if we stop at the gate: $1.2M, not $4M.
Trade-offs and pitfalls
- Never hide the width: showing only the 10% midpoint invites the question "what if it is 5%?" with no answer ready.
- Do not offer "somewhere between 5 and 15" with no recommendation. Evasive means no action; staged funding is an action.
- If adoption in the subset comes in under 15% the recommendation changes, and I say so up front.
You are evaluating a new business segment with very little historical data, no direct benchmark, and inconsistent customer feedback. How would you make a recommendation anyway, and what guardrails or pilot design would you put in place to manage the uncertainty?
Sample Answer
Direct answer
With little data I still recommend, but I recommend a bounded, reversible step instead of a full commitment. I make the assumptions explicit, size the pilot so that its result can actually change my mind, and set the spending cap and the stop rule before it starts. Thin data changes the shape of the decision (small, staged, checkable), not whether I give a view.
Structured elaboration
Act now or validate first? Four tests.
- Reversibility: can we undo it cheaply? A pilot yes, a multi-year contract no. Reversible decisions can be made on thin evidence.
- Cost of waiting: is a window closing (competitor, season)? If delay is cheap, gather more data first.
- Value of information: would more data plausibly flip the decision? If every outcome of a study leads to the same action, skip the study. Example: if the segment is worth entering whether the study shows 5% or 15% conversion, the study has no value.
- Cost of the test versus the cost of being wrong: do not spend $200k to avoid a $50k mistake. Applied here: a capped $150k pilot is reversible and the full launch is not, so the pilot passes tests 1 and 4.
State the assumptions the decision rests on. An assumption is something we believe but have not shown. Typically: customers in the new segment have the problem, will pay roughly what we charge, and can be reached at an acceptable cost. I rank them by how much the decision depends on each, and test the riskiest first.
Communicate the limits of the sample. Inconsistent feedback from 9 customers, 6 positive, is not "two thirds are positive". The 95% interval (the range of true shares that fit the data) for 6 of 9 runs from roughly 35% to 88%, which includes "barely half" and "nearly everyone". I say that plainly, and also say who the 9 were (who picked them, who is missing).
Worked example
Illustrative: a new small-business segment for a product sold to enterprises. No history, no benchmark, 9 mixed interviews.
Pilot design:
- Question: can we win qualified small-business leads at a rate that makes the segment worthwhile?
- Scope: 60 qualified leads over 8 weeks, with a separate small team and a hard spend cap of $150k.
- Success bar (set now): at least 6 of 60 convert (10%) and the sales cycle (time from first contact to signed deal) under 45 days. A qualified lead is a prospect who fits the target customer profile and has a real need and budget.
- Stop rule: if fewer than 3 convert by week 6, stop and write up why.
- Owner and check date: the segment lead, with a review at week 4.
Is 60 leads enough? This is a power question: power is the chance the pilot reaches the bar when the segment really is good. The binomial calculation (the standard way to count how often a given number of successes appears in 60 independent tries at a fixed rate) gives the chance of seeing 6 or more conversions: if the true rate were 3%, under 1%; at 5%, about 8%; at 10%, about 56%; at 15%, about 90%. Read it this way: if the segment is really poor (3%), a pass by luck is very unlikely, so a pass is meaningful evidence the rate is not tiny. If the segment is really at 10%, we still fall short of 6 about 44% of the time (100% minus 56%), so a miss is not proof of failure. I therefore treat a result of 3 to 5 conversions as "extend the pilot" and not as a verdict.
Check the week-6 stop rule the same way, because by week 6 only about three quarters of the leads (roughly 45 of 60) have been worked. At a true 10% rate, the chance of fewer than 3 conversions among 45 leads is about 16%, so the stop rule would wrongly end a segment that is exactly on the bar about one time in six. At a true 5% it fires about 61% of the time and at 15% only about 3%. That is acceptable for a spending guard on a $150k cap, but I say so: week 6 is a cheap-stop check for clearly poor results, and the launch decision waits for the full 60 leads at week 8.
Recommendation to leadership: approve the capped pilot, not the segment launch. Decision on launch at week 8 using the bar above.
Trade-offs and pitfalls
- The recommendation changes if a cheap, fast study (for example 10 more interviews with the right buyers) is available and could flip the decision; then validate first.
- Pitfall: a pilot too small to detect the effect you care about. Compute its power (as above) before running it.
- Pitfall: moving the success bar after seeing results.
Unlock Full Question Bank
Get access to all 25 Data-Driven Business Decision-Making interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.