Prioritization and Trade-Off Decisions Questions

Situation. Sales wanted single sign-on (SSO, letting a company's employees log in with their corporate identity) for enterprise deals; support wanted a self-serve password and account recovery flow. Both leaders were certain, and I had one team for the quarter.

What I weighed

• Reach: recovery touched most users; SSO touched the few large accounts.
• Revenue: 5 open enterprise deals asked for SSO; recovery drove a large share of support tickets.
• Cost: SSO was roughly twice the effort.
• Confidence: I checked deal notes and ticket data rather than relying on the anecdotes of each leader.

How I decided. I agreed the goal with both before looking at features: "reduce time to revenue and cost to serve". Then I scored both options with a weighted table (each criterion gets a weight for how much it matters, each option a 1 to 5 score per criterion, and the weighted scores are added up), shared it, and let each leader challenge an input.

SSO: 0.45 x 5 + 0.15 x 2 + 0.20 x 2 + 0.20 x 4 = 3.75. Recovery: 0.45 x 2 + 0.15 x 5 + 0.20 x 4 + 0.20 x 4 = 3.25. The support lead challenged the weights: if reach is 25% and revenue 35%, Recovery edges ahead, 3.55 to 3.45. So the decision depended on revenue carrying the most weight, which followed directly from the goal we had both agreed to. I kept the weights and added a stopgap (a cheap temporary measure that relieves the pain until the full fix) to answer her case. The sequence: the stopgap came first, in weeks 1 and 2 (a clearer reset email and a help article), then SSO for the rest of the quarter.

The one who lost. I called the support lead before announcing. I gave her the data, the stopgap, and a firm date for the full flow, and asked her team to review the stopgap.

Result. Two of the five enterprise deals closed on schedule (the other three were still in negotiation at quarter end), ticket volume stayed flat, and the support lead agreed to the next planning round because the criteria were visible.

The same method in other situations. If the disagreement is with a PM about scope, use the same shared criteria; if the tension is AI project deadline vs quality vs cost, say which of the three was fixed and which flexed. Example: the demo date was fixed at 8 weeks and the team was fixed at 4 engineers, so scope flexed: we shipped the model for 3 of 5 document types.

What I would do differently: bring both leaders into the scoring session earlier.

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. 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. I would tell a story where a plausible, scored decision was wrong because one input was assumed rather than measured, then show how I found out and what changed in my process. (The numbers below are illustrative, to show the shape of a good story.)

Situation and reasoning. I was the product manager (PM) for a collaboration product. I proposed a "saved views" feature. I ranked it with RICE (Reach x Impact x Confidence / Effort, scored per quarter, with Effort in person-months). My inputs came from a survey and three loud customer calls:

Assumed: Reach 4,000 users/quarter x Impact 1 x Confidence 80% / Effort 2 person-months
RICE = 4,000 x 1 x 0.8 / 2 = 1,600

That put it first on the list. The weak point was Reach: it came from what people said they wanted, not from what people did.

How I found out. Before building I had written a hypothesis with a threshold: "at least 25% of weekly active users will open a saved view within 4 weeks, or we reconsider." After launch, instrumentation showed adoption far below that bar and most opens came from the same few accounts who had asked for it. Re-scoring with the observed Reach of about 1,000 users/quarter gives 1,000 x 1 x 0.8 / 2 = 400, a quarter of the original (1,600 / 400 = 4). Interviews showed the real pain was finding old documents, which search already half-solved.

What I did.

• Told my manager and the sponsoring customers within the week, with the data, rather than defending it.
• Stopped further investment, kept the feature behind a small footprint, and redirected the next sprint to improving search.
• Wrote the post-mortem: the miss was treating stated demand as Reach.

What changed afterwards. Reach must now come from usage data or a fake-door test (a button that measures clicks before the feature exists). Every roadmap item carries a written success threshold and a review date. Confidence drops to 50% when the only evidence is requests.

Pitfall. A weak story blames users or timing. A strong one owns the specific reasoning error and shows a changed habit.

Direct answer. Rank: (1) the accessibility fix, (2) the experiment, (3) the banner redesign. Do the first two inside the two weeks. The redesign is not built this sprint; the experiment tests its cheapest slice, a new banner headline (a copy variant), against today's banner. The accessibility issue is critical and is a must-do (work that happens regardless of its score, because users may be unable to use the product and legal exposure grows each week). The experiment ranks above the redesign because it tells you whether a redesign is worth building.

What the experiment is (illustrative). An A/B test: half of visitors see the current banner, half see the new headline, and you count signups per 1,000 visitors for a week. Say 30 vs 36 signups per 1,000 is a 20% lift (relative increase). On 200,000 visitors a month, 6 extra per 1,000 is 6 x 200 = 1,200 extra signups a month, so if a full redesign delivered the same lift, each month of delay would cost about 1,200 signups (the headline test is only a proxy for the redesign, so the real figure could be lower or higher). If the result shows no lift, the case for the 8-day redesign weakens a lot, but a headline test cannot prove a redesign useless, so ask what else the redesign changes before dropping it.

Reasoning

• Cost of delay (what waiting costs per week) is asymmetric: the accessibility issue harms people now and carries legal risk, while the banner's lift is a modest, unproven gain.
• Effort (illustrative): accessibility 4 days, experiment 6 days, redesign 8 days. 4 + 6 = 10 working days, so the first two fill two weeks and the redesign does not fit.
• Learning value: a simple test of banner copy gives evidence on whether the full redesign pays off.

Related cases

• Checkout form-field fix vs marketing campaign page: fix the checkout field first. It sits where people already intend to buy, so a small friction cut is a direct conversion gain, and it is usually cheap.
• Ten small experiments, one designer and one engineer: the bottleneck sets the plan. Rank by expected learning per day of the scarcer person, run the three or four best, batch design-only or copy-only tests that need no engineer, and drop the rest for now.

Telling the people not picked. Say it directly and early, with the reason in their terms: "Accessibility is a must-do, the experiment decides whether your redesign is worth the build, so we are testing a copy variant first. If it lifts signups, the redesign is next, targeted for the following sprint." Offer a date to revisit, and what evidence would move them up. Never say only "not now".

Pitfalls. Letting the loudest or most senior request jump the queue; skipping a legal or accessibility fix because it has no metric; promising a date you cannot hold.