A technical roadmap for a fundraise

A technical roadmap for a fundraise is a twelve-month plan that ties the engineering work to the money being raised, carries its own maintenance and technical-debt share, and is checked against the team's measured delivery capacity. That is the whole shape. The rest of this page is what goes on each line and what the reviewer does with it. The pillar page on preparing for technical due diligence puts the roadmap in sequence with the rest of the preparation, and the investor's view of how the roadmap is read is on SaaS metrics versus engineering reality.

Matt Van Itallie's checklist, published in TechCrunch on 26 October 2022, asks for three things under the product roadmap heading that this page is built around: the last twelve months of product management data split between new features and maintenance, the roadmap for the next twelve months, and (under code quality) what finance invests in preventing and remediating technical debt, security risk and IP risk [1]. His list of eight reviewer questions, published the day before, makes the last of those a question in its own right: "How much does finance invest in tech debt prevention?" [2]. Reveneau's preparation method treats the roadmap as the answer to all three, one document with the history on the left, the plan on the right, and the debt line in both, because a reviewer who can see the split going backward and forward has no reason to compute it.

What does a reviewer do with the roadmap?

A reviewer reads the roadmap against three other things: the deck, the ticket history, and the deploy log. Against the deck, they check that the product the roadmap builds is the product the deck sells. Against the ticket history, they check that the team has been working on what the roadmap continues, which is Van Itallie's first question ("What have you been working on?") [2]. Against the deploy log, they check that the team ships at a rate that makes the roadmap's dates possible.

The third check is the one founders miss. DORA's software delivery metrics, as defined on dora.dev, include deployment frequency and change lead time, the time from a commit to running in production [8]. A reviewer computes both from your logs. A roadmap whose first quarter assumes twelve releases from a team whose deploy log shows six per quarter is a plan the reviewer will mark as unsupported, whatever the deck says about velocity. The page on what investors look for in a startup's codebase covers computing the five DORA numbers before the reviewer does.

What should each line of the roadmap carry?

Each line carries six things, and a roadmap is a table of them:

Column	What it holds
Item	One deliverable a customer or an operator would notice
Why	The customer problem or the revenue line it serves, in one sentence
Cost	Engineer-weeks, from the team's own estimate
Needs	What the round buys for this line: a hire, a vendor, infrastructure
Quarter	When it ships, with the dependency on any earlier line named
Evidence	The load test, customer request or incident that justifies it

The "needs" column is the one that ties the roadmap to the fundraise. If the round is for two engineers and a data platform, the roadmap should show which lines those two engineers and that platform make possible, and the lines should sum to the ask. A roadmap that would be the same with or without the money is telling the investor the money is not needed, and a roadmap that needs more than the money is telling them the ask is wrong. Our guide to software development cost covers estimating the cost column, and scaling engineering teams covers what a new hire adds to capacity and when.

Keep the "why" column honest about who asked. A line justified by "three of the five largest customers asked for this in Q2, tickets attached" is an artefact; a line justified by "strategic" is a slide.

How much of the roadmap should be maintenance?

Whatever share the last twelve months show, unless you can say what changes. The checklist asks for the historical split between new features and maintenance [1] because the reviewer wants to know two things: what the real share is, and whether the roadmap pretends it is smaller.

Compute the share from the ticket export: label every ticket in the last twelve months as feature, maintenance or incident, and total the engineer-time or the ticket count per label. Then carry the same share into the roadmap as a standing line per quarter. If the historical share is 35 percent maintenance and the roadmap shows 10 percent, the reviewer will ask what changed, and "we will have fewer bugs" is the answer that ends the conversation badly. "We are retiring the legacy reporting module in Q1, which produced 40 percent of maintenance tickets last year, tickets attached" is the answer that survives.

The right share differs by company. A reviewer at seed expects more maintenance than a reviewer at Series B, and a product with a hardware integration expects more than a web application. What every reviewer expects is that the number on the roadmap is the number in the history, or that the difference has a reason with evidence.

Where does technical debt go on the roadmap?

On its own line, with a budget, per quarter. Van Itallie's seventh question is "How much does finance invest in tech debt prevention?" [2], and the only artefact that answers a question about investment is a line item with a number on it. Put the technical-debt line in the same table as the feature lines, with the same six columns, and let the "evidence" column carry the item from the known-problems list it addresses.

This is also where the architecture presentation's change table lands. The page on presenting your architecture to investors describes a table of the parts of the system you would change, with the scale at which each stops fitting, the cost and the trigger. The rows of that table whose trigger falls inside the next twelve months are roadmap lines. The rows whose trigger falls later are the reason the technical-debt line has a budget at all: some of it will be spent on work you cannot name yet.

A reviewer who sees a debt line reads the roadmap as a plan made by a team that knows its own system. A reviewer who sees no debt line assumes the debt is paid out of the feature lines, and discounts every date accordingly. The investor-side page on assessing technical debt describes how that discount is applied.

How should the roadmap connect to the deck?

Line by line. Every product claim in the deck that describes something not yet shipped should be a row in the roadmap, with its quarter. Every roadmap row that ships something the deck sells should say which slide. A reviewer reads the two side by side, and the a16z data room guide of 25 August 2022 lists numbers inconsistent with the deck as the first red flag in a data room [3]. A date in the deck that the roadmap does not carry is the roadmap equivalent.

The same guide advises leaving detailed three-to-five-year projections out of the data room unless asked [3], and the engineering version of that advice is to keep the roadmap to twelve months. Beyond twelve months, the roadmap is a vision, and a vision belongs in the deck. A reviewer asked to assess a three-year technical plan can only say that it is a plan; a reviewer asked to assess a twelve-month plan can check it against capacity, history and money, and a plan that survives that check is worth more to the investor than a longer one that cannot be checked.

What does a roadmap look like that fails the review?

Four shapes fail most often, and each is fixable in an afternoon:

1. The wish list. Twenty features, no costs, no quarters, no dependencies. Fix: cut to the lines the money buys, cost each one, and order them.
2. The capacity fiction. Dates that assume a release rate the deploy log does not show. Fix: compute deployment frequency and change lead time for the last quarter, and plan at that rate plus whatever the new hires add after their ramp.
3. The maintenance-free future. A historical maintenance share of a third and a roadmap that shows none. Fix: carry the share forward as a standing line, or name the specific change that reduces it, with evidence.
4. The debt in hiding. Known problems on the data room index page and no roadmap line that addresses them. Fix: a debt line per quarter with a budget, referencing the known-problems list.

The roadmap goes in the roadmap folder of the engineering data room, next to the ticket export it is computed from. Put both in before the review starts, so that the reviewer's first reading of the plan is beside the history that supports it, and the one-sentence answer that accompanies them, per what a technical review asks for, can be as short as "the split is attached and the roadmap carries it forward".