Tech roadmap
Building a technical plan the leadership will approve
1 to 2-day training for tech leads, senior devs and fractional CTOs: turn a list of technical projects into an arbitrated, funded, and delivered trajectory.
The symptom
"So where are our features in all this?"
You spent two weekends on it. The document is clean. Twelve projects, six quarters, it's all there: the version upgrade, the auth rewrite, observability, breaking up the monolith, rebuilding test coverage.
You present it to the leadership meeting. The CEO scrolls through, stops, and asks one question: "So where are our features in all this?"
The discussion is over. Your document goes into a shared folder nobody will ever open.
What actually happened is you built a parallel roadmap. Two plans competing for the same team capacity, and between the two, the one that generates revenue always wins. The leader doesn't look down on the technical side. Nobody showed them what your plan would earn them.
The cost of inaction
What it's actually costing you
Your plan is useless.
A document nobody uses to make decisions stays a wish list with nice formatting.
Technical prioritization happens anyway, without you.
By default, it happens by urgency: whatever broke last night, whatever annoyed a client, whatever's blocking Friday's demo. You end up living with a priority order nobody chose.
You can't say no.
Turning down a request with no plan to counter it with makes you look like someone protecting their own comfort. With a validated plan behind you, the same refusal becomes a reminder of a commitment already made.
You're always reacting.
Technical investments only get funded after an incident, once the cost has already been paid. It's the most expensive way to operate there is.
You lose credibility at every deadline.
Because a technical roadmap built on dates instead of horizons proves wrong within three weeks, and you're the one left carrying that.
What changes
What you gain
A technical trajectory that lives inside the product roadmap.
It stops being a competitor and becomes a condition of what the product wants to do.
The right to say no.
A plan approved by the leader turns every later trade-off into a short conversation, referred back to a decision already made together.
Getting ahead of things.
You address issues six months before they become incidents, which costs a fraction of the price and wakes nobody up at night.
Commitments you actually keep.
A way of estimating and communicating uncertainty that lets you commit without lying, and stay credible next quarter.
A recurring meeting with the decision-maker.
The roadmap becomes the vehicle for a regular conversation about the technical side, which is worth far more than the document itself.
Profile
Who it's for
Tech leads, senior developers taking on scoping responsibility, architects, freelance CTOs and fractional CTOs. Also useful for employed CTOs at young companies building their first technical plan.
You need real development experience and to be working in a context where there's a product roadmap, a leader or client to convince, and limited team capacity to allocate.
This isn't for you if
you're looking for a project planning method, a portfolio management tool, or program management. Here, we work on the content of the trajectory, its justification, and how to defend it.
The method
The main steps
What a tech roadmap actually needs to produce
Its function is to trigger and document decisions, well before announcing dates. We start by separating the execution plan, which belongs to the team, from the trajectory, which belongs to the conversation with the leader. Confusing the two is the most common and most costly mistake.
Where the content actually comes from
A credible technical roadmap doesn't come from the team's frustrations. It's built from identifiable sources: the product ambitions for the next twelve months, debt threatening delivery capacity, upcoming load thresholds, security and compliance obligations, team evolution, tooling. We work through gathering and weighing these sources.
Sequencing by horizons rather than dates
What gets secured now, what gets prepared next, what stays on the radar for later. A horizon holds up, a date nine months out proves wrong. We work on granularity, which should be fine-grained for the near horizon and deliberately coarse beyond it, and how to explain that asymmetry to someone expecting a schedule.
Estimating without lying
How to give a defensible order of magnitude, how to express uncertainty without hiding behind it, and how to handle the moment you're asked for a firm number on something nobody has ever done before. A roadmap's credibility is decided entirely here.
Making it readable and defending it
Translating every project into what it unlocks for the business: a shorter delay, a risk lifted, a ceiling pushed back, a more autonomous team. Building the one-page version the leader can read alone. And presenting options with a recommendation rather than a request for approval.
Keeping it alive
A roadmap that isn't revisited becomes a lie within three months. We set up the review ritual, the signals that should trigger an off-cycle re-arbitration, and how to make visible what's been done, what's shifted, and why.
Putting it into practice
The training's exercise
Starting from a complete client context, business ambitions, state of the codebase, team composition and budget constraints, you build a technical trajectory across three horizons.
Then you defend it in ten minutes in front of a leader played by another participant, with their objections, their cash-flow constraints, and their obsession with the release date.
The group's feedback focuses on readability, the level of jargon, how solid the estimates are, and the ability to drive a decision rather than get a vague agreement in principle.
Deliverables
What you leave with
Pricing
Format and pricing
1 day
€900 excl. VAT
The essentials: the sources, sequencing by horizons, estimation, and making it readable.
2 days
€1,800 excl. VAT
An extra day devoted to participants' real cases, building their own roadmap for their current context, a leadership-defense simulation, and working through objections.
Deliberately practical teaching: short inputs, progressively building a complete roadmap, role-play with a leader across the table, and group feedback.
The training costs the equivalent of one day of development. A properly oriented team-quarter is worth dozens of days.
Frequently asked questions
Questions we get asked
"Here are the twelve technical projects for the next eighteen months."
"To hit the H1 targets, three things need to be secured now. Two more get prepared next, and I'll tell you in January whether they're still relevant. There's one decision for you to make this quarter, on authentication, and here are the two options."
The same technical work behind it. A leader who decides, instead of a leader who postpones.