How to answer an engineering roadmap planning interview question

In this article

1. Before you start
2. Why interviewers ask this
3. Engineering roadmap planning from first principles
4. Worked example
5. Trade-offs and edge cases
6. How to answer it in an interview
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

This page belongs to the leadership interview questions guide, and it pairs with how to build a roadmap and prioritize.

Why interviewers ask this

A roadmap answer shows how you choose between good options when you cannot do them all, and that is the daily work of an engineering manager (EM) or director. A vague answer ("I talk to stakeholders and prioritize") reveals nothing about how you decide, so a follow-up usually probes for the method.

A weak answer lists frameworks by name. A strong answer shows an order of operations: outcomes first, a capacity limit, a scoring method with its weaknesses stated, a way to show uncertainty to stakeholders, and a way to fund reliability. A Staff-level or director-level answer adds how the plan changes when evidence changes and how you measure whether the plan worked. Reports from candidates describe this question in EM and director loops; no public source says how any company scores it, so treat the points above as advice about what a strong answer shows.

Engineering roadmap planning from first principles

Engineering roadmap

An engineering roadmap is a shared plan that orders the problems and bets an engineering team will work on, by priority and by confidence, so product, leadership and engineers can see direction without reading a ticket list.

Now-Next-Later roadmap

A Now-Next-Later roadmap is an outcome-focused product roadmap that organizes work by levels of confidence instead of fixed dates: Now holds work in progress, Next holds validated opportunities the team is still refining, and Later holds strategic bets.

In plain words

Think of planning a road trip with a fixed amount of fuel. You choose the destination first, because it decides which routes matter. Then you check the fuel, because it limits how far you can go. Then you rank stops by how much they add to the trip per liter. You also keep some fuel back for a breakdown. The analogy breaks in one place. A team's fuel use is uncertain, so some stops are guesses, and the plan must say which.

In one precise sentence, an engineering roadmap planning answer states the outcomes, the capacity, a transparent way to rank bets, a confidence level for each and a reserve for reliability.

Step 1: Start from outcomes and capacity

Outcomes and capacity come before any ranking. An outcome is a change in the world you want, such as fewer failed checkouts, and a feature is only one way to get it. Capacity is what the team can finish, measured here in person-months. A person-month is the work that one team member can do in a month, the unit Intercom's reach, impact, confidence, effort (RICE) post uses for effort.

Say both limits aloud in an interview. "We have about this much capacity and these two outcomes" frames every later choice and shows that you plan against a limit instead of a wish list. Then subtract the reserve for reliability and maintenance before you count what is left for new bets; Step 4 shows how to size it. You now know what the plan must fit inside; the next step ranks what goes in.

Step 2: Score each bet with RICE and say how sure you are

RICE is a scoring method named for four factors: reach, impact, confidence and effort (Intercom, Sean McBride, 2018). RICE multiplies reach, impact and confidence, then divides by effort. The result measures "total impact per time worked", which is the quantity a team wants to maximize.

Reach is a count of people or events per time period, such as customers per quarter. Impact comes from a fixed scale: 3 for massive, 2 for high, 1 for medium, 0.5 for low and 0.25 for minimal. Confidence is a percentage: 100% is high, 80% is medium, 50% is low, and anything below that is a total moonshot. Effort is in person-months and divides the score, because more effort is a bad thing.

Confidence is the factor candidates skip, and it is the only one that admits the other estimates may be wrong; halving it halves the score. The worked example below shows a project that leads the list only while its confidence stays above about 42%. Naming that threshold shows you ask what would change the ranking, not only what the ranking is.

Step 3: Group bets by confidence, not by calendar

Now-Next-Later columns are confidence horizons, not quarters. According to ProdPad's glossary (updated June 2026), Now is work actively being done, Next is validated opportunities the team is still refining and Later is strategic bets. Now-Next-Later columns must not be used as Q1, Q2 and Q3, which ProdPad lists as a common mistake.

The format is not anti-date. Put dates on real commitments, such as a contract or a legal deadline. In an interview, say which of your items are commitments and which are bets. A stakeholder who sees that split trusts the plan more than one who sees a single list of dates.

Step 4: Fund reliability and measure the outcome

An error budget funds reliability work while releases keep shipping. An SLO (service level objective) is a reliability target, such as the share of requests that must succeed in a quarter. The Google workbook states that an error budget is 1 minus the SLO, so a 99.9% SLO leaves a 0.1% budget. In the Google site reliability engineering (SRE) book, as long as error budget remains, new releases can be pushed.

The workbook's example policy ties the budget to the plan: if a single class of outage consumes more than 20% of the error budget over a quarter, the team must have a top-priority item in its quarterly planning document to address it. That sentence turns "we should fix reliability" into a rule a roadmap can carry. Measure the outcomes from Step 1, such as the failed-checkout rate. For delivery health, DORA (DevOps Research and Assessment) lists five software delivery metrics, and its research says speed and stability are not trade-offs. Use them to learn, not to set targets.

1 · Outcomes2 · Score3 · Group4 · ReliabilityReplay

Step-by-step description

1. Set outcomes and capacity first.
2. Score each bet and state confidence.
3. Group bets by confidence.
4. Fund reliability with an error budget.

• Outcomes and capacity come before any ranking.
• RICE multiplies reach, impact and confidence, then divides by effort.
• Now-Next-Later columns are confidence horizons, not quarters.
• An error budget funds reliability work while releases keep shipping.

Worked example

Intercom's post gives three projects as inputs, and the scores below are computed from them with score = reach × impact × confidence ÷ effort.¹ Project 1 has a reach of 450 per quarter, an impact of 3, a confidence of 100% and an effort of 2 person-months. Project 2 has a reach of 2,000, an impact of 1, a confidence of 80% and an effort of 4. Project 3 has a reach of 800, an impact of 2, a confidence of 50% and an effort of 1.¹

The reach arithmetic in the same post is 500 a month × 30% × 3 months = 450 per quarter.¹ The author also says RICE scores should not be used as a hard and fast rule, because a project may be a dependency for another or may be table stakes for certain customers.

The ranking is Project 3, Project 1, Project 2.¹ Project 3 stays first only while its confidence stays above about 42%: at an illustrative confidence of 30%, its score falls to 480 and Project 1 moves ahead. Raising Project 3's confidence estimate from 50% to an illustrative 80% would lift its score to 1,280.¹

Text description of the diagram

• Project 3 scores 800, Project 1 scores 675 and Project 2 scores 400.
• Project 3 stays first only while its confidence stays above about 42%.

Next, capacity. Suppose a team of 8 engineers works for 3 months, which is 24 person-months (illustrative). A 70/20/10 split across features, reliability and technical debt gives 16.8, 4.8 and 2.4 person-months; the split is an assumption, not a figure from any source.¹ The three projects cost 7 person-months together, so 9.8 person-months of feature capacity remain for other bets.¹

For reliability, a 99.9% SLO over 1,000,000 requests in four weeks allows 1,000 errors (Google workbook). A 99.999% quarterly SLO leaves a 0.001% budget, and an incident that fails 0.0002% of the quarter's expected queries spends 20% of it (Google SRE book).¹

Trade-offs and edge cases

A scoring method makes trade-offs explicit, and it never makes them for you. Dependencies and table-stakes work can justify a lower-scored project first (Intercom), so treat the score as the start of a conversation. A project's reach and impact are estimates, and confidence only describes how good those estimates are.

A timeline is not wrong; it fits some work. ProdPad says a timeline or Gantt chart is best when you have genuine fixed deadlines and high certainty.

Text description of the diagram

• A timeline suits genuine fixed deadlines and high certainty.
• Now-Next-Later columns must not be used as Q1, Q2 and Q3.

When a plan changes mid-quarter, see when priorities change mid-quarter. When reliability and features compete, see tech debt versus features. DORA warns against setting metrics as a goal, making disparate comparisons and competing across teams, and it says the metrics are best applied to one application or service at a time. Reliability targets also have a ceiling: Google says 100% is probably never the right target. Pressure is a separate problem; delivery under pressure covers it.

How to answer it in an interview

The spoken structure: outcomes and capacity, then scoring with its limits, then confidence horizons, then reliability, then the review habit. Rehearse it out loud until it fits about a minute.

Common mistakes

• "RICE gives us the answer." (wrong) The author of the method says the scores are not a hard rule. (right) "RICE ranks the options; dependencies and table-stakes work can still change the order, and I say so."
• "Now, Next and Later are Q1, Q2 and Q3." (wrong) The columns are confidence horizons. (right) "Dates go on commitments only; the columns show how sure we are."
• "We slow down to be safe." (wrong) DORA's research says speed and stability are not trade-offs. (right) "Smaller changes are easier to recover from if there is a failure, as DORA's guide notes, so I ship in small steps."
• "We aim for 100% reliability." (wrong) Google says it is probably never the right target. (right) "We set an SLO and spend the error budget on purpose."

Follow-up questions

How do you build a roadmap and prioritize?

Name the outcome, state capacity, score the bets, group them by confidence and review often. The full walk-through covers the same order for a broader question.

How do you balance tech debt and features on a roadmap?

Reserve a share of capacity for it and attach reliability work to evidence such as error-budget burn, as in the workbook's policy. The tech debt page goes deeper.

What do you do when priorities change mid-quarter?

Re-score the affected bets with the new evidence, move items between horizons, and tell stakeholders what slipped and why. See priorities that change mid-quarter.

Should an engineering roadmap have dates?

Only on real commitments. A Now-Next-Later roadmap is not anti-date, but a date on an uncertain bet creates false precision.

How do you say no to a stakeholder's request?

Show the scores and the capacity limit, then offer a trade: what moves down if the request moves up. Stakeholder management for EMs covers the conversation, and the director of engineering questions show where it leads at larger scope.

Which metrics show that the plan is working?

Track the outcome metrics you set in Step 1 (for example, the failed-checkout rate) to see whether the bets worked. Use the five DORA metrics (change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate) to see whether delivery itself is healthy, and avoid turning them into targets.

Sources

1. RICE: Simple prioritization for product managers — Intercom Blog (Sean McBride), 5 Jan 2018
2. What Is a Now-Next-Later Roadmap? — ProdPad glossary (vendor page), 29 Jun 2026
3. DORA's software delivery performance metrics — DORA (dora.dev), 5 Jan 2026
4. Embracing Risk (Site Reliability Engineering book) — Google SRE book (undated page), 26 Oct 2026
5. Example Error Budget Policy (Site Reliability Engineering workbook) — Google SRE workbook, 19 Feb 2018