Roadmap Prioritization Frameworks for EM Interviews

Every EM interview includes some version of this question: "You have five projects competing for three engineers. How do you decide?" The interviewer is not looking for gut instinct. They want a structured framework, clear communication of trade-offs, and evidence that you can say "no" with data.

The RICE Framework

RICE was created by Sean McBride at Intercom as a way to objectively score product and engineering initiatives. It stands for:

RICE Score = (Reach x Impact x Confidence) / Effort

Component	Definition	How to Estimate
Reach	Number of users/customers affected per quarter	Use product analytics, funnel data, or user counts
Impact	How much each user is affected (scale: 0.25 = minimal, 0.5 = low, 1 = medium, 2 = high, 3 = massive)	Align with business goals -- revenue, retention, satisfaction
Confidence	How certain you are in the estimates (100% = high, 80% = medium, 50% = low)	Based on data quality, research, past accuracy
Effort	Person-months of engineering work required	Use t-shirt sizing converted to numeric values

Example: A search improvement project reaches 50,000 users/quarter, has high impact (2), you are 80% confident, and it takes 3 person-months.

RICE Score = (50,000 x 2 x 0.8) / 3 = 26,667

The number itself is meaningless -- it is only comparable against other RICE scores from the same team using the same scales. What makes RICE worth using in an interview is what happens when you move one input. Effort is in the denominator, so it dominates: halving the effort does more for the score than doubling the reach. Try it.

Two things worth taking into an interview from this. First, the confidence term is the one people quietly inflate, because unlike reach and effort nobody can audit it -- so ask what evidence sets confidence above 80%, and be ready to be asked that yourself. Second, because effort dominates, descoping is a prioritisation tool, not a concession. "We can double this project's score by cutting the reporting view from v1" is a stronger contribution to a planning meeting than any argument about relative importance.

The ICE Framework

ICE is a simpler alternative when you need faster estimation. Each component uses a 1-10 scale:

ICE Score = Impact x Confidence x Ease

Component	Scale	Notes
Impact	1-10	Business value if the project succeeds
Confidence	1-10	How sure you are it will work
Ease	1-10	How easy it is to implement (inverse of effort)

ICE works well for early-stage prioritization when you lack precise data. RICE is better when you have quantitative reach data.

Weighted Scoring Models

When RICE or ICE feel too narrow, weighted scoring lets you add custom dimensions:

Criterion	Weight	Project A	Project B	Project C
Revenue Impact	30%	8	5	9
Strategic Alignment	25%	7	9	6
Technical Risk	20%	4	7	3
Customer Demand	15%	9	6	8
Team Readiness	10%	6	8	5
Weighted Score		6.90	6.85	6.50

Every criterion here is scored higher is better, which is worth saying out loud because one of them reads the other way round. "Technical Risk 4" for Project A does not mean it is the fourth-riskiest; it means it scores 4 out of 10 on being low-risk. A criterion whose name implies a cost and whose scale rewards the absence of it is the most common way a weighted model gets read backwards in a room, and the fix is to name the column for the good thing -- "Technical Confidence" -- rather than to explain the inversion each time.

Check the arithmetic yourself rather than trusting the row: Project A is (8 × 0.30) + (7 × 0.25) + (4 × 0.20) + (9 × 0.15) + (6 × 0.10) = 2.40 + 1.75 + 0.80 + 1.35 + 0.60 = 6.90. Doing this in front of an interviewer is not pedantry. A weighted-scoring model is only as persuasive as its arithmetic, and the fastest way to lose a prioritisation argument is to have a stakeholder find an error in your spreadsheet while you are defending its conclusion.

The power of weighted scoring is transparency. Stakeholders can see exactly why Project A ranked above Project C, and they can challenge specific weights rather than arguing about feelings.

Notice also how close A and B are -- 6.90 against 6.85. A gap that small is not a result, it is a tie. The honest reading is that the model cannot separate these two projects and the decision has to be made on something the model does not capture: sequencing, who is available, or which one teaches you more about the market. Presenting 6.90 versus 6.85 as a ranking is the most common way these frameworks are misused, and an interviewer who knows that is listening for whether you say so.

The Tech-Debt Allocation: Balancing Debt vs. Features

A common EM interview question is how you balance feature work against tech debt, and the common answer is "we reserve 20% of each sprint." Say the number if you like, but know what it is: a practitioner convention, not a research result. There is no study establishing 20%, no standards body behind it, and the figure teams actually run sits somewhere in the 10-25% band depending on how much debt they carry and how much it currently hurts. A candidate who states 20% as an industry standard invites the follow-up "standard according to whom?", and that is a bad place to be.

What survives the follow-up is the reasoning, and it is the same reasoning whatever number you land on:

• A fixed reservation beats an ad-hoc one, because the alternative is negotiating for debt time every sprint against a feature request, and debt loses that argument every time.
• The number has to be small enough to be uncontroversial and large enough to compound. Too small and the debt outruns the payments; too large and the roadmap visibly stalls and the reservation gets cancelled the first time a deadline slips.
• A predictable cadence is most of the value. Engineers plan around a known slice; they do not plan around a promise that this quarter will be calmer.
• It exists to avoid the "big bang rewrite" trap, where nothing is paid down for two years and then everything stops for six months.

The strong interview answer names its own evidence. "We run 20%" is a preference. "We ran 20% for two quarters and build time went from 14 minutes to 4, so we held it" is a decision, and it is the version that survives a VP asking why the number is not zero.

How to implement it in practice:

• Reserve 1 day per week per engineer for tech debt (or 2-3 days per sprint in a 2-week cycle)
• Let the team choose which tech debt items to tackle -- they know the pain points
• Track tech debt reduction with metrics (build time, deploy frequency, incident count) so you can show ROI to stakeholders

Communicating Trade-Offs to Stakeholders

The hardest part of prioritization is not the math. It is explaining to a VP why their project ranked fourth. Use this structure:

1. Lead with the framework -- "We scored all six proposals using RICE. Here are the results."
2. Show the data -- Present the actual scores side by side.
3. Acknowledge what is being deferred -- "Project X is valuable. Its RICE score is 12,000 versus 26,000 for the top project. We are scheduling it for Q3."
4. Offer alternatives -- "If Project X is urgent, we can accelerate it by descoping feature Y or adding one contractor."

Saying "No" Constructively

Engineering Managers must say "no" constantly. The skill is making it feel collaborative rather than adversarial:

• Never say "no" without data. Replace "We can't do that" with "That scores 4,200 on RICE versus 18,000 for our current top priority. Here is the trade-off."
• Offer a "yes, if" alternative. Instead of rejecting a request, state the conditions: "Yes, if we can defer the mobile redesign by 3 weeks" or "Yes, if we get one more engineer."
• Document decisions. Keep a prioritization log so you can reference past decisions. This prevents re-litigating the same arguments every quarter.

Quarterly Planning in Practice

In an interview, describe your quarterly planning process as a cycle:

1. Collect inputs -- Engineering tech debt list, product roadmap requests, customer support escalations, OKRs
2. Score everything -- Apply RICE or weighted scoring to every candidate project
3. Capacity check -- Map scored projects against available engineering weeks (subtract holidays, on-call, and the 20% tech debt allocation)
4. Stakeholder review -- Present the draft plan, collect feedback, adjust weights if the business context has changed
5. Commit and communicate -- Lock the plan, publish it broadly, and define what "done" means for each project

Next, we will cover how to communicate your prioritization decisions to executives using structured frameworks that match how they think. :::