Prioritization and Trade-Off Decisions Questions

Step 1: find the real concern. An executive insisting on a pet feature (one they personally champion, whatever the data says) usually has an underlying need: a customer promise, a competitor worry, or a board narrative. I would ask in private, before any meeting with an audience, "what outcome do you want this to deliver?" Only after I know the answer do I choose which alternative below to offer first.

Step 2: bring evidence in their terms. A one-page comparison against the other ranked options. Illustrative page:

Show the opportunity cost (the value of the best thing we give up by spending the capacity here): "Building this means not building the next item, which is tied to our renewal goal." On these numbers the pet feature reaches about a tenth of the customers and moves roughly a quarter of the conversion.

Step 3: offer alternatives, not a flat no. Offer first whichever one matches the need you heard in Step 1.

• Pilot: the smallest version, about 2 weeks, with a success threshold and a kill rule agreed in advance. Example: "If at least 5% of the 200 pilot users use it weekly after two weeks, we continue; below 2%, we stop and drop it; between 2% and 5%, we run one more week with a larger group rather than argue about it." With 200 users, 5% is 10 people and 2% is 4, so the thresholds are noisy; I would also agree up front how the pilot users are chosen (not hand-picked by the sponsor) so the result cannot be rigged.
• Cheaper route: a design prototype, customer interviews, or a manual version.
• Deliver the need: if the real concern is visibility, give a demo slot or a metric review instead.
• Time-boxed slot: a capped amount of capacity (for example under 10% of the quarter) if they still want it.

Step 4: communicate. Pre-wire the decision (talk it through one-to-one with the people involved before the group meeting, so nobody is surprised), then confirm in writing with the criteria and the date we will re-review.

If they still insist: it is their call within clear limits. I would disagree and commit (state my view once, then back the decision fully), time-box it, and record the trade-off. I would not quietly slow-walk it (drag it out or underinvest to make it fail).

Sample line: "I want this to work for you. The data says it moves about a quarter of what the next item does. Can we run a two-week pilot and decide on the result?"

What flips it: the pilot data supporting the feature, or a legitimate strategic reason I did not know.

Direct answer. I would first measure whether the suspicion is true, then add safeguards that remove the sponsor's identity and the calendar from the decision, and finally track a few numbers that would show the bias shrinking.

Step 1: test the suspicion. Pull last quarter's items. Illustrative example: of 20 items shipped, 12 (60%) had a VP-level sponsor, while only 7 of the top 20 by score (35%) did. A gap that large suggests seniority, not value, may be moving work up, but with only 20 items on each side it is weak evidence: a 60% versus 35% split like this would appear by chance roughly one time in five (Fisher exact test, p about 0.2). Treat it as a reason to look at several quarters before concluding, and judge the safeguards by whether the gap narrows consistently, not by one quarter.

Step 2: name the biases and pair each with a mitigation. The first three rows (HiPPO, persistence, recency) address the problem as stated; the last two are a second layer worth adding once those are working.

Step 3: structural safeguards. Written criteria and weights agreed before any items are scored. A decision log recording who asked, the score, and any override with a reason. A named tie-breaker who is not a sponsor, and a pre-mortem on the top items (imagine it has failed a year from now and list why; do this before committing).

Step 4: how I would know it works.

• Correlation between sponsor seniority and final rank falls toward zero. To compute it, rank items by sponsor seniority and by final priority, then correlate the two rankings (rank correlation, from -1 to 1). Illustratively, with 8 items a value near 0.9 means seniority almost sets the order, while 0.2 means little relationship.
• Share of overrides, and the share of last-two-weeks requests that jump the queue, decline.
• Outcomes of low-seniority items match the outcomes of high-seniority ones.
• Quarterly survey of requesters: "do you understand why your request ranked where it did?"

Trade-off. Strict process slows urgent real escalations, so keep one visible fast lane (a separate pre-agreed route for genuine emergencies such as security or outage) with its own criteria.

Direct answer. I pulled six weeks of planned feature work out of the quarter to fund a platform fix, because the platform problem was quietly taxing every feature after it. I made the case in the team's own currency (delivery speed and incident cost), named what we gave up, and checked the result against a prediction I wrote down beforehand. The story below is a representative shape, with illustrative numbers.

Situation. Our deploy pipeline and a shared service had become fragile (platform work means the internal systems other teams build on, such as build pipelines, shared services and tooling). Last quarter 8 of our 24 releases needed a manual rollback (one in three), and 6 engineers each spent about a day per week on firefighting. The roadmap had four customer features queued: bulk CSV import, saved filters, a billing export, and a partner integration.

Making the case.

• Quantified the tax: incident hours plus the delay on every feature, converted into engineer-weeks (for example 6 engineers x 1 day per week lost = 6 days, about 1.2 engineer-weeks per week of calendar time).
• Showed the compounding effect (the loss grows because each new feature adds to the fragile base): if nothing changed, next quarter's feature capacity would shrink further, so deferring only moved the cost. At 1.2 engineer-weeks lost per calendar week, a 13-week quarter loses about 15.6 engineer-weeks (13 x 1.2) to firefighting alone, and that is the figure the six-week fix was weighed against.
• Proposed a bounded fix: 6 weeks of work with a stated exit criterion (a measurable condition agreed in advance that says the work is done and stops it: rollbacks below one release in ten, no pages for the pipeline), not an open-ended rewrite.
• Pre-wired the people who would lose: I took the sales lead through which two features slipped and offered a dated commitment for each.

What we gave up. The saved-filters feature moved to the following quarter, and the customer-requested partner integration got a "not this quarter" with a firm date. I said that out loud rather than hiding it.

Outcome vs expectation. I had written the prediction down: rollbacks halve, firefighting time drops by about half. Rollbacks fell from 8 of 24 releases to 3 of 27 (about 11%, just short of the one-in-ten exit criterion). Firefighting fell from about 6 engineer-days a week to about 4, a third rather than a half, because a second flaky dependency surfaced. Measured against the prediction I wrote down, halving the rollback rate would have meant about 4 of 24 releases (17%), so the 11% result beat the prediction, while the firefighting target was missed. The exit criterion I had set (below one release in ten) was stricter than the prediction, which is why 11% still counted as just short. Both deferred features shipped on the dates I promised.

What I would do differently. Scope an audit of dependencies before sizing the fix, and bring the sales lead in earlier. The lesson: platform work wins arguments when it is expressed as lost feature capacity with an exit criterion, never as "tech debt is bad" (technical debt means shortcuts that make future changes slower or riskier).

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. Pick the payment revamp plus the reporting upgrade, do reporting first, and confirm the vendor date before the payment work starts. That uses 26 of 30 weeks and gives the highest risk-adjusted impact of any combination that fits.

Method. Impact is each initiative's expected business value on a common illustrative scale (higher is better). Risk is scored 1 (low) to 5 (high) for how likely the work is to slip or fail, and each risk point removes 10% of the value. Risk-adjusted impact = impact x (1 - 0.1 x risk). The 0.1 factor is an assumption, not a standard. For Payment: risk 4 means a 40% haircut, so 9 x (1 - 0.4) = 9 x 0.6 = 5.4. Value density is adjusted impact per week of work. Greedy picking means ranking by density and taking items from the top until the capacity runs out.

Ranking by density gives R, M, P, F. Greedy picking R then M uses 18 weeks and cannot fit P (38 needed) or F (34 needed), leaving 12 weeks unused. Checking every combination that fits in 30 weeks:

So P + R wins under these assumptions. Test the assumption that matters: the 0.1 per risk point is invented. Generalising to a factor k, P + R scores 13 - 40k and M + R scores 10 - 16k, so they tie at k = 0.125 (both 8.0). At k = 0.15, M + R wins (7.6 versus 7.0). The pick is therefore sensitive to how heavily risk is penalised, and the vendor's risk of 4 is the driver. That is why confirming the vendor date first matters more than the decimals. Order: R first (6 weeks, low risk, early value, and it buys time for the vendor), then P in weeks 7 to 26, leaving 4 spare weeks (about 13% of capacity) for the vendor risk. If the vendor is not ready by week 6, switch to M (12 weeks), ending at 18 weeks used with 12 spare.

What I would want to know first: what impact measures and whether it is the same unit across all four; the vendor's committed date and the contract terms; whether P can be phased; any compliance deadline (a hard date is a constraint scheduled first, not a score); and whether the 30 weeks already excludes leave and on-call.

If capacity is given as headcount. With 8 engineers for a 12-week quarter, capacity is 96 engineer-weeks, or about 77 after reserving 20% for leave and on-call. The same method applies when you must choose three initiatives from a longer list: score each, test every set of three that fits within capacity, then sequence by risk.