Your roadmap is a P&L

Read this if your roadmap meetings end with whoever argues longest. A feature request is a claim on scarce team time. Put a price on that time, a range on what the work might earn and a date on when it starts paying. The conversation gets shorter once everyone uses the same numbers.

Eight roadmap candidates sit on the screen. Two hours pass. Sales has a customer quote. Marketing has a competitor screenshot. Product has a retention chart. By the end, the CEO has secured a homepage redesign, partly because nobody wants a third hour.

The redesign will consume seven weeks of a full delivery team. At $15,000 per team-week, that is $105,000 of capacity before the first customer sees anything. Those seven weeks could have gone somewhere else.

Your roadmap is a P&L. Every item spends team time in pursuit of a return. Put cost, expected return, timing and confidence on one sheet and most of the argument changes. The company, figures and forecasts in this worked example are invented. Its single costing assumption is $15,000 per delivery-team-week, including the team's loaded cost.

Everyone brings a different currency

One request has five customers behind it. Another appeared in a competitor's launch. A third looks impressive in a board deck. Each sounds persuasive until somebody asks how to compare them.

The disagreement survives because there is no common unit. A 2026 ProductPlan survey of 250 product leaders reported that leadership escalations override more than 60% of prioritization frameworks.¹ A framework does little good when the final decision can ignore it.

A framework does little good when the final decision can ignore it.

Use money as the starting unit. The goal is to put competing claims through the same test, even when the answers are rough. A customer request remains evidence. It needs an estimate of the revenue it could bring or keep.

Start with the bill

Count the delivery-team-weeks needed to finish the item. Multiply by the cost of one team-week. Add outside help, software and any ongoing support or hosting cost.

Team time has a cost even when the salaries are already in the payroll. It is capacity you cannot spend twice. Keep that economic cost separate from new cash spending when talking to finance.

Then write down what moves back. If the homepage uses seven team-weeks, which items wait? Put their likely lost return beside the choice. Do not quietly add that opportunity cost twice when comparing two complete plans.

Four ways work can pay

A roadmap item earns its place by making money, keeping money, removing a real cost or saving a bigger expense later.

New revenue: More customers buy, or existing customers spend more. Count the contribution left after the costs of serving them. A million dollars of sales is not a million dollars of return.

Revenue kept: Fewer customers cancel or fail to renew. Estimate how much revenue would have disappeared without the change. A control group helps.

Cost removed: Fewer payment failures, fewer manual cases or less infrastructure spend. Time saved is useful, but it becomes cash savings only when spending falls or a hire is avoided.

Learning: A small test might reveal that a proposed major build will fail. Count the larger expense you can avoid. Treat that as a one-time benefit rather than pretending it arrives every month.

Give each idea a low and high estimate. A range makes uncertainty visible without turning the meeting into a contest over decimal places.

A month in the queue has a price

A feature that could be earning money now earns nothing while it waits. Don Reinertsen calls the profit lost per unit of delay the cost of delay. His published first chapter and accompanying explanation make the case for measuring development choices in economic terms.²

Our checkout fix is expected to bring in $45,000 a month at the middle of its range. After the confidence adjustment used below, the planning figure is $40,500. Ship it a month later and you may forgo $40,500. Push it back two months and the estimated loss is $81,000.

That shortcut assumes the opportunity stays available and the benefit starts promptly. A slow rollout or a seasonal business needs a different curve. The point is to put a price on waiting before assigning the next sprint.

Give opinions a smaller number

The payoff estimate is only as good as the evidence beneath it. A live test showing fewer abandoned checkouts earns more confidence than a competitor screenshot. A customer using an existing workaround is better evidence than a sales promise.

For a quick first pass, multiply the midpoint of each monthly range by a confidence percentage. Call the result adjusted monthly return. The percentages are judgments, not statistically measured odds. They force the team to show where it has proof and where it has hope.

Now rank the work by adjusted monthly return per delivery-team-week. Calculate simple payback as build cost divided by adjusted monthly return. Ongoing costs are already deducted from the monthly ranges.

Five items, one table

Monthly return means added contribution or avoided cash cost, net of ongoing expenses. The score uses the midpoint times confidence, divided by team-weeks. Payback uses the same adjusted monthly return. ★ marks the executive's original choice.

The checkout fix and renewal retries together take five team-weeks and cost $75,000. Their adjusted return adds to $62,100 a month. The homepage redesign takes seven team-weeks and costs $105,000 for an adjusted $10,500 a month.

That leaves two team-weeks free and $30,000 less capacity committed. The smaller jobs could bring nearly six times the estimated monthly return. They may also overlap in practice. Check that before adding either return to a forecast.

The ranking is a first filter. Product lifespan, hard deadlines, dependencies and the time needed to launch can change the order. Nobody should approve the full budget from one score.

Leave room for the unknown

Some work has no defensible return estimate yet. A new market, an unfamiliar technology or an idea that could change the business may deserve attention anyway.

Give those bets a fixed share of capacity in advance. Fund small tests that answer specific questions. Stop the work when the evidence tells you to stop. A new idea should not need a fictional revenue forecast to compete with a checkout repair.

Look at the same invented company's last quarter. Four teams had 52 delivery-team-weeks between them. Six went to deliberate bets. Another eight went to work with no clear result attached. Those are different categories. The first was a choice. The second needs an explanation.

Close the month against the promise

Finance compares a budget with actual spending. Product can do the same with returns.

Each month, show what an item was meant to earn, what it has produced so far and how you measured the difference. Revenue gains need a fair baseline. Retention work needs time for customers to renew. Cost savings need an actual expense to fall or an agreed hire to be avoided.

Record surprises. A feature that makes half the promised return can still be a good investment. A failed pilot can justify itself if it prevents an expensive rollout. Adjust the next estimate using what happened, rather than preserving a flattering forecast.

The meeting gets less political when the numbers are visible before anyone speaks. People can argue about a range, the evidence or the timing. At least they are arguing about the same decision.

Build the table for your next roadmap meeting. Five items. One hour. Let the numbers make the first cut, then spend the remaining time on what they cannot settle.