Business Acumen and Commercial Context Questions

Direct answer

I would write the plan as a data function (analytics) and say so; the same method applies to engineering or reliability. Define what "active" means first, decompose the 25% goal into new, kept and returning users, then pick three initiatives that attack the biggest leaks, with a stated reason for each and a stated list of things I will not do.

Terms

• Active user: a person who performed a defined core action in a window, for example at least one meaningful action in the last 28 days. This definition must be written down; changing it later can move the number without any real change.
• Growth accounting: active users this period = active last period + new + returning (reactivated) - lapsed. It shows which flow to change.
• Activation: a new user reaching the first valuable action, such as completing a first task. The activation funnel is the sequence of steps to get there, with the share who drop at each step. Time to first value is how long that takes.
• Cohort: users who joined in the same period, tracked together. A holdout is a group deliberately left out of a change as a comparison. Reactivation means bringing a lapsed user back.
• Vanity total: a big number, such as total sign-ups, that does not show whether people stay. Reconciliation within an agreed tolerance: the new, retained, returning and lapsed counts must add up to the reported total within a set gap, for example 0.5%.

The arithmetic of the goal (illustrative base: 400,000 active users)

25% of 400,000 = 100,000 more active users over four quarters. As a straight line that is 25,000 net per quarter. If growth compounds instead, it is about 5.7% per quarter (1.25 to the power of 0.25 is 1.0574). I would plan to the straight line and track the compounded path beside it: compounding asks for about 23,000 net adds in Q1 and about 27,100 in Q4, so the straight line keeps the team ahead of the compounded path early, which leaves room for the harder last quarter.

Quarter plan: three prioritised initiatives (Q1)

How much each initiative adds (illustrative Q1 sizing)

• Initiative 1 adds no users itself; it makes the others measurable.
• Initiative 2: assume 120,000 new users a quarter. Raising 7-day activation from 30% to 40% gives 12,000 more activated users. If activated users are still active at 28 days 60% of the time against 10% otherwise, that is 12,000 x (0.60 - 0.10) = 6,000 more active users.
• Initiative 3: assume 200,000 lapsed users and a reactivation test showing 2% more return than the holdout: 200,000 x 0.02 = 4,000 returning users.

Together about 10,000 of the 25,000 a quarter, or 40% of the line, once both are fully live; that is a run-rate figure, not a Q1 result. On this plan's own timeline the first activation experiment reads out in week 10, so a winning flow reaches only about 3 of the 13 weeks of new users in Q1 (12,000 x 3/13 is about 2,800 more activated users, and their 28-day retention lands mostly in Q2), and the reactivation test runs weeks 6 to 12. Q1 therefore adds well under 10,000 net users from these initiatives; the full effect shows from Q2 on, and the Q1 deliverable is the measured, trusted baseline plus proven experiments. I would say that out loud: the remaining 15,000 depends on acquisition and product work owned elsewhere, and the plan names that gap and its owner. Activation gains continue each quarter because every new cohort benefits.

Plan outcomes in order: by week 3 the numbers are trusted; by week 10 the first experiment has read out; by week 13 the quarter's net adds are measured against the 25,000 line and the plan is rebased.

What I would deliberately not do

• Build a machine-learning personalisation model: expensive, and the first two initiatives are cheaper to test.
• Create more dashboards for vanity totals (total sign-ups) that do not separate retained from new.
• Accept ad hoc requests that are unrelated to the three initiatives without trading them off in writing.
• Chase a one-off spike from a campaign that brings users who do not return.

Customer-first version of the same plan

If the mission is "customer-first growth", the 90-day version keeps the three initiatives but states outcomes in customer terms: faster time to first value, fewer customers who give up in week one, more lapsed customers who come back for a reason they care about. Progress measures: time to first value, 7-day activation rate, 28-day retention of the new cohort.

Reliability or engineering variant

For an SRE (site reliability engineer) team the ladder is: protect the sign-up and first-use path (latency and error budgets on those paths), fix the top causes of failed first sessions, and add alerts on funnel drop-offs. An error budget is the amount of failure a service may have in a period before reliability work takes priority over new features; latency is how long a response takes. The same rule applies: each item names the metric it moves and what is left undone.

Pitfalls

Counting sign-ups as active users; a plan with no "not doing" list; no way to tell whether movement came from the initiatives or from seasonality (use holdouts, groups kept out of a change as a comparison).

Direct answer

Build the argument from the sales team's own evidence and in the unit they care about: do we make more money with the feature than without it? Put a dollar figure on what the feature wins, put a dollar figure on what it costs to build, run and support, and show the single number that would have to be true for it to pay off (the break-even). Then soften the reaction by involving sales in testing that number, offering something real in place of a flat "no", and attaching a revisit trigger so the decision is "not yet, and here is the bar" instead of "never".

Step 1: understand the demand before arguing

Pull the last two quarters of opportunity notes and lost-deal reasons. Count how many deals actually named the feature as a requirement (not "would be nice"), their annual contract value (ACV, the yearly subscription value of a deal), taken from the sales team's opportunity notes (their record of each deal), and the win rate (share of deals that close) with and without it. "Popular" often means loud, so the first job is to separate the number of requests from the number of deals blocked.

Step 2: the cost side, in the same units

Include four things: the one-time build, the ongoing maintenance (engineer time, the test matrix, meaning the combinations of settings and customer configurations that must be re-tested each release, and on-call), the extra cost to serve each account that uses it (support tickets, hosting), and the gross margin effect (gross margin is revenue minus the direct cost of delivering the product, as a share of revenue).

Step 3: the arithmetic (illustrative inputs)

Assume ACV $60k, gross margin 78% before the feature, 36 deals a year that mention the feature, a 20% base win rate, and sales claims a 10-point lift if we ship it. The feature adds $9k a year of support and hosting per account that uses it, $120k a year of maintenance, and a $150k build spread over 3 years.

acv, gross_margin = 60.0, 0.78         # $k per account per year
extra_cost = 9.0                       # $k per year extra support and hosting per account using the feature
fixed = 120.0 + 150.0 / 3              # $k per year: maintenance plus a 150k build spread over 3 years
deals, base_win, lift = 36, 0.20, 0.10 # deals per year that mention the feature; win rate; claimed lift
gp_per_account = acv * gross_margin - extra_cost
incremental_gp = deals * lift * gp_per_account
drag = deals * base_win * extra_cost   # extra cost on deals we would have won anyway
print(f"GP per account {gp_per_account:.1f}k ({gp_per_account / acv:.0%} margin)")
print(f"incremental GP {incremental_gp:.1f}k - fixed {fixed:.1f}k - drag {drag:.1f}k = {incremental_gp - fixed - drag:.1f}k per year")
print(f"break-even win-rate lift {(fixed + drag) / (deals * gp_per_account):.1%}")

Output:

GP per account 37.8k (63% margin)
incremental GP 136.1k - fixed 170.0k - drag 64.8k = -98.7k per year
break-even win-rate lift 17.3%

In words: each account that uses the feature earns $37.8k of gross profit instead of $46.8k, so its margin falls from 78% to 63%. The feature wins 3.6 extra deals a year ($136.1k of gross profit) but costs $170.0k of fixed spend, and it also adds $64.8k of cost on the 7.2 deals we would have won anyway. Net: about minus $98.7k a year. It breaks even only if the win-rate lift is 17.3 points, not the claimed 10.

The break-even comes from setting incremental gross profit equal to total cost: lift x 36 deals x $37.8k = $170.0k fixed + $64.8k drag, so lift = $234.8k / $1,360.8k = 17.3%. Here "drag" is the extra cost the feature adds on deals we would have won anyway (36 x 20% x $9k = $64.8k).

The number to take to the room is the 17.3-point break-even: "if lost-deal data shows a lift above that, I will change my view".

Step 4: the operational complexity argument

Convert it into capacity: the $120k a year of maintenance is about half an engineer (at an assumed $240k loaded cost per engineer-year, salary plus overhead), a half-engineer not shipping the roadmap, plus a larger test matrix and more support escalations. State what the half-engineer would do otherwise, with its own estimated return, so complexity is a priced trade and not a vague worry.

Step 5: soften the reaction

1. Pre-wire (brief people privately before the meeting). Share the numbers with the sales leader one-to-one before any group meeting, so nobody is ambushed.
2. Use their data. Review ten lost deals together; if sales finds the lift is real, you update.
3. Offer alternatives, not just a refusal: a narrower version covering the 80% use case, a paid add-on priced to cover its cost to serve, a partner or workaround for the named deals, or a dated revisit.
4. Acknowledge the cost to them in plain words ("this makes your quarter harder") and give enablement (sales materials and training, such as a battlecard, a one-page sheet on how to answer the gap against a named competitor, or a reference customer) for deals where the gap hurts. In the room that sounds like: "This makes your quarter harder and I do not want to wave that away. The numbers say it needs a 17-point win-rate lift to pay for itself and you are claiming 10. Let us review ten lost deals together; if the lift is there I will change my view. Meanwhile here is a narrower version for the named deals."
5. Define the trigger: "if the lost-to-feature rate exceeds X for two quarters, we reopen".

Trade-offs and pitfalls

• Margin dilution is not the whole picture. Customers who use the feature may churn less, which would improve the case; include a retention estimate if you have one, and say it is excluded if you do not.
• One huge strategic logo (a prestigious customer whose name helps win others) can justify an exception. Handle it as a priced custom deal, not a roadmap commitment.
• Never argue from engineering taste ("it is messy"). Argue from money and capacity.
• Do not call sales wrong. The claim is "unproven at the cost we would pay", which is testable.

Direct answer

Connect each roadmap item to a company objective through a written causal chain: item, user behaviour it changes, team metric that moves, company-level number that moves as a result. If I cannot write that chain in two sentences with a plausible size, the item does not ship this cycle. I make this a routine step in planning, not a one-time exercise.

Terms

OKR (objectives and key results) is a planning format: an objective states a qualitative aim, and key results are measurable outcomes that show it was reached. A roadmap is the ordered list of initiatives the team will build. An item "ladders up" when each step of cause and effect leads to the next level above it, ending at a company objective. Expansion means existing customers spending more (extra seats, a higher plan); net revenue from existing customers is that expansion minus what is lost to cancellations and downgrades; a renewal is the date a customer decides whether to continue. A holdout is a group deliberately kept on the old experience as a comparison, and a guardrail is a metric that must not get worse while you chase the main one.

The process

1. Start from the company objective and its constraint, in words: for example, "Grow revenue from existing customers this year."
2. Identify the mechanism your team can influence. What user behaviour, if it changed, would move that objective?
3. Write the ladder for each candidate item and size it roughly.
4. Test each item against three questions: does it move the key result directly? Is the cause-and-effect plausible, with evidence (data or research) rather than hope? Is this the cheapest way to move it?
5. Rank, cut and write down the assumptions so leadership can see what the alignment depends on and revisit it when a number changes.

Worked example: a product team that owns customer onboarding for a business software product

Sizing the item (illustrative)

Assume 1,000 new accounts a month. Moving setup completion from 40% to 55% means 550 instead of 400 complete it: 150 more accounts a month. Suppose past data show 25% of accounts that complete setup expand within 90 days against 10% of those that do not, with an average expansion of $2,000 a year. Each extra completing account then adds 0.15 expansions: 150 x 0.15 = 22.5 expansions x $2,000 = $45,000 of annual expansion revenue per monthly cohort, about $540,000 across twelve cohorts. Accounts that set up well may have expanded anyway, so I would count only half until the holdout confirms the effect: about $270,000 a year. Against a build cost of 12 person-weeks at an assumed $2,400 loaded cost per week ($28,800), the item clears the bar; an item with no such chain has no number to set against its cost.

What I would drop, and why

Suppose the backlog also holds "redesign the settings page" and "add a dark theme". Neither has a link to the setup milestone or to expansion revenue; they are legitimate but belong to a different objective. I would drop or defer them from this cycle's commitments, tell the requesters why, and keep them in a visible parked list. Another to drop: an item that ladders up in a story but whose evidence is only an executive's preference. It stays on the list until someone supplies a test or data.

When team metrics conflict

Say a growth team is measured on sign-ups and a support team on ticket volume. More sign-ups bring more tickets, so each team's win hurts the other. Resolve by agreeing a shared outcome both feed (retained, active accounts), keeping each team's metric as a guardrail for the other, and escalating tie-breaks to the owner of the shared outcome. Document assumptions in the plan (what each number is expected to do and what would change our mind), so alignment can be validated later instead of re-argued.

What a well-aligned function looks like in concrete outcomes

Each team can name the one company number it moves; leadership can point to items that were cut because they did not ladder up; metrics are reviewed on a schedule and the roadmap changes when the evidence does; teams rarely argue about priorities because the ordering criteria are shared.

Pitfalls

Forcing every item to ladder (maintenance and reliability work has a case on risk, which should be stated, not hidden); key results that measure activity, not outcome; objectives so broad everything fits.

Direct answer

I would not answer "yes" or "no" to a 2% target. I would first ask what 2% of what: is it 90% to 92% accuracy (2 percentage points) or 90% to 91.8% (2% relative)? Then I would turn it into the number of wrong decisions removed per month, put a price on each wrong decision, subtract the full cost of the model over a time horizon (build, run and maintain), and compare that with cheaper ways of getting part of the same gain. If the payback is longer than the period the model will stay accurate, the gain is not worth it, however good 2% sounds.

How I decide

1. Clarify the metric. Accuracy is the share of predictions that are right. It hides what kind of error was removed. If only 2% of cases are positive, a model that always says "no" is 98% accurate, so I would check precision and recall (the share of flags that are right, and the share of real cases found) before accepting accuracy as the measure.
2. Convert to errors avoided. Volume x accuracy gain.
3. Price one error. The time, money or customer harm of each wrong prediction, from the people who clean them up.
4. Cost the whole life. One-off build, monthly serving cost (the compute it takes to run the model on each prediction, called inference), monthly maintenance (retraining, monitoring, on-call), and the opportunity cost (the value of the next-best thing those engineers could have built instead).
5. Check the 2% is real. A gain smaller than the noise in the test set is not a gain.
6. Compare cheaper options. Better training data, a threshold change, a business rule, or a human check on low-confidence cases may capture much of the value for little cost.

Worked example (illustrative)

A classifier assigns 100,000 invoices a month to expense categories and is 90% accurate. Accuracy of 92% means 2,000 fewer wrong categories a month (10,000 errors become 8,000, a 20% reduction in errors).

• Cost of one error: about 4 minutes of an accountant's time at $45 an hour = $3.
• Value: 2,000 x $3 = $6,000 a month.
• Cost: build $60,000 (2 engineers x 6 weeks x $5,000 per engineer-week), plus $500 a month extra inference and $1,500 a month maintenance, which is $2,000 a month.
• Net: $6,000 - $2,000 = $4,000 a month, so payback (the months it takes for cumulative net benefit to equal the build cost) is $60,000 / $4,000 = 15 months.

Fifteen months is long if invoice formats shift every year and the model must be retrained at that point. I would take it to the stakeholder as: "this pays back in 15 months if it holds its accuracy; a rule-based fix for the two worst categories might recover part of the gain in two weeks."

Noise check: on a 5,000-example test set, accuracy near 90% has a standard error of about 0.4 points (the square root of 0.9 x 0.1 / 5,000), so a 2-point gain is clearly real while a 0.5-point gain would not be. The standard error is the typical size of the random wobble in a measured accuracy from the particular sample you tested on; as a rule of thumb, a gain more than about twice the standard error (here 0.8 points) is unlikely to be luck. When comparing two models, if I conservatively treat their scores as independent, the gap has a standard error of about 0.6 points (0.4 x the square root of 2), so 2 points still clears twice that (1.2) and 0.5 does not. Because both models are scored on the same examples, their errors are correlated, so a paired test such as McNemar's (which looks only at the examples where the two models disagree) is usually tighter than this independent figure; 0.6 is a cautious upper estimate, not a floor.

Trade-offs and pitfalls

• A big accuracy gain on an easy segment may be worth nothing if the costly errors are elsewhere.
• Value per error is rarely uniform, so a single average price can mislead.
• Maintenance is the cost most often left out; models decay as data changes.
• What would change my answer: a much higher cost per error (for example regulatory exposure), a much larger volume, or evidence the current error rate is growing.

Direct answer

I pick one hypothetical model, write down every input (volume, uplift, unit value, build cost, run cost, risk haircuts), turn it into a monthly net figure and a payback period (the months needed to earn back the build cost), and then show finance how that figure moves when the two least certain inputs move. The point of the sensitivity table is that finance sees which two numbers they are really being asked to believe. For the hypothetical here (an AI model that drafts replies for a support team and also routes tickets), the base case is a net saving of $24,660 a month and a payback of 7.3 months, and it stays comfortable unless the cash share falls well below the assumed 50%.

Terms

• Loaded cost: salary plus benefits and overhead per hour of an employee.
• Inference: running the trained model to produce predictions; its cost is the run cost.
• Payback period: months until cumulative net benefit equals the up-front build cost.
• Cash share: the fraction of freed-up hours that turns into real spend avoided (a hiring plan reduced, overtime or contractor hours cut). The rest is capacity that gets redeployed, which is real value but not a cash saving.

Input template for a finance partner

The calculation (assumptions are the ones in the table)

TICKETS = 40_000          # tickets per month
ELIGIBLE = 0.55           # share the model can draft a reply for
ACCEPTED = 0.70           # share of eligible drafts agents accept
HOURLY = 38               # $ loaded cost per agent hour
REWORK = 9                # $ per misrouted ticket
MISROUTES_AVOIDED = TICKETS * (0.08 - 0.05)   # 8% down to 5%
RUN_COST = 10_000         # $ per month: inference, hosting, upkeep
BUILD_COST = 180_000      # $ one-off

def net_per_month(minutes_saved, cash_share):
    hours = TICKETS * ELIGIBLE * ACCEPTED * minutes_saved / 60
    gross = hours * HOURLY + MISROUTES_AVOIDED * REWORK
    return hours, gross, gross * cash_share - RUN_COST

hours, gross, net = net_per_month(6, 0.5)
print(f"hours saved {hours:,.0f}, gross labour value ${gross:,.0f}, net ${net:,.0f}/month, payback {BUILD_COST/net:.1f} months")
print("net $/month (payback months); rows = minutes saved per ticket, columns = cash share")
print("min   25%               50%               75%")
for m in (3, 6, 9):
    cells = []
    for c in (0.25, 0.5, 0.75):
        _, _, n = net_per_month(m, c)
        cells.append(f"{n:8,.0f} ({BUILD_COST/n:5.1f}m)" if n > 0 else "    <=0 (never)  ")
    print(f"{m:>3}   " + "   ".join(cells))

Output:

hours saved 1,540, gross labour value $69,320, net $24,660/month, payback 7.3 months
net $/month (payback months); rows = minutes saved per ticket, columns = cash share
min   25%               50%               75%
  3         15 (12000.0m)     10,030 ( 17.9m)     20,045 (  9.0m)
  6      7,330 ( 24.6m)     24,660 (  7.3m)     41,990 (  4.3m)
  9     14,645 ( 12.3m)     39,290 (  4.6m)     63,935 (  2.8m)

Arithmetic behind the first line: 40,000 x 0.55 x 0.70 x 6 / 60 = 1,540 hours saved a month; 1,540 x $38 = $58,520; misroutes avoided = 40,000 x 3% = 1,200, times $9 = $10,800; gross $69,320; at 50% cash share that is $34,660; minus $10,000 run cost = $24,660; $180,000 / $24,660 = 7.3 months.

The two weakest assumptions and what they do

The weakest are minutes saved per ticket (self-reported until measured) and cash share (a management decision, not a model property). From the table:

• Cash share falls to 25% at 6 minutes: net $7,330 a month, payback 24.6 months.
• Minutes saved fall to 3 at 50% cash share: net $10,030, payback 17.9 months.
• Both fail together (3 minutes, 25%): net $15 a month, so the model never repays its build cost.
• Both hold at the optimistic end (9 minutes, 75%): net $63,935, payback 2.8 months.

So the honest statement to finance is: "Base case pays back in about 7 months. It pays back inside two years in seven of the nine cells I tested, and fails only if the cash share falls to 25% at 6 minutes (24.6 months) or both inputs sit at their low ends. I recommend a pilot with a holdout group to measure minutes saved before the full build, and an up-front agreement on what counts as cash."

Revenue lift, the third kind of impact

If the model is a recommender or a pricing model, the value is incremental contribution margin, not revenue. Incremental means on top of what would have happened without the model. Contribution margin is what an order earns after its variable costs (product cost, shipping, payment fees, discounts). A randomised holdout is a group of randomly chosen visitors who do not see the model, so their behaviour shows what would have happened anyway; uplift is the difference between the two groups.

Illustrative case: 5,000,000 visitors a month, 2.00% conversion in the holdout and 2.05% with the recommender, and $12 contribution margin per order. Uplift is 0.05 percentage points: 5,000,000 x 0.0005 = 2,500 extra orders; 2,500 x $12 = $30,000 a month; minus the same $10,000 run cost = $20,000 net; payback on the $180,000 build is 9.0 months. The same two-weakest-inputs test applies. If uplift is only 0.03 points: 1,500 extra orders, $18,000, net $8,000, payback 22.5 months. If the lift was bought with discounts that cut margin to $9 an order: 2,500 x $9 = $22,500, net $12,500, payback 14.4 months. Revenue that would have happened anyway, or that came at a lower margin because of discounts, does not count.

Pitfalls

• Counting freed hours as cash when nobody changes headcount or spend.
• Quoting the base case without the sensitivity table.
• Leaving out run and maintenance cost, which is certain, while benefits are uncertain.
• Using accuracy-style model metrics in place of dollars.