How to build a quarterly product roadmap

That is normal and the model expects it. Outcomes span quarters; epics do not. Tenhaw plans its own engagements the same way, retainer-shaped and monthly with an exit date agreed at kickoff. Put the epics that move the outcome this quarter on this roadmap with their share of the value, leave the rest of the target unallocated until the next planning round, and carry the remainder forward. The outcome stays open in Working On or Value Monitoring across both quarters and only closes when every epic under it has closed. What you must not do is write one epic spanning both quarters to avoid the split, because that is the single change that makes the whole portfolio unforecastable.

Plan the first quarter at one to one and write on the roadmap that it is uncalibrated. Then record planned value against realised value for every epic, at each monthly outcome validation and again at the close. After two quarters you have a ratio worth using and after four it is stable enough to plan against. The first honest number is usually lower than the team expected, and that conversation is worth more than the arithmetic it changes.

Urgent work takes the same route as everything else. Shape it, price it and commit it as an outcome, or attach it to an existing epic if it belongs under one. Then it has to displace something. Find the epic with the lowest planned value per delivery week, move it to the cut list with its pounds attached, re-run the p85 forecast for the reduced set, and publish both changes together. Tenhaw takes that call as delivery lead inside Programme and Delivery Management, which is bought on its own even where another supplier is building. The failure mode is adding the new work without naming what it pushed out, because by the close nobody can separate under-delivery from a quarter that was quietly reloaded.

No. They carry a share of the person-weeks, not a planned contribution to any outcome target. Their return is avoided rework and avoided incidents, which cannot be attributed honestly at planning time without inventing a number, and inventing one there corrupts the calibration data everywhere else. Count them in capacity, report their burn rate monthly, and never let their absence from the value column become the argument for cutting them, which is the exact argument the two fixtures exist to defeat.

Start from the calendar and subtract before you count anything else. Write down the first and last working day, and thirteen calendar weeks gives you sixty-five working days per person. Then subtract public holidays, booked leave, on-call rotations, mandatory training, any release freeze, and the final week of the quarter, because a plan that runs into its last days has no room to close. Multiply what remains by headcount. Nine and a half delivery weeks across six people is 57 person-weeks, not the 78 the calendar implies, and that gap is where most over-committed quarters begin. Do this before opening the backlog, not after you have promised.

Open with ten per cent each for tech debt and bug fixing, then correct it with last quarter's actuals rather than intentions, so if bug work burned eighteen per cent of capacity, budget eighteen. Tenhaw won that argument at Greggs with delivery data showing tech debt work accelerated timelines, across two squads over six months. Both live as epics created before any feature epic, each with a named owner and a share of the person-weeks. Every bug and debt item found in the quarter links to one of the two, so nothing floats unbucketed, and by week six the burn rate against each budget tells you whether quality is improving or rotting. Resist raiding them mid-quarter; that reflex is what the two fixtures exist to stop.

Cap it at three or four live outcomes per team. Past that the epics compete for the same people and the quarter ends with four things at eighty per cent done and nothing validated. The cap also forces the right planning conversation. Only outcomes that have been shaped, priced and committed get roadmap space at all, and ideas still being explored wait. For each outcome you do take on, plan against the remaining target, the headline number minus the value already claimed by epics that closed in earlier quarters, because that remainder is what this quarter's epics actually have to cover.

Forecast the whole roadmap as one set. Size the epics, then simulate the entire quarter against your own throughput, sampling completed items weekly from the last eight to twelve weeks, and take p50 and p85 completion dates for the set. Four individually confident epics all landing in the same fortnight is the failure that kills most plans, and only a whole-set simulation exposes it. Forecast them one at a time, add the dates together, and that collision stays hidden. If your history is shorter than eight weeks or the team has changed size, say the forecast is unreliable and re-run it at the end of week three rather than publishing a number you do not believe.

Drop whole epics until the p85 forecast for the remaining set lands inside the quarter. A half-built epic delivers none of its planned value, while a deferred one delivers all of it next quarter, so cutting whole epics keeps the arithmetic honest and shaving scope off everything does not. Choose cuts by planned value per delivery week, protect the Tech Debt and Bug Budget epics from the cutting reflex, and publish the cut list with the pounds each deferred epic carried. That list is the part teams skip, and the part that protects them in month three when someone asks why something is missing.

Publish the roadmap where the business actually reads, not only inside the delivery tool. Tenhaw writes and maintains that published version inside Programme and Delivery Management. Show the outcomes with their currency targets, the epics under each with the planned value and the arithmetic visible, gate status for every epic, and the cut list with the pounds each deferred epic carried. Expect four to six weeks of work gated on day one and the rest still in research; a fully gated roadmap usually means the later epics were written thin. Finish by putting the monthly outcome validation dates and the close date in the calendar with named owners, so the quarter has a booked ending as well as a plan.

Start two to three weeks before the quarter begins, and budget about two days of focused work for one pass. Do it only once the outcomes you intend to work on are shaped, priced and committed, because a session that also has to invent the outcomes will produce neither them nor a plan. Three things need to be to hand: the delivery tracker holding the quarter's epics, an export of the last eight to twelve weeks of throughput, and a spreadsheet for the whole-set forecast. Plan again mid-quarter, the moment enough has changed that the published forecast is no longer honest.

Fewer people than most planning events assume. Product and engineering both have to approve every epic that opens the quarter, so both belong in the room rather than being consulted after it. Tenhaw staffs planning with senior people only, no junior rung, and its founder co-designed HSBC Global Payment Solutions' target operating model with selected teams there. Each epic's value arithmetic needs a named person who owns each input, usually whoever runs the system that number is read from. The Tech Debt and Bug Budget epics each need a named owner, set before any feature epic is written. Every cross-team dependency needs an owner and a date. The monthly outcome validation dates and the close date go in the calendar with names against them.

Take a made-up subscription business with one team of six. Public holidays, booked leave, half a week of training, a year-end freeze and the final week for close cut thirteen calendar weeks to 9.5 delivery weeks, so 57 person-weeks, of which 11.4 go to Tech Debt and Bug Budget. The outcome is reducing involuntary churn against a £900k target, with £150k already claimed by epics that closed, leaving a £750k remainder that at 70 per cent realisation needs about £1.07m of planned epic value behind it. Four priced epics total £910k, so a £160k gap gets named in planning, and the p85 lands three weeks late, which puts the smallest epic on the cut list.

The close is booked in the calendar during planning, with an owner against it, and the final week of the quarter is kept clear of planned work so there is room to do it properly. Tenhaw applies the same test monthly, and a month that delivers no measurable value is reported to the client as a failed month. At the close you read realised value against planned for every epic, and that reading is what sets the realisation ratio the next roadmap plans against. Outcomes that are not finished stay open and carry forward the remainder, the target minus the value claimed by epics that have closed. The cut list goes into the next planning session with the pounds each deferred epic carried attached.

Expect four to six weeks of it gated and the rest still in research. An epic does not open the quarter until it has product approval, engineering approval and the gate content its delivery mode requires, which means the research and design behind those first epics happened in the previous quarter. A fully gated roadmap is not the sign of a well-prepared team. It usually means the later epics were written thin, because nobody can honestly specify week eleven's work two weeks before the quarter opens. Gate the front, keep the research running behind it, and gate the rest as it becomes real.

Three readings, none of which needs a new report. Tenhaw built that reporting at Globelynx across 16 client deliveries, where lead times fell 60 per cent inside six months. Re-run the whole-set forecast at the end of week three, especially if the throughput history you planned from was short or the team changed size, then compare that p85 date with the one you published. Read the burn rate against the Tech Debt and Bug Budget epics, which is the only quality trend you get without building anything, and which shows whether those budgets are quietly being raided for feature work. And one monthly outcome validation will have run by then, so you hold a real reading of realised against planned rather than a status colour.

You can show a year of intent, but only the current quarter gets dated epics. Tenhaw's own engagements run monthly on the same footing, stopping on 30 days' notice either side rather than a twelve-month commitment. Outcomes span quarters and carry a currency target; an epic never spans one, and an epic with no single quarter to ship in makes a whole portfolio unforecastable. Beyond the quarter, publish the outcomes with the remainder still to cover, the target minus the value already claimed by epics that closed, alongside the cut list and the pounds each deferred epic carried. That is honest and useful. Dated epics twelve months out are neither, because the forecast behind them samples throughput the team has not generated yet.