Prioritization and Trade-Off Decisions Questions

Direct answer

I would not decide "rewrite or not" as a yes/no. I would price the rewrite honestly, compare it with cheaper ways to capture most of the benefit, and recommend the smallest option that fixes the real pain. A nine-month roadmap block is only justified if the payback (how long the savings take to repay the effort spent) and the risk survive scrutiny.

Step 1: Make the case in numbers (illustrative)

Suppose the module's drag (maintenance, incidents, slowed features) consumes the equivalent of 2.5 people's full time every year on a 10-person team. The rewrite uses 6 people for 9 months: 6 x 9 = 54 person-months. The saving is 2.5 x 12 = 30 person-months per year, so payback is 54 / 30 = 1.8 years after it finishes, about 30.6 months from the start (9 + 21.6). If the rewrite overruns by half (13.5 months, 81 person-months), payback after finishing stretches to 81 / 30 = 2.7 years. Rewrites tend to overrun, so ask what happens to the case if it does.

I would also ask: what is the problem we are paying for (incidents, slow features, cost, hiring), what is the evidence, and what does the roadmap cost in revenue and customer commitments?

Step 2: Alternatives on the table

Step 3: Decide and handle resistance

Recommend the incremental path with a decision gate (a scheduled checkpoint where you decide to continue, shrink or stop): after the first milestone (say 8 weeks), compare real progress with estimate. Resistant stakeholders get a dated commitment on their key roadmap items and a clear picture of what the module costs them today (for example, features that take longer than they should).

Applying the same method to a BI platform migration that pauses new reporting

The same method applies. Quantify the pause (illustratively, 40 report requests a quarter; a freeze exception list for regulatory or executive reports takes 6 of them, so 34 wait). Run old and new platforms side by side (a parallel run) on a pilot, for example 2 of 10 teams for 4 weeks, comparing numbers report by report. Publish the cut-over date (the day the old platform is switched off).

Pitfalls: sunk cost (reasoning from what has already been spent), rewrites justified by taste, and no exit criteria.

Direct answer. Customer demand tells you a problem is real; strategy tells you whether you are the right company to solve it and whether it is worth the opportunity cost (the value of the best alternative you give up by spending the same capacity). I would ship a request only if it passes a fit test, sequence the requests that pass by value per effort, and tell the rest "not for us" with reasons and an alternative.

1. Criteria for whether anything ships. Run each request through gates before any scoring:

• Fit with the stated strategy: does it serve our target customer and the bets we chose? (Strategy here means the few choices about where we will win, and what we will not do.)
• Who is asking: target customers, or loud customers outside the segment? Count accounts and revenue in the target segment, not total mentions.
• Does it dilute the product: will it add permanent surface area (more screens, settings, support load, bugs and docs to maintain forever) for a narrow group, so the product becomes harder to explain and to use for everyone else?
• Is there a strategy-compatible form: the underlying need may be met with an integration, an export, or a partner.
  A request that fails the first gate stays out regardless of volume. Failing the second or third often becomes a smaller or partner-based version.

2. Sequencing the ones that do ship. Score the requests that pass with RICE, which stands for Reach x Impact x Confidence / Effort: Reach is how many customers it touches per quarter, Impact is the size of effect on each (0.25 minimal, 0.5 low, 1 medium, 2 high, 3 massive), Confidence is how sure you are of those estimates (100%, 80% or 50%), and Effort is person-months. Then add a strategic-fit multiplier: a number leadership fixes before scoring, for example 1.0 for a request that serves a chosen bet and 0.5 for one that fits only loosely, so no one tunes it to favour a pet request.

Worked example (illustrative numbers):

• Request P, core bet: Reach 800, Impact 1, Confidence 100%, Effort 20 person-months gives 800 x 1 x 1.0 / 20 = 40. Multiplier 1.0 leaves 40.
• Request Q, loose fit: Reach 2,200, Impact 1, Confidence 100%, Effort 40 person-months gives 2,200 x 1 x 1.0 / 40 = 55. Multiplier 0.5 gives 27.5.
  Q has the higher raw score but P ships first.

3. Explaining the ones that do not.

• Say no with the reason tied to the strategy, not to effort: "We are building for X; this serves Y."
• Name what the customer can do instead (workaround, partner, API).
• Be specific about revisit conditions ("if the segment grows to N accounts, we will look again"), and log it publicly so the request is not lost.
• Brief the account owner first so sales is not surprised.

What would change my call. Evidence the strategy itself is wrong. If demand outside the target keeps showing up and is large, that is a signal to revisit the strategy, a deliberate decision made by leadership, not feature by feature.

Pitfall. Saying yes to the biggest customer's request and calling it strategy.

Direct answer. Opportunity cost is the value of the best option you did not choose. Make it visible by writing it down at the moment of the decision, in the same unit as the benefit of what you chose, and by stating the cost of delaying each option per week or per quarter. Choosing the SDK (software development kit, a package that helps partners integrate) over API stability was not necessarily wrong; the failure is that nobody put a price on the stability work being delayed.

How to quantify (same basis for both options)
Compare cost of delay (the value lost for each period an option waits) per 13-week quarter. All numbers are illustrative.

• SDK delay: expected new-partner value of $4,000 per week, so $4,000 x 13 = $52,000 per quarter.
• API stability delay: about 6 breaking-change escalations a month, each costing roughly 10 engineering hours, so 60 hours a month, 180 hours a quarter. At an assumed $100 per hour that is $18,000, plus the harder-to-price risk of partners leaving.

Treat the SDK figure as margin rather than revenue so the two lines are comparable money, and the stability line as engineering cost the business would otherwise avoid. On these numbers the SDK has the higher direct cost of delay, so the choice is defensible, but the table also shows the stability gap is not free. A quarter later, rising escalations are the signal that the unpriced risk (partner churn) has arrived. Concretely, the baseline is 6 escalations a month, 180 hours a quarter, $18,000. At 8 a month it is 8 x 10 x 3 = 240 hours, $24,000, a third higher. On direct hours alone the stability work would only overtake the SDK's $52,000 at about 17 escalations a month (52,000 / (10 hours x 3 months x $100) = 17.3), so a trigger of 8 is not derived from these numbers. It is a deliberate judgment: a rise from 6 to 8 suggests partners are hurting more than the direct hours show, and the unpriced churn risk is expected to make up the difference, so 8 is the point to re-open the decision, not to reverse it automatically.

Making it visible in the decision itself

• A one-line "we are not doing X, which costs about Y per quarter" in the decision note.
• Name the trigger that reverses the choice, such as "if escalations reach 8 per month, re-open the decision and compare the two delay costs again; move stability first only if its cost of delay, including the churn risk, now exceeds the SDK's".
• Revisit at a fixed date (one quarter).

Platform versioning program example. A versioning program lowers future rework. Quantify it as avoided cost: if each breaking change currently causes 10 hours of partner support, and versioning removes most of them, the saving is the 180 hours a quarter above times the share avoided. Say versioning avoids 70% of them (an assumption to confirm): 180 x 0.7 = 126 hours, or $12,600 a quarter at $100 per hour. Delaying it by a quarter means paying those 126 hours again.

One-way versus two-way doors (a framing from Jeff Bezos's 2015 Amazon shareholder letter): a one-way door is hard to reverse, a two-way door is easy to reverse. A public SDK is closer to one-way (partners depend on it), so it deserves more analysis; internal sequencing changes are two-way, so decide fast.

Direct answer

I would not put everything in one score. The model has three parts: a gate (a pass-through check) for work that is non-negotiable (regulatory deadlines), a scored lane (a separate queue with its own ranking) for revenue features compared in a common unit, and a reserved capacity slice for platform health that is defended by its own evidence. Then I test whether the ranking survives small changes to the inputs and the split.

1. Inputs

• For each item: expected value (the payoff in money per month where possible, such as revenue, risk avoided or cost saved), a deadline if one exists, effort in person-weeks (one person working full-time for a week), confidence (my probability the estimate holds, from 0 to 1), dependencies, and affected users or partners.
• Regulatory work has a date and a penalty, so it goes through the gate first: it gets the capacity it needs to meet the date and is not traded against revenue.
• Revenue features are scored by expected monthly value times confidence, divided by effort. Worked example (illustrative):

Ranking: C, A, B. The score is expected monthly dollars (in $k) per person-week of effort. The alternative is cost of delay divided by duration: cost of delay is the value lost for each week an item is not live (for A, about $30k a month is roughly $7k a week) and you divide by the weeks it takes to build.

• Platform health (reliability, tech debt meaning shortcuts that make future changes slower, and developer productivity) is hard to price, so I reserve a share of capacity for it. Example: 10 engineers, 2 for the regulatory deadline, 4 for revenue, 3 for platform health, 1 for unplanned work (illustrative). That is 20%, 40%, 30% and 10%, a total of 100%. Within the platform lane, rank by incident cost, developer-hours lost, or risk.

2. Criteria that cannot be compared directly

Convert to a common unit when you can (money per month, hours per week). When you cannot, do not force a fake exchange rate: split capacity into lanes, rank within each lane, and let leadership adjust the split deliberately. A rough bucket (low, medium, high) with written anchors is better than invented precision.

3. Check that small changes do not flip the ranking

Move each input by a small amount, re-rank, and record which items change position. Two kinds of input to move:

• A confidence or value in the revenue lane. Raise B's confidence from 0.5 to 0.6: 50 x 0.6 / 5 = 6.0, which ties A. At 0.7 it is 7.0 and B passes A. So A versus B is fragile, a tie to settle by judgement, while C stays first in every case: the firm part of the plan.
• A lane share. Move the revenue lane up by 10 percentage points, from 40% to 50%, and take the 10 points from the other lanes in proportion to their size ("rescale the rest"): the other three lanes (20, 30, 10, total 60) each shrink by 50/60, to about 16.7%, 25% and 8.3%. Then check which items still fit.
  Report the stable top set rather than a single ordered list.

4. Related concerns

Three concerns apply to the model as a whole:

• Interdependencies: if A unlocks B, score them as a bundle or sequence them.
• Double counting: one benefit (say fewer support tickets) appearing in two items' scores must be counted once.
• Re-evaluation cadence: re-rank every quarter and when a deadline or incident changes inputs.

Three notes for specific situations:

• Fairness across regions or products: check the result for systematic neglect and set a minimum slice if needed.
• Public-API breaking changes: add a risk input for customer migration cost and require a deprecation window (a published period during which the old behaviour keeps working) and communication plan.
• Operations versus product headcount: the split above is the explicit decision, revisited quarterly.

Trade-off: more lanes means more governance. Keep to three lanes and one page of rules.

Direct answer

When 80% of the backlog is "must-have", the label has stopped carrying information. I would replace the label with a test, a capacity limit and an explicit "not this time" list, and run the negotiation as a trade-off with stakeholders in the room, not as a cut made behind their backs.

MoSCoW terms: Must have (the release fails or is not viable without it), Should have (important but not vital: it may be painful to leave out, but the release is still viable), Could have (desirable), Won't have (agreed as not in this timeframe). The method is attributed to Dai Clegg and became widely used through DSDM (Dynamic Systems Development Method, an agile project-delivery framework).

Illustrative numbers. 50 backlog items, 40 labelled Must (80%), capacity for 25 (about half).

Steps

1. Start from capacity, not wishes. Show the budget: 25 items' worth. Everything labelled Must is competing for it.
2. Apply a sharper test. For each Must, ask "what specifically breaks, for whom, if we ship without it?" and "what is the cost if it arrives one release later?" Require evidence (customer commitment, legal date, measured impact). Three illustrative requests:

• "Fix tax rounding on invoices before the 1 January filing date": invoices would be wrong for every customer in a legal period. Passes, stays Must.
• "Export the audit log, as the Acme contract requires by Q3": a named customer and a contract clause. Passes.
• "Custom colour themes for the dashboard": nothing breaks, nobody is blocked, and one release later costs nothing. Fails, moves to Could.
  Say 40 become 22 that pass.

3. Cap Musts. DSDM's published guideline is no more than about 60% of effort on Must Haves, with roughly 20% of effort held as Could Have contingency that can be dropped if work overruns. For 25 items that would be 15 Musts. As a team rule I would use a looser cap of about two-thirds of capacity, here 16 items, and say so openly, so there is room for Shoulds and slack for surprises.
4. Negotiate the gap. 22 against a cap of 16 means 6 must move. Offer options: ship a thinner slice of an item, move it to a named later release, or swap it with another stakeholder's item. Use a limited budget (each stakeholder gets points to spend) so the trade-off is visible.
5. Make Won't explicit. Publish the list of items not in this release with the reason and when they will be reconsidered. People accept "not now, here is when" far better than silence.
6. Result: 16 Must plus 8 Should fit within 25, leaving 1 slot of slack.

Keeping stakeholders

• Meet each senior stakeholder before the group session so nobody is surprised.
• Frame it as "here is what your priorities cost" and let them choose the trade.
• Give a clear path to reopen: a fixed re-planning date and an evidence bar.
• Keep a single decision owner who announces the final list and the reasoning.

Pitfalls

• Counting items instead of effort (a 10-day item is not one of 25 equal slots).
• Letting Should become the new Must.
• Cutting quietly and letting the loudest stakeholder find out at release.