The SaaS Technical Roadmap: Planning 6 Months of Engineering With Confidence
Most SaaS technical roadmaps are dead by month two. The plan gets written in January, reality shows up in February, and by March the document is something people apologize for in the planning meeting. We see this often enough in client engagements to treat it as the default outcome, and it has a fixable cause: the typical roadmap is a wish list with dates attached, built without a capacity model and without written assumptions.
A SaaS technical roadmap that stays useful for six months is a different artifact. It starts from business outcomes instead of feature requests, and it treats engineering capacity as a budget that has to add up. What follows is the process we use with clients, template included.
Why the six month plan usually dies
The failure pattern is consistent. Someone collects feature requests from sales, support, and the founders. The list gets sorted by loudness, dates get attached, and the result looks like a plan. It is a queue. A queue does not know your team's capacity, and it cannot absorb the incident that eats three weeks of a quarter.
The document fails socially too. When engineering presents system language (migrate the billing service, introduce a message broker) to people who think in capabilities, stakeholders cannot argue about priorities. So they argue about dates instead, and that negotiation is where trust goes to die.
Start a SaaS technical roadmap from outcomes, not features
Begin with the company OKRs, or whatever passes for them in your organization. If the goal for the half year is to cut churn by 20 percent, the roadmap question becomes: which engineering initiatives move that number? Perhaps reliability work on the two features your heaviest users touch daily. Perhaps onboarding instrumentation, because right now nobody can say where trial users give up. Those initiatives have a reason to exist that survives scrutiny.
We run this as a mapping exercise. Every initiative points at one business outcome, and every outcome has at least one initiative pointed at it. An initiative that points at nothing either gets cut or has to defend itself as engineering health, which is a legitimate category with its own standing budget. In our experience the mapping kills about a third of the original wish list on the spot, which is the point.
Capacity planning: the arithmetic nobody wants to do
Six developers times six months is not 36 person months of feature work. Before committing to anything, subtract:
- Incidents, support escalations, and urgent customer requests. Take the percentage from your incident history, not from optimism. For most SaaS teams we see, it lands between 15 and 20 percent.
- A standing allocation for technical debt and maintenance, typically 20 percent. Skip the allocation and the debt collects it anyway, in the form of slowdowns and firefighting. A codebase health scorecard tells you whether 20 percent is enough for your situation.
- Hiring ramp-up, which is negative before it is positive. A developer who starts in month two costs senior review time through month four and contributes fully from month five at best. Booking a new hire at full capacity from day one is fiction.
- The ordinary overhead of meetings, reviews, holidays, and sick leave. Plan with 75 percent of nominal time before any of the deductions above.
Multiply it out and a six person team has roughly half of those 36 person months available for planned initiatives. Write that number at the top of the roadmap. Every prioritization conversation gets shorter once it is visible.
If the technical debt share is contested, and it usually is, an outside technical debt assessment settles the number faster than another round of internal debate.
Sizing initiatives: S, M, L, XL
We size roadmap items in T-shirt sizes on purpose. Story points at roadmap level suggest a precision that does not exist yet.
| Size | Calendar reality | What it means |
|---|---|---|
| S | Days up to 2 weeks | Known work in known code, one developer |
| M | 2 to 6 weeks | Some unknowns, up to two developers, no data model surprises expected |
| L | 6 to 12 weeks | Real unknowns, cross team touchpoints, or a live data migration |
| XL | A quarter or more | Too big to plan. Split before it enters the roadmap |
The argument about whether something is M or L is where the planning value lives, so we force it with a fixed set of questions. Does the initiative touch authentication, billing, or the core data model? Then it is at least M. Does it migrate live data? At least L. Does it depend on a third party shipping something first? Add a size and write a risk register entry. Can two people state the acceptance criteria and mean the same thing? If not, the initiative cannot be sized and goes back for definition.
An XL never enters the roadmap in one piece. Split it into an L that ships something observable and a follow-up that gets sized once the L has landed and taught you something.
Sequencing: fewer dependencies beats earlier starts
Four principles, in the order we apply them.
Schedule the initiatives with real unknowns early in the half year. Discovering in month five that an L was actually an XL leaves you no room to react.
One team, one initiative at a time. Two half finished initiatives are worth less than one shipped, and the context switching taxes both.
Keep two initiatives that touch the same subsystem out of the same time window, even across teams. Merge conflicts are the cheap part of that collision; the contested design decisions are the expensive part.
Make dependencies point backward. If initiative B needs the API from initiative A, then A finishes before B starts, with slack in between, and B's row in the roadmap names that dependency.
When sequencing keeps producing deadlocks no matter how you shuffle, the architecture is telling you something about coupling. We hold that conversation in tech stack strategy reviews, and it is much cheaper there than in production.
The risk register: what could invalidate this plan
Every roadmap stands on assumptions, so write them down next to it. A typical register from our engagements: the backend hire starts by March at the latest, the payment provider ships its announced API in Q2, the SOC 2 audit window does not move, nobody on the four person core team goes on extended leave. For each entry, note how likely it is to break and which initiatives fall with it.
Then price the risk in as buffer. We keep 20 percent of each quarter unallocated. When an assumption breaks, the impact has somewhere to go. When nothing breaks, the buffer absorbs the next initiative ahead of schedule, which makes for a pleasant review meeting for a change. The buffer is the response plan for the risk register, agreed on before anyone is stressed.
Present capabilities, not systems
The version of the roadmap that reaches the leadership meeting contains no subsystem names. Translate every row.
| System language | Capability language |
|---|---|
| Migrate billing to the new provider abstraction | Customers can pay by invoice and direct debit, not only by card |
| Introduce read replicas and query caching | Dashboards stay fast at ten times current data volume |
| Refactor the permissions module | Enterprise admins can define custom roles themselves |
This translation does real work. It lets non-technical stakeholders argue about priority, which is their job, without arguing about implementation, which is not. And when someone requests a new capability mid cycle, you can show in the same language what it would displace.
The monthly review that keeps it current
One meeting, 45 minutes, once a month, same agenda. Compare shipped against planned. Walk the risk register and mark each assumption as held or broken. Resize what remains if reality has moved. Record whatever scope entered from outside the roadmap, because something always does. The output is a short diff against last month, not a new document.
Version the roadmap like code. The January plan should remain readable under the March revisions, because the diff history is the honest record of how the half year went, and it is the best input you will have for planning the next one.
Two failure modes are worth naming. If the review turns into a status meeting, move status updates into writing and keep the meeting for decisions. If the review never changes anything, the roadmap is not being used between meetings; a plan that survives four months without a single revision was written too vaguely to be wrong.
The one page template we use with clients
One table, one row per initiative.
| Column | What goes in it |
|---|---|
| Initiative | Name, phrased in capability language |
| Outcome | The business goal or OKR it moves |
| Size | S, M or L. XL means split it first |
| Window | A target month range, never a date |
| Owner | One name, not a team name |
| Depends on | Risk register entries and other initiatives |
| Status | Planned, active, shipped, or dropped |
Below the table sit the capacity number, the buffer, and the risk register. Everything fits on one page. A roadmap that needs a slide deck will not be updated monthly, and a roadmap that is not updated is a historical document.
FAQ
How far ahead should a SaaS technical roadmap go?
Six months in initiative level detail, twelve months in themes. Anything beyond that is a direction, and pretending otherwise costs credibility. The monthly review sharpens the far end as it gets closer.
How much buffer does the plan need?
Our default is 20 percent per quarter, adjusted upward for teams with a heavy incident load or an audit on the calendar. Teams that consistently finish with unused buffer can trim it, though teams in that position are rare in our experience.
What is the difference between the roadmap and the backlog?
The backlog is everything you might do. The roadmap is the subset the team has capacity to do this half year, tied to outcomes, sized, and sequenced. If the two documents look similar, the roadmap step has not actually happened.
If you want a second pair of eyes on your next planning cycle, from the capacity math to the technical debt number it depends on, write to hello@wolf-tech.io with a short note on where planning hurts. More about how we work is at wolf-tech.io.