Prioritization and Trade-Off Decisions Questions

Situation. I was a PM for a team of 6 engineers. The sales director asked for a custom export for one key account, just as we had committed the quarter to fixing a checkout bug that was generating support tickets for three customers at renewal risk (customers whose contracts were coming up for renewal and who had said the bug might make them leave).

Task. Say no to the export for this quarter without losing the relationship.

How I prepared

• Listed the two requests in the same format. The export: 1 account, about $90K a year at stake if they left, 6 engineer-weeks. The checkout bug: 3 accounts and about 2,000 end users hitting it, about $240K a year at renewal risk, 4 engineer-weeks. (Illustrative figures.)
• Checked the capacity arithmetic so the "no" rested on numbers and not on feeling. Six engineers over a 13-week quarter is 6 x 13 = 78 engineer-weeks, and the plan already committed about 76 of them, including the 4 for the checkout fix. The 6-week export would have fit only by displacing work we had already promised, which is why the answer was "not now" and not "it is too big". (Illustrative figures.)
• Checked whether a smaller version existed: a manual export our support team could run in under an hour.
• Pre-wired it: I talked it through with her one-to-one before the planning meeting, so she heard it from me privately and not for the first time in front of others.

Action. I said, "Not this quarter, and here is why." I showed the two lists side by side, offered the manual export immediately, and committed to a decision on the full feature at next planning with her customer's data attached.

Reaction. She was frustrated at first and pushed for a date. Once she saw the renewal risk next to hers, she accepted the manual route and asked me to include her customer in the next review.

Result. The checkout fix shipped on time, the three accounts renewed, the manual export covered the customer for the quarter, and the full feature was scheduled the next quarter.

What I would do differently: involve sales earlier in the quarter's priority list so the no was not a surprise.

The same method in other situations. The same shape applies to a customization request or a dashboard request: a clear criterion, a quicker partial answer, and a firm date for the next look.

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.

Direct answer

I would not decide customer by customer. I would turn every request into a scored backlog item, build the highest-value ones that fit a fixed capacity, and resolve incompatible requests by making the behavior configurable or choosing one default for the product's direction. To avoid a custom shop, I keep one product, one codebase and clear rules for what we say no to.

Step 1: Understand what the revenue concentration means

Say three customers, A, B and C, are 30%, 23.3% and 16.7% of a $3.0M ARR (annual recurring revenue, the yearly subscription income) base, which is 70% together: A is $900k, B is $700k, C is $500k. That gives them leverage, but also a risk: serving the largest customers' special needs can crowd out the product everyone else buys. Ask what job each request is really doing, because the underlying need is often compatible even when the requested feature is not.

Step 2: Score the requests (illustrative, fixed budget of 40 person-weeks)

Item codes: the letter is the customer who asked (A, B or C) and the number is that customer's request, so A1 is customer A's first request. Score = ARR at stake x strategic-fit multiplier / effort in person-weeks. ARR at stake is the revenue of the whole customer relationship that is exposed if its request is refused. A customer can have several accounts (workspaces) under one contract, so the 'Accounts asking' column counts how many of them raised the request, while the ARR column is that customer's full contract ARR either way (customer B's contract is $700k whether one workspace or two ask), and nothing is added again. The strategic-fit multiplier says how well the request matches the product direction: 1.5 strong (a general capability many customers in our target segment would use, such as a reporting option), 1.0 neutral, 0.5 weak (logic only that customer's workflow needs).

The six built items use 4 + 3 + 6 + 5 + 10 + 8 = 36 person-weeks of the 40. C1 would need 43, so I would look for a smaller C1 slice or a plain deferral. C4 (6 pw) does not fit in the 4 remaining either.

Caveat on the score: it credits a customer's whole contract ARR to each of that customer's requests, so it is a ranking aid that favours cheap items, not expected revenue. Refusing a small tweak rarely puts all $900k at risk. A stricter version multiplies by the chance that refusing this particular request triggers churn (for example 5 to 10 percent for a minor request, 30 percent or more for a stated renewal blocker); I would apply it to the top and bottom of the ranking and check whether the built set changes before committing the 40 person-weeks. Here A1 and C1 ask for opposite defaults on the same screen. A1 scores higher, so I would ship A1 with a setting that lets C1's customers choose their behavior later, and only build that setting when its score justifies it.

Step 3: Decision rules that stop custom-shop drift

• One codebase: no per-customer forks or hard-coded customer branches.
• Build extension points (settings, APIs, integrations that let customers adapt behavior without code changes for them alone) instead of one-off features. A custom shop is a company whose roadmap is a list of individual customers' special requests.
• Requests that stay bespoke are priced as paid services, with the customer funding the work.
• Test: does at least one other account, or the segment we are targeting, also want this?

Long-standing customer versus new market

Weigh retention of existing revenue against growth potential: a retained customer's ARR is near-certain, a new market's is probabilistic, so discount the new market by its probability. If the fit score is similar, protect the base unless the new market is the company's stated strategy.

Communicate: tell each customer what will and will not be built, why, and when, without implying a bespoke roadmap.

Principle. A large contract is a real benefit, but a custom capability that conflicts with the public roadmap and changes the architecture (the underlying structure every later feature builds on) is a decision that is hard to reverse. I would not choose build, one-off, or decline on revenue alone.

Four tests

1. Reuse: would at least two or three other customers or segments want this? If yes, build it into the product, shaped generally.
2. Roadmap and architecture: does it block or distort planned work? An architectural change affects every later release, so price the maintenance as well as the build: a rough method is to estimate the share of an engineer who must keep it working each year and cost it as engineer-weeks (the worked example below does this).
3. Contract: can we sign it without date commitments on roadmap items, exclusivity (we may not sell the capability to others), or custom support forever?
4. Opportunity cost: the value of the best thing the team does not ship. Compare against the same ranked list as everything else.

Worked example (illustrative). Contract worth $1.2M a year. Build takes 2 engineers for 2 quarters (52 engineer-weeks). Assume $4,000 per engineer-week fully loaded, so the build costs 52 x $4,000 = $208,000. Upkeep: say a quarter of one engineer, 0.25 x 52 = 13 engineer-weeks a year = $52,000. First-year cost is about $260,000, so the contract looks very profitable in isolation (about $4.60 of revenue per $1 of cost). That is the trap: the real cost is what the same 52 engineer-weeks would otherwise ship. Suppose two roadmap items, which would retain existing customers who might otherwise leave (retain means keep revenue we already have) and add new sales, are worth $1.8M a year after discounting for confidence. Per engineer-week that is $1.2M / 52 = about $23,100 for the contract against $1.8M / 52 = about $34,600 for the roadmap. The roadmap wins, so decline or narrow the request. Two caveats keep this honest: counting the 13 upkeep weeks too (65 engineer-weeks, $1.2M / 65 = about $18,500) only widens the gap, and I would apply the same confidence discount to the contract's $1.2M as to the roadmap's figure (a signed contract needs less discount than a forecast), which also cannot reverse the order here. If the roadmap items were worth $0.6M instead, the contract wins and I would build it.

My call. Counter with a narrowed, paid option: build the reusable core behind a feature flag (a switch that turns the capability on only for chosen customers) with the customer as a design partner (they co-define requirements and fund part, get early access, accept no roadmap-date promise). If it only serves them, offer a one-off as a clearly separated service with its own price and an upstreaming policy (a rule that the work is either folded into the product later or retired by a set date). Decline when the change would damage the architecture or commit us to supporting a fork (a private copy of the code that drifts away from the product).

Other request sizes. A 3-week custom report (3 engineer-weeks, about $12,000 on the numbers above): do it as a one-off if it uses existing data and has no ongoing owner, and ideally charge for it. Sales vs foundational work: put the sales request on the same scoring as foundations, since they are both just options.

Telling sales and the customer. Give the customer a date and what they get; tell sales exactly what we will not promise.

What flips it: the customer being a strategic reference (a well-known account whose endorsement helps us win a segment we plan to enter).

Direct answer

I would fix the support bug this month, unless the sales deal is provably gated on this month's date. Both requests are loud, so I turn each into the same unit, expected revenue protected per engineering-week, and let the numbers plus one named decision-maker settle it. Whichever side loses gets a dated plan, not a "maybe later".

Step 1: Turn each claim into something testable

• Sales: Is the feature the stated blocker, in writing, from the buyer? What is the ACV (annual contract value: the average yearly value of the contract, normally excluding one-time fees; for a one-year deal with no setup fees it equals the first-year deal size) and the expected signing date? What is the win chance with the feature versus without it?
• Support: How many accounts hit the bug, and what is their ARR (annual recurring revenue, what customers pay per year)? NPS (Net Promoter Score, a survey of how likely customers are to recommend you) falling is a symptom, so check whether affected accounts really churn more than similar unaffected ones. Correlation is not yet causation.
• Engineering: A real estimate for each, and whether either can be sliced smaller.

Step 2: Compare on one basis (illustrative numbers)

The deal is a one-off and the bug cost keeps growing each month it stays open. Both inputs are rough, so I would check that the ranking survives a halving of either estimate before I commit.

Step 3: The call and who is involved

Fix the bug first (about 1.5 weeks). Then give sales a concrete path: a scoped slice of the feature with a committed date next month, a workaround or demo for the prospect now, and an executive on the buyer call. A single owner (the head of product) makes the call and tells both sides the same day with the reasoning. Involve the sales lead and account executive (deadline evidence), the support lead and an analyst (affected accounts), the engineering lead (estimates and slicing), and customer success (who owns the affected accounts).

What flips it

If the buyer confirms in writing that the feature is the only blocker and signs this month, and affected accounts have a workaround, build the feature. Pitfalls: letting the loudest voice win, comparing dollars to NPS points directly, and silently dropping the losing request.