In this article
Before you start
Why interviewers ask this
Roadmap questions reveal whether a manager plans from capacity or from wishes. A candidate who says "I list the most important things and the team does them" has not said what is left out, how much time is real, or what happens when the plan breaks. The question is reported in interviews at large technology companies in several forms, such as how you manage priorities, how you plan with objectives, quarters or sprints, and how you balance upkeep and new work.
A weak answer names a framework and stops. A strong answer states the goal, the capacity arithmetic, the ordering rule and the reserve, and then names one thing the team did not do and why. The engineering manager interview guide shows how planning questions fit the wider loop.
Building a roadmap from first principles
- Roadmap
- A roadmap is an ordered plan of the outcomes a team intends to deliver over a period, tied to goals and sized against the capacity it really has, which differs from a backlog because it commits to an order and a boundary.
- Capacity reserve
- A capacity reserve is a share of a team's time deliberately left unassigned at planning time so that urgent, unplanned work can be absorbed without displacing the committed roadmap.
In plain words
A roadmap is like a household budget for time. You decide what matters this month. You count the hours you really have after commuting and chores. You keep an envelope for the surprise bill. You spend the rest in order of value. The analogy breaks on estimates. A household knows its rent, but an engineering estimate is a guess with error. So the plan needs a check-in, not just a sheet.
Said precisely, there are three steps: fix the goal and horizon, size capacity after a reserve, and order the work by a visible rule. Google's guide says its teams set annual and quarterly objectives and key results (OKRs). They grade them from 0.0 to 1.0 and aim for 60 to 70 percent, which signals ambitious goals (Google re:Work, 2016).
Step 1: Set the goal and the planning horizon
The first step is to agree what the period is for before anyone lists projects. The input is the company or product goal; the output is two or three outcomes for the period, each with a measure, and a horizon such as a quarter. An OKR is an objective with measurable key results, and the Google guide describes grading them and revisiting them a few times a quarter.
A roadmap is not the backlog. The Scrum Guide calls the Product Backlog "an emergent, ordered list of what is needed to improve the product" and says a Sprint, a fixed-length event of one month or less, has a single Sprint Goal (Scrum Guide, November 2020). The roadmap sits above that: outcomes for the quarter, with the backlog and sprints as the weekly mechanics. What you now know: what the period is for and how you will judge it.
Step 2: Size capacity with a reserve for the unplanned
The second step turns the team size into honest planned capacity by taking out leave, upkeep and a reserve. The input is people times weeks; the output is the engineer-weeks that can be committed. A team of 8 engineers over 13 weeks has 104 engineer-weeks. Taking out 8 percent for leave, 20 percent for keeping systems running and 15 percent as a reserve for the unplanned leaves 59.3 engineer-weeks, or 57 percent, for planned work; the percentages are illustrative.1
Google's site reliability engineering (SRE) organisation aims to keep operational work below 50 percent of each engineer's time (Google SRE book, 2017). That is the reason to size upkeep honestly. The reserve answers the follow-up: an urgent outage of 6 engineer-weeks takes 38 percent of a 15.6-engineer-week reserve and leaves the committed roadmap intact.1 What you now know: how much work you can promise.
Step 3: Score and order the work
The third step orders candidates by a visible rule and checks they fit the capacity from Step 2. Intercom's reach, impact, confidence, effort (RICE) method scores a project as Reach times Impact times Confidence divided by Effort, with Impact on a scale from 0.25 to 3, Confidence of 100, 80 or 50 percent, and Effort in person-months (Intercom, 5 January 2018).
Reach is how many people a project affects per period, here customers per quarter. A person-month is one person working for one month. Intercom's Effort counts product, design and engineering time. Using Intercom's example inputs, the score is Reach times Impact times Confidence divided by Effort; for Project 1 that is 450 x 3 x 1.0 / 2 = 675.1
| Project | Reach (customers per quarter) | Impact | Confidence | Effort (person-months) | Score |
|---|---|---|---|---|---|
| Project 1 | 450 | 3 | 100% | 2 | 675 |
| Project 2 | 2,000 | 1 | 80% | 4 | 400 |
| Project 3 | 800 | 2 | 50% | 1 | 800 |
Project 3 goes first despite 50 percent confidence.1 Together the three need 7 person-months of product, design and engineering time, about 30 person-weeks; even if all of it were engineering time, the list fits inside the 59.3 planned engineer-weeks.1 A score starts the conversation; check dependencies too. What you now know: an order you can defend.
Step-by-step description
- Set outcomes and a horizon.
- 104 engineer-weeks, 59.3 for planned work.
- Score, order, stop where capacity stops.
- A team of 8 engineers over 13 weeks has 104 engineer-weeks.
- Planned work gets 59.3 engineer-weeks after leave, upkeep and a reserve.
Text description of the diagram
- Planned work gets 59.3 engineer-weeks, or 57 percent, in the illustrative example.
- The reserve is 15.6 engineer-weeks.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →The Staff-level answer
A Staff-level answer ties the roadmap to goals, shows the capacity arithmetic and the reserve, and names a decision to stop something.
How do you build a roadmap and prioritise?
I start from the goals for the quarter and what we will measure. Then I size capacity honestly: people times weeks, minus leave, upkeep and a reserve, which for my team of eight leaves a little over half the quarter for planned work. I score candidates on reach, impact, confidence and effort, order them, and fit them into that planned capacity, so the list stops where the capacity stops. I say aloud what we are not doing and who agreed. I check in mid-quarter, and an urgent problem draws from the reserve first.
What makes it Staff-level: it commits to a boundary and says what is not done, it treats uncertainty as a reserve and a check-in, and it names who agreed.
The rubric
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Goal | "Most important things" | Quarterly goals with measures | Goals tied to the company outcome |
| Capacity | Not mentioned | People times weeks | Net of leave, upkeep and a reserve |
| Ordering | Gut feel | A scoring rule | A rule plus dependencies and risk |
| Trade-off | None | Names what is left out | Names who agreed to leave it out |
| Change | Plan is fixed | A mid-quarter check | A reserve and a rule for urgent work |
Three variants of this question
How do you plan: OKRs, quarterly plans or sprints?
OKRs, quarterly plans and sprints are three layers, not three alternatives. OKRs set the outcomes, a quarterly plan sizes and orders the work, and sprints run the weeks; the Google guide recommends revisiting OKRs a few times a quarter.
How do you work with product management to define features for each release?
Agree the outcome and the measure with the product manager first, then trade scope against capacity in one visible list. Neither side owns the whole decision. See the stakeholder management guide.
How do you measure the success of a project?
Name one outcome measure set before the work starts, such as lead time or adoption, and one cost measure, such as engineer-weeks used. Compare both with the plan after launch, not only on the launch date.
Common mistakes
- Planning at 100 percent. (wrong) "We assign every engineer-week." (right) Reserve time for leave, upkeep and surprises; here 43 percent was not planned work.
- Naming a framework as the answer. (wrong) "I use RICE." (right) Say the goal, the capacity, the ordering rule and one thing left out.
- Never saying no. (wrong) "We do everything." (right) The list ends where capacity ends, and you say who agreed.
- Treating the score as truth. (wrong) "It scored highest, so we did it." (right) Check dependencies and low-confidence inputs.
- A plan with no check-in. (wrong) "The roadmap is set for the year." (right) Check mid-quarter and adjust; see when priorities change mid-quarter.
Follow-up questions
How much of your capacity do you reserve for unplanned work?
It depends on how much unplanned work you actually see, so measure it for a quarter and set the reserve to match. The example used 15 percent plus 20 percent for upkeep, both illustrative; Google's SRE guidance of staying under 50 percent operational work is the ceiling for an operations-heavy team.
What do you do when the roadmap is fully committed and an urgent outage arrives?
Take the work from the reserve first. If it is larger than the reserve, tell the owners of the lowest-ranked committed items what will slip, and agree it with them before you start rather than after.
How do you say no to a vice president?
Show the trade-off in their units: what the new request displaces, by how much, and what you recommend. Offer an order and a date, and ask which committed item they would drop. The driving a cross-team change page covers how to get agreement across teams.
How do you balance tech debt and keeping the lights on with new work?
Count upkeep as a named bucket in the capacity, and fund it before features. The example gave it 20 percent of the quarter, an illustrative share. For the decision between paying down debt and shipping, read tech debt vs features.
How do you prioritise between business requirements and tech debt?
Put both in the same visible order. Score the business request on reach, impact, confidence and effort, and state the cost of the debt in the same units, for example the engineer-weeks it takes from every quarter. Fund the upkeep bucket first, then let the score decide the rest. The tech debt vs features page covers the argument in full.
How do you manage priorities?
Keep one ordered list tied to the goals, review it at a fixed point such as mid-quarter, and change it only by naming what drops. For neighbouring delivery topics see the project, program and agile hub and the product management hub.
- Set goals and a horizon first; the roadmap sits above the backlog.
- Size capacity as people times weeks minus leave, upkeep and a reserve.
- Order by a visible rule such as RICE, then fit the list to the capacity.
- Say what you are not doing, who agreed, and when you will check again.
Sources
- Set goals with OKRs — Google re:Work (originally published 2016), 1 Jan 2016
- The Scrum Guide — Ken Schwaber and Jeff Sutherland (November 2020), 1 Nov 2020
- Eliminating Toil, Site Reliability Engineering — Google (O'Reilly Media, 2017), 1 Jan 2017
- RICE: Simple prioritization for product managers — Intercom (Sean McBride), 5 Jan 2018
