Prioritization and Trade-Off Decisions Questions

Direct answer. Rank the three areas by expected harm removed: how many people are blocked, how badly, and how much legal exposure each carries. On the illustrative numbers below, fund checkout and search, and defer onboarding to next quarter with a date.

Measuring impact across the product

• Reach: monthly sessions in the area times the share of sessions hitting an accessibility barrier (from an audit or automated scan plus assistive-technology testing, meaning testing with tools such as screen readers that read the page aloud for blind users).
• Severity: 1 = hindered, 2 = serious, 3 = task blocked (for example a screen reader cannot complete payment).
• Legal risk: a multiplier from legal counsel. Counsel might say 1 for a flow where complaints are unlikely and 3 where a lawsuit or regulator complaint is plausible, as with payment. The values are a judgment call, which is why you ask counsel and test sensitivity (see below).

Check: 40,000 x 0.03 = 1,200; 1,200 x 3 x 3 = 10,800. 300,000 x 0.02 = 6,000. 25,000 x 0.04 = 1,000; 1,000 x 2 = 2,000.

Sessions hit is used as a stand-in for people affected (one person can account for several sessions, so unique-user counts from analytics would be better if available). The score multiplies the factors because each one scales the harm: twice the sessions hit, or twice the severity, doubles the expected harm. Severity and legal are ordinal judgments (1 to 3), not true ratios, so treat the scores as a rough ranking, not exact amounts.

Sensitivity: if legal said 1 for all three areas, checkout drops to 1,200 x 3 x 1 = 3,600, and search (6,000) moves first. The legal judgment is what decides the order, so get it in writing.

Decision: checkout first (blocked purchases plus the highest legal exposure), then search (very wide reach even though each barrier is milder). Onboarding is last: lowest score, though it deserves a scheduled follow-up since it is the first impression.

Who to consult

• Users with disabilities or an accessibility specialist: confirms which barriers truly block tasks.
• Legal/compliance: exposure and any deadlines.
• Engineering leads of each area: effort and whether fixes in search are shared with other areas.
• Customer support: complaint data, and the PM/design owners of the area that loses out, before the decision is announced.

What would flip it: a legal notice or customer complaint on onboarding, or a cheap shared-component fix that covers search and onboarding together.

Short answer

I would write a short decision record that a stranger can read in five minutes: what was decided, why, what else was considered, what was given up, and exactly what would make us revisit. The format follows the architecture decision record (ADR), a short written note per decision that Michael Nygard popularized in 2011 with sections for title, status, context, decision and consequences. I add options, scoring and revisit triggers.

The template, and why each part exists

Short excerpt (illustrative)

Decision: Ship the SSO login before the new reporting module. Status: accepted, review 15 March. Options: SSO first; reporting first; both with a smaller scope. Trade-off: reporting slips one quarter; three accounts that asked for it were told. Revisit if: more than two renewals cite reporting, or the SSO estimate grows past 8 weeks.

Decision log and retention

Keep a one-row-per-decision index (ID, date, decision, owner, status, review date) linked to each record. Store records in one searchable place such as the wiki or the product repository. Keep them as long as the product exists; mark old ones superseded instead of deleting or rewriting them, so history stays truthful.

Executive-facing version

A one-page summary on top of the record: recommendation, what we are not doing, the cost and risk, and the one thing we need from them.

Direct answer. Decide by the outcome you care about downstream, per visitor who starts onboarding, and test it. If a longer flow keeps more users even though sign-ups fall, the signup metric is the wrong target. Explain it as one funnel, not as one metric winning.

Worked example (illustrative). Out of 100 visitors who begin:

• Short flow: 60% finish and 20% of those are still active at 30 days. 100 x 0.6 x 0.2 = 12 retained.
• Long flow: 50% finish and 30% of those stay. 100 x 0.5 x 0.3 = 15 retained.

Signups fall by 10 per 100, but retained users rise by 3. The break-even retention for the long flow is 0.6 x 0.2 / 0.5 = 0.24, so it wins if its retention beats 24%.

Where the 0.24 comes from. Short flow: 100 x 0.6 x 0.2 = 12 retained. For the long flow to match that, 100 x 0.5 x r must equal 12, so r = 12 / 50 = 0.24. Above 24% retention it wins; below, it loses. Here its 30% clears the bar.

Simple two-direction matrix. "Payback" means the extra users kept later must make up for what the change costs now. A guardrail is a second metric you watch so a win on the main metric cannot hide damage elsewhere.

How to decide.

1. Run an A/B test and compare retained users per visitor started, not retention among finishers, since the long flow filters out low-intent users and that flatters its rate.
2. Set a guardrail (a second metric watched alongside the main one) on completion and on drop-off at the longest step.
3. Look for a middle path: keep the long flow's valuable steps but let people skip or defer them.

Communicating. Say: "Signups will drop, and that is expected. We are measuring retained users, which is what drives revenue." Show the trade in one chart, and ask leadership to agree the success metric before launch so the dip is not a surprise.

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.