Prioritization and Trade-Off Decisions Questions

Direct answer. When the expected return is tied, decide on the things the return number leaves out: deadline, reversibility, what we learn, and strategic fit. Then split the loser's goal if possible and tell them plainly why.

Check the tie first. Request A: $600k at stake, 50% chance it works, so $300k expected. Request B: $400k at stake, 75% chance, also $300k. Same return, so these tie-breakers decide:

1. Cost of delay (value lost per week of waiting): does one have a date that expires, such as a renewal in 8 weeks, while the other can wait a quarter? The expiring one goes first.
2. Reversibility: prefer the choice that is cheaper to undo or that leaves the other still possible next quarter.
3. Learning and risk: prefer the one that tests a big assumption cheaply, or reduces a risk that blocks other work.
4. Strategic fit: the one aligned to this quarter's stated goal.

The question does not say which request, if either, has a date, so that is the first thing to ask the two teams. Suppose B turns out to have the expiring renewal and A can wait a quarter: then B wins. If neither has a date, fall through to reversibility, learning and strategic fit in that order. Quick-but-risky versus bigger-but-larger-payoff is the same logic: a 4-week option worth $150k at 90% gives $135k, about $34k per engineer-week; a 12-week option worth $500k at 40% gives $200k, about $17k per week. The big bet wins only if the extra value is strategic or the engineer's best alternative use of the other 8 weeks of a 12-week quarter returns less than the $65k gap ($200k minus $135k), about $8k per week; with the quick option at about $34k per week, almost any further good use of that time beats the big bet.

The team that loses. Tell them in person before it is announced, show the criteria (not just the verdict), offer what you can: a smaller scoped piece, a workaround, a guaranteed place at the start of next quarter, or help to make their case for extra capacity. Never leave them guessing.

Direct answer. Treat the backlog as a funnel with six weekly stages. Merge duplicates first, clarify only what survives, give every item a named owner, score with a light rubric, then match the top of the list to real analyst capacity. Everything not funded is published as "not this quarter" with a reason.

Week 1: inventory and de-duplicate. Export all 600 into one sheet. Normalize titles (lowercase them, strip prefixes like "URGENT:" and expand abbreviations, so "Rgn churn rpt" and "Regional churn report" look the same), then group by dataset or dashboard touched and by requester. Merge exact duplicates mechanically and near-duplicates after a quick read. Example of a near-duplicate pair: Sales asks for "weekly churn by region" and Finance asks for "regional churn report, weekly". Same data, same grain, same cadence, so they become one item and both requesters stay listed as stakeholders. Budget: 600 requests at about 3 minutes each is 30 hours of first-pass reading, so split it between two people. Also tag requests that an existing dashboard already answers and close them with a link.

Week 2: clarify. Send each requester a five-field template: the decision this supports, the deadline and why, who uses the result, how often, and the current workaround. Send the template on day one of Week 2, remind non-responders midweek, and close anything still unanswered at the end of that week with "reopen if still needed", so Week 3 starts with only surviving items (a longer wait would push owner assignment and scoring into the weeks reserved for staffing and review). Silence is information about priority.

Week 3: assign owners. Every surviving item gets a requesting business owner (the business-side person who confirms the value and will use the result) and a delivery owner on the data team (the analyst or lead who estimates and builds it). Items nobody will own are closed.

Week 4: score. Use a lightweight RICE-style rubric. RICE is a scoring method: score = Reach x Impact x Confidence / Effort. Map your factors onto it: Reach is people affected, Impact is the value of the decision it supports (0.25 minimal, 0.5 low, 1 medium, 2 high, 3 massive), Confidence is how sure you are of the data and the estimate (100%, 80% or 50%), and Effort is analyst-weeks (one analyst working one full week). A hard deadline or legal need is not scored; it goes straight into a must-do list. Keep scoring to about 10 minutes per item.

Illustrative scoring of three surviving requests:

The dashboard is funded first. The forecast model has high impact but low confidence and high effort, so it goes to the deferred list with a note on what would raise its score.

Week 5: staff. Capacity is the constraint. Illustrative: 4 analysts, 13 weeks, 60% of time on planned projects is 4 x 13 x 0.6 = 31.2 analyst-weeks. Fill the ranked list until that runs out, keeping a reserve (for example 20%) for urgent work. Applying it: 31.2 x 0.8 = 24.96, so plan for about 25 analyst-weeks of ranked work and hold roughly 6 in reserve.

Week 6: review and publish. Present the funded list, the deferred list with reasons, and the closed list to stakeholders, then lock it for the quarter.

Pitfalls. Do not clarify 600 items before de-duplicating; do not score items without owners; do not let the funded list exceed measured capacity.

Short answer

I would estimate each idea in net hours saved per month after upkeep, work out its payback time, put it in the same unit as feature work (value per hour of build effort), and require that someone can name what the saved time will be used for. That keeps "it would save time" from outranking work that moves customers or revenue.

Step 1: Estimate the payoff

For each idea: runs per month x minutes saved per run / 60 = gross hours saved. Subtract monthly upkeep (fixing the script when systems change). Divide the build hours by the net hours for payback in months (how long until the time saved repays the build time).

Illustrative inputs: a loaded cost (salary plus overhead such as benefits and equipment, per hour of work) of $75 an hour and 140 build hours per person-month.

Year-one value per build hour = net hours x 12 x $75 / build hours (D: 90 x 12 x 75 / 400 = $202.50).

Step 2: Compare against non-automation work

Suppose a customer-facing feature needs 420 build hours and is expected to retain $20,000 a month after discounting for confidence: $240,000 / 420 = about $571 per build hour. Retained revenue and saved labour are both dollars per build hour, but revenue is not profit, so convert it first: at an illustrative 70% margin, $571 becomes about $400 per build hour. It still beats even the best automation (D at $202.50), so it goes first. D still ranks second, and B should be dropped.

Step 3: Guard against "it would save time"

• Use net hours after upkeep, not gross.
• Saved time must turn into something: five hours a month spread across twelve people is not recoverable, so it is worth nothing in practice.
• Set a payback limit (for example, within six months), and allow very small automations (a day or two) without a debate.
• Count wait time, not just effort: C looks weak in hours, but if engineers sit blocked waiting for environments, its real value is the delay removed.

Cognitive load and errors

Manual steps also cost mistakes and interruptions. Value them: errors avoided x cost to fix each, or on-call pages removed (as in the example below). Do not guess a number; use the count of past incidents. Example: if manual environment setup caused 6 misconfiguration incidents last year at about 4 engineer-hours each to fix, that is 24 hours, or 24 x $75 = $1,800 a year, to add to the automation's value.

Customer-support sequencing

Sequencing for the highest-value idea, D (support triage): automate the highest-volume, most repetitive, lowest-risk ticket categories first (triage and tagging), then suggested replies, and only then automatic resolution, with a human handoff for anything risky.

Direct answer. Keep the same scoring structure but change what each input means: measure impact for platform work as time or risk avoided for the engineers (and downstream customers) who depend on it, and for multi-tenant products weight reach by value (revenue or contract size), not by headcount (the number of people or accounts). Then compare everything in a shared currency, so internal items are not penalized for having fewer, more concentrated users.

RICE adapted. RICE = Reach x Impact x Confidence / Effort (Intercom's framework: Reach as people per time period, Impact on a 0.25 to 3 scale, Confidence as a percentage, Effort in person-months).

Why the raw score misleads (illustrative). Impact scale: 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal. A CI pipeline upgrade: Reach 120 engineers, Impact 1, Confidence 80%, Effort 1.5 person-months gives 120 x 1 x 0.8 / 1.5 = 64. A customer feature: Reach 4,000 users, Impact 0.5, Confidence 80%, Effort 3 gives 4,000 x 0.5 x 0.8 / 3 = 533. Raw RICE says the feature wins 8 to 1 only because it counts heads. Put both in dollars to compare fairly: at an assumed $12k per person-month, the CI work returns 7.5 person-months = $90k for a cost of 1.5 x 12 = $18k (5x). The feature, if 3% of its 4,000 users convert at $300 a year, brings 4,000 x 0.03 x 300 = $36k for a cost of 3 x 12 = $36k (1x). Mind the periods: the CI figure is per quarter and the feature figure is per year, so put them on one basis before comparing. Annualised, the CI work returns about 4 x $90k = $360k a year (20x its $18k cost, if the saving holds in all four quarters) against the feature's $36k a year (1x). The order is the same and the gap is larger. The RICE Reach figures need one period too (for example engineers per quarter and users per quarter) in the same table.

Platform and internal tooling

• Reach: the engineers using it, plus the customer-facing teams whose output it speeds up.
• Impact: hours of engineering time saved, incidents avoided, or lead time cut, converted to dollars or to capacity returned.
• Worked example (illustrative): a faster continuous-integration pipeline (CI, the automated build and test system) used by 120 engineers saves 10 minutes per day for 60 working days a quarter: 120 x 10 x 60 / 60 = 1,200 hours. At 160 working hours per person-month, that is 7.5 person-months returned each quarter. If it costs 1.5 person-months, it returns 7.5 / 1.5 = 5 times its cost every quarter, a result a customer-facing feature can be compared against directly.

Multi-tenant products where impact varies by customer. (Multi-tenant means many customer organizations share one product; annual contract value is what a customer pays per year.) Weight reach by value. Three enterprise accounts at $200,000 annual contract value are 3 x $200,000 = $600,000, exactly equal to 300 small accounts at $2,000 (300 x $2,000 = $600,000), though raw headcount says the second group is 100 times larger. Score both views and see which ranking you can defend, then add retention risk (an account threatening to leave) as a separate flag.

Data-engineering example: refactor vs new pipeline. Value the refactor by failures and on-call hours avoided, stale-data days for downstream dashboards, and risk of a major outage; value the new pipeline by the decisions or revenue it enables. A refactor that prevents 6 failures a quarter at 5 hours each saves only 30 hours, so it loses on time saved alone; it wins if those failures corrupt data the business relies on. Say which basis you used.

Guardrails. Reserve a fixed share of capacity (e.g. 20%) for platform and reliability so they never have to win a head-to-head scoring contest every quarter.

Pitfalls. Letting reach = 120 engineers lose to reach = 4,000 users without translating; counting the same hours saved twice; giving platform work a free pass because it feels responsible.

Direct answer

I would build one front door for requests, triage them weekly against a short scoring rubric, split capacity into fixed lanes (urgent, ranked requests, infrastructure), and publish the queue so everyone can see where their request sits and why. Stakeholders accept outcomes they can inspect, so the visible queue, the scores, and a quarterly review with representatives from sales, marketing, product and finance matter as much as the ranking itself.

Intake

• One form, with required fields: the decision this supports, who will use it, the deadline and what happens if it misses, and who sponsors it.
• Deduplicate and cluster. Of 50 open requests, many ask the same underlying question. Merge them and, where possible, answer with a self-serve dashboard instead of repeated one-off pulls.
• Weekly triage of 30 minutes by the team lead and an analyst.

Ranking rubric

Score each request 1 to 5 on four criteria. Weights are illustrative and are agreed with the stakeholder group in advance: impact 40%, strategic fit 25%, risk or urgency of not doing it 20%, effort 15% (5 means cheap).

For example, the dashboard: 0.4 x 5 + 0.25 x 4 + 0.2 x 4 + 0.15 x 4 = 2.0 + 1.0 + 0.8 + 0.6 = 4.4.

Capacity model

Four analysts across a two-week cycle give 4 x 10 = 40 analyst-days. I would divide it as 8 days (20%) for urgent asks, 8 days (20%) for infrastructure such as pipelines and data models, and 24 days for the ranked queue: 8 + 8 + 24 = 40. The 20% infrastructure lane protects the team from drowning in ad hoc work and never fixing the foundations.

Infrastructure items are scored on the same rubric so their value is visible, but they compete only against each other for the 8-day infrastructure lane. The 3.9 pipeline rebuild therefore does not displace the 4.4 dashboard or the 3.75 churn refresh, which draw on the 24-day ranked lane. Tier 0 and Tier 1 requests (below) both draw on the 8-day urgent lane.

Service tiers for urgent asks

• Tier 0: executive, regulatory or outage-related, same day, must be sponsored by a director.
• Tier 1: small pulls under half a day, answered within three business days.
• Tier 2: everything else, goes through the ranked queue.

Tier 0 requests that arrive too often get reviewed, because a constant stream means the underlying report needs building.

Making the outcome visible and accepted

1. A shared board showing rank, score, owner, status and estimated start for every request.
2. A short written reason for anything below the cut line, plus what would raise it.
3. A quarterly prioritization review with a representative from sales, marketing, product and finance, who agree the weights and break ties.
4. Aging rule: any request older than 90 days is re-confirmed or closed.

For data engineering or data science requests, effort must also count data availability and pipeline changes, and risk should include model or data quality consequences.

Pitfalls

• Scoring without capacity: a ranked list is useless if it exceeds the 24 days.
• Letting urgent swallow the team: an unlimited urgent lane kills the ranked queue.
• Opaque triage: hidden decisions are reopened as escalations.