Prioritization and Trade-Off Decisions Questions

Direct answer

An impact versus effort grid is a two-axis chart: vertical is how much value an item delivers, horizontal is how much it costs to build. To make placements defensible rather than opinion, I would agree the scales before anyone places anything, have people place items privately and then reveal, require effort from the engineers and impact evidence from data, and write a one-line reason for every placement. Then I would treat each quadrant differently and be honest about where the grid stops being useful.

Running the workshop for about a dozen ideas (60 to 75 minutes)

1. Define the axes (10 min). Impact is tied to one named metric (for example, weekly active users) and scored 1 to 5. Effort is in engineer-weeks (one engineer working full time for one week), bucketed small (up to 1), medium (2 to 4), large (5 or more).
2. Silent, individual placement (10 min). Everyone places every item alone first. This avoids anchoring: the first number or opinion spoken aloud pulls everyone else's estimates toward it.
3. Reveal and discuss only the disagreements (30 min). Where placements differ by more than one band, the people at each end explain with evidence. Engineers own the effort axis, product and data own the impact axis.
4. Record (10 min). One line per item: the evidence for its placement, and what is unknown.

What to do with each kind of item

Worked example with 12 ideas for a reporting product (illustrative):

That is 3 quick wins, 3 big bets, 2 fill-ins, 3 time sinks and 1 unplaceable, which sums to 12. The three time sinks are declined in writing, the AI summary gets a two-day spike (can the model summarise our reports well enough, and at what cost per report) before it is placed, and the quick wins are sequenced first.

The same method in other situations

• BI request queue: impact is decisions influenced, effort is analyst-days.
• Ops investigation list: impact is the cost of the problem, effort is the time to investigate.
• Customer discovery list: impact is how many interviewed customers raised it.
• Eisenhower grid (urgent versus important): urgent and important means do now, important but not urgent means schedule, urgent but not important means delegate, neither means drop.

Where it breaks down

• False precision: a dot on a chart looks objective but is a guess.
• Ignores confidence, risk and dependencies: an item can look like a quick win and hide a dependency on another team.
• Position hides size: a huge-impact slow item and a modest one can sit in the same quadrant.
• Quick-win drift: a team that only ever picks quick wins never tackles big bets, so reserve a share of each quarter for one.
• Group opinion: consensus placement is still opinion, so evidence notes matter.

When these bite, move to a scored method such as RICE (Reach x Impact x Confidence, divided by Effort, which adds a confidence factor the grid lacks).

Direct answer (structure of a strong story). Pick a real case where an urgent escalation (an incident, an executive demand, a failed job) hit a strategic project you owned, and show the weighing, the decision, the communication and the lesson. Below is a realistic shape; use your own facts and keep any numbers you cite true.

Situation. I owned a multi-quarter project to rebuild a reporting pipeline. Two weeks before an internal demo, the nightly job feeding a key customer dashboard started failing, and the customer's team escalated. Both claims on my time were legitimate.

What I weighed

• Harm now versus harm later: stale data at a customer was already damaging trust; the demo slipping a few days would cost an internal milestone, not a customer relationship.
• Reversibility: a missed demo can be rescheduled; lost customer trust is slower to repair.
• Who else could help: I could hand the incident to the on-call owner, but the root cause sat in my team's code.
• Cost of the project slipping, and how many days I could absorb before the dependency date moved.

Decision. I took the escalation first: paused the project, gave the incident two focused days, and put a second engineer on the demo preparation using a narrower scope (the three screens that mattered most to the audience).

Communication. Same day: told the customer contact what failed, what I was doing, and when the next update would come. Told the demo audience and my manager that the demo was moving by a specified number of days or being narrowed, and why. No one learned of the change second-hand.

Result. The dashboard was restored, the demo went ahead with a narrower scope, and the project slipped by the days I had announced. The root cause was a defect in our code, and the customer had to tell us because nothing alerted on the nightly job failing, so afterwards I fixed the defect and added monitoring.

What I would do differently. Keep a standing buffer in project plans for operational escalations, and agree up front who decides when an escalation may displace project work, instead of improvising under pressure.

The same method in other situations. When a model training job fails right before a demo, the same method applies: decide whether the demo can run on the last good model or a smaller scope. When several high-priority ad-hoc asks stack on routine maintenance, rank them out loud, tell each requester a date, and defer maintenance with a written reason.

Direct answer. I would keep one shared product core, set an explicit rule for what may vary by market, and decide local requests with a weighted score plus a compliance gate. When two regions' research conflicts, I would first test whether the difference is a real difference in need or only in how it is expressed, and prefer one configurable feature over two separate ones.

1. What stays consistent. Anything that makes the product one product: data model, core workflows, identity and billing, design system (the shared library of components and patterns), security, and analytics definitions. Local teams may vary content, language, payment methods, defaults and onboarding, and may add features inside an agreed extension point (a defined place where a market can customise without changing the core).

2. Deciding which local requests to build. Two steps.

• Gate (not weighted): legal or regulatory requirements ship regardless of score. This is the compliance gate: a pass/fail check that sits outside the scoring. Example: a data-residency requirement, where a national, sector or customer-contract rule says certain customers' data must be stored on servers in their own country or region (GDPR itself regulates transfers out of the EU with conditions rather than banning them, so the duty comes from the specific rule), so a market subject to such a rule cannot wait on a revenue ranking.
• Weighted scoring (each criterion rated 1 to 5, weights agreed in advance): revenue 40%, growth 20%, compliance exposure 25%, strategic importance 15%. Illustrative market scores: EU revenue 5, growth 2, compliance 5, strategic 4 gives 0.4 x 5 + 0.2 x 2 + 0.25 x 5 + 0.15 x 4 = 4.25. LatAm: 2, 5, 2, 4 gives 2.9. APAC: 4, 4, 3, 5 gives 3.9. The 25% compliance-exposure weight in the score covers softer exposure (risk of fines, audit findings, reputational harm) and is separate from the gate, which covers hard legal duties. The score is per market, not per request: it decides how much of the local capacity each market's team gets to spend, and the requests inside each market are then ranked separately (step 3). It does not say whether a given request is good.

3. Balancing a three-region roadmap. Reserve capacity for local work, for example 70% central and 30% local. Think of engineering capacity as 100 points, so local work gets 30 points. Split those 30 points in proportion to the scores: 4.25 + 2.9 + 3.9 = 11.05, so EU about 11.5, LatAm about 7.9, APAC about 10.6 (roughly 11.5, 8 and 10.5, which sum to 30; rounding each to a whole point would give 12, 8 and 11, so keep one decimal when the total is fixed). Within each region, rank requests by impact over effort, and review the split every quarter. Illustrative first-quarter local roadmap: EU gets its data-residency storage setting and a local invoicing format; LatAm gets a local instalment-payment option; APAC gets a messaging-app sign-in and a localised onboarding flow.

4. When research in two regions conflicts. Concrete case: users in one region want a bank-transfer checkout and users in another want card saving; both are describing the same need (paying easily with a trusted method), expressed differently. Ask three questions: does the difference come from the task or from culture and habit; can one feature serve both with a setting; what is the cost of two versions (every version doubles testing and support). If it truly cannot be unified, ship the region-specific version behind a feature flag (a switch that turns the feature on only for chosen markets or users), measure it, and keep the core API identical so the variants can converge later.

Pitfall. Letting the loudest region set the roadmap, or imposing one design everywhere because consistency is cheaper for us.

Direct answer. Decide at each checkpoint from future cost and future expected value only. Money already spent is gone whichever way you choose, so it must not enter the comparison. Set the criteria before the work starts, in writing, with named decision-makers and a rule that stopping is an acceptable outcome. Sunk cost means money, time or effort already spent that cannot be recovered; the sunk cost fallacy is letting it justify more spending.

Set up front (before month one)

• Minimum success thresholds per checkpoint (for example, at month 3 and month 6): a specific measured result that must be reached to continue.
• Kill criteria: conditions that trigger a stop, such as "projected cost to finish exceeds the value ceiling" or "the key assumption is disproved".
• Cost controls: a cap on infrastructure spend per phase, released in tranches, and a named owner who must re-approve each release.
• Who decides: a sponsor plus someone independent of the team, so the team's pride is not the only voice.

At each checkpoint ask three questions

1. What have we learned that changes the odds of success?
2. What is the remaining cost, and what is the payoff if it works?
3. Is there a cheaper path to the same answer: a smaller test, a pivot (a deliberate change of direction using what you learned), or a narrower scope?

Worked example (illustrative, in $ thousands). Spent so far: 1,200 (ignored). Remaining cost to finish: 600. Payoff if it succeeds: 2,400. If the probability of success is 40%, expected value is 0.4 x 2,400 = 960, so net 960 - 600 = +360: continue. If new evidence drops it to 25%, expected value is 0.25 x 2,400 = 600, net 0: break-even, so stop or shrink to a cheaper experiment unless a pivot raises the odds. The 1,200 never appeared in either calculation.

"Encouraging but inconclusive" signals are the dangerous zone: define in advance what would make them conclusive, and cap how long you will wait.

Moving the team when stopping: announce the decision with the evidence, thank the work, name what was learned and reused, give people their next assignments the same week, and write a short retrospective. Stopping cleanly is what makes the next team willing to run an honest test.

Short answer

The missing frequency is the first thing to find, not a reason to stall. I would ask the stakeholder a few concrete questions, request a small set of data that estimates how often the case occurs, and then decide now, later or never from frequency, severity, workaround cost and build cost.

Questions to ask the stakeholder

1. Can you show me one real example, and what exactly triggered it?
2. Who hit it: which customer or segment, and how valuable are they?
3. When did it last happen, and how many times in the past quarter?
4. What happens when it occurs: blocked, wrong result, or just inconvenient?
5. Is there a workaround, and what does it cost the user?
6. What is the cost of ignoring it: revenue, a contract, a regulation?
7. Why does this need to be decided now?

Data requests

• A query or random sample of real records to estimate frequency (not a hand-picked list).
• Support tickets and sales notes mentioning it.
• Error logs or workaround usage.
• Account value for the affected customers.
• An engineering estimate for the fix.

Worked example (illustrative numbers)

Suppose a billing system handles 1.2 million invoices a month, and the edge case is invoices that mix two tax regimes. A random sample of 5,000 invoices contains 40 cases.

• Rate: 40 / 5,000 = 0.8%.
• A 95% confidence interval (the range of true rates plausibly consistent with the sample) is about 0.59% to 1.09%.
• Monthly volume: about 9,600 invoices, plausibly 7,100 to 13,000.

If customers fix each one by hand in about 5 minutes, that is 9,600 x 5 / 60 = 800 hours of customer time a month. A build estimate of 3 person-months is about 420 hours (assuming 140 hours per person-month), paid once. The interval matters here: the low end of 7,100 invoices is about 590 hours a month and the high end of 13,000 is about 1,080, so every plausible value is above 420 hours and the estimate's uncertainty does not change the decision. (The interval comes from a standard method for a proportion, the Wilson interval, applied to 40 cases in 5,000.)

Reading it: the pain customers bear every month is about twice the one-off build, so on frequency alone this belongs in "now or next cycle", not "later".

Decide with frequency and severity

In the example, the 0.8% rate puts it in the second row: next cycle. A "later" case looks different. Suppose the rate were 0.05%: 600 invoices a month, 50 hours of customer time, and the 420-hour build would take 8.4 months of that pain to repay. With a cheap workaround and no silent errors, that is "later" with a written trigger: a trigger is a concrete threshold that reopens the decision, for example more than 10 support tickets a month about it, or one affected enterprise customer asking. A workaround is the manual route customers use meanwhile, and a segment is a group of customers, such as one plan tier, that you check separately. If the same case produced a wrong total without anyone noticing, it would go to "now" at any rate.

Pitfalls: treating a vivid anecdote as a rate, sampling only complaints (which hides the silent cases), and saying "never" without recording why.