The Roadmap Is a Lie: What to Build Instead

Every time I walk into a new engagement as a fractional CTO, I ask to see the roadmap. About a third of the time I get a Notion page that has not been updated in six months. A third of the time I get a Gantt chart that has been ceremonially maintained but bears no resemblance to what the team is actually working on. The remaining third, the founder gives me an honest shrug and says, "We do not really have one."

The interesting thing is that the third group is often the most functional. They have figured out something the other two have not yet admitted: the traditional 12-month engineering roadmap is a lie, and at seed stage, maintaining one is worse than not having one at all.

This article is about what to use instead. A lightweight planning artifact that survives contact with reality, gives the team direction, lets the founder communicate externally with confidence, and takes about 45 minutes per week to maintain.

Why traditional roadmaps fail at seed stage

The 12-month roadmap is a relic of a stage of company that seed-stage startups are not yet in. It assumes three things that are false in early-stage:

It assumes the work is predictable. At seed stage, you are learning what to build. The thing you think matters in month 4 is probably not the thing that will matter by the time you get there. A roadmap that promises specific features in specific months pretends otherwise, and when reality diverges (always), the roadmap becomes a source of confusion.

It assumes the team capacity is stable. A 3-engineer team plus a hiring search plus an incident at a big customer plus an unexpected dependency issue means the team has half its planned capacity for a month. The roadmap did not account for that. Reality does not care.

It assumes the customer is quiet. The roadmap was built based on one snapshot of customer feedback. Three months later, a single conversation with a whale customer reshuffles priorities, and the roadmap is instantly out of date. If you update it to reflect the new reality, you are admitting it was fake. If you do not, it becomes a parallel reality that everyone ignores.

The result is the same either way. The team stops looking at the roadmap because it does not describe what they are actually doing. The founder stops looking at it because it is wrong. The document becomes a prop for investor updates and nothing more.

What to use instead: the three-horizon plan

The artifact I use with clients is a single document I call the three-horizon plan. It is three sections, updated weekly, and answers three questions about what the team is building.

Horizon 1: This week. What is the team actively working on right now? This is the real backlog. It is specific, names tasks, and changes frequently. Think of it as the sprint, whether or not you call it that.

Horizon 2: Next month. What are the 3–5 things the team will probably work on over the next 4–6 weeks? This is intentionally fuzzy. It is a set of themes or initiatives, not a list of tasks. The point is to give the team enough context to make decisions about this week's work without over-committing to next month's.

Horizon 3: This quarter. What are the 2–3 big bets for the quarter? This is the strategic layer. It changes rarely — usually only when something significant shifts in the business. It is the level at which the founder communicates with investors and the team communicates with each other about priorities.

That is it. Three horizons, one page, updated once a week.

What each horizon looks like in practice

A concrete example from a client engagement (details changed).

Horizon 1: This week

Sarah is finishing the onboarding redesign and expects to ship Wednesday.
Marcus is debugging the billing webhook issue reported by Acme Co — top priority until resolved.
Priya is pairing with Marcus half the week and spending the rest on the Postgres migration prep.
Contractor is doing the Stripe tax integration, on track for Friday.

Horizon 2: Next 4–6 weeks

Ship the self-serve signup flow (the thing that unblocks the growth experiments).
Complete the Postgres schema migration so we can support multi-tenancy for the enterprise pipeline.
Reach "green" on the observability dashboard (error rate, latency SLO, uptime).
Stand up the first version of the AI feature PoC so sales has something to demo.

Horizon 3: This quarter

Move from self-serve hobbyist customers to the first 5 paying SMB customers.
Build the engineering foundations (observability, CI maturity, on-call rotation) to support a team of 6 instead of 3.
Validate whether the AI feature is a real wedge or a distraction.

Note how different each horizon feels. Week is operational. Month is thematic. Quarter is strategic. The three answer different questions, which is why you need all three.

How to maintain it (45 minutes per week)

The discipline of maintenance is more important than the format. Here is the weekly ritual I install at clients:

Friday afternoon, 30 minutes, solo. The CTO (or fractional CTO, or engineering lead) updates Horizon 1 based on what the team actually did this week. They skim Horizon 2 and adjust if the week's work revealed something. They only touch Horizon 3 if something strategic shifted.

Monday morning, 15 minutes, team. The team reads the updated plan at the start of the week's first meeting. Anyone can flag disagreement. The team's mental model for the week is aligned before anyone opens a pull request.

That is 45 minutes per week. Cheaper than any real roadmap tooling, and more accurate than any annual planning exercise.

How this maps to investor communication

The objection I get from founders is: "But my investors want a roadmap." They do. They also want an accurate one. The three-horizon plan is actually better investor material than a Gantt chart, because it communicates the level of specificity investors should actually be paying attention to.

In the monthly investor update, I recommend including Horizon 3 (the quarter's big bets) with a sentence of progress against each. That is what investors need to know. If they want more detail, they are free to ask, and you can show them Horizon 2. They almost never need Horizon 1.

Investors who insist on a 12-month feature roadmap at seed stage are either unfamiliar with early-stage operating realities or testing you. Either way, the three-horizon plan plus a confident explanation of why you run this way is a better answer than a Gantt chart you know is fake.

Handling the whale customer

A common failure mode of seed-stage roadmaps is the whale customer. One conversation with your biggest account changes everything, and the roadmap becomes either frozen in the old reality or completely rewritten around the new one.

The three-horizon plan handles this well. The whale's request goes into Horizon 2 if it is important and the team can make room, or into Horizon 3 if it is a strategic shift. Either way, it is visible and it is explicit. You do not have to pretend the previous plan is still in effect, and you do not have to redo a quarter's worth of planning.

The honest conversation with the team is: "Acme asked for X, it is worth doing because [reason], so we are moving Y out of this month's horizon and Z to next quarter. Here is what that does to the big bets." That conversation takes 20 minutes and the team understands what is happening. Contrast that with the old pattern, where Sarah quietly drops her previous work to chase the whale and nobody tells Marcus why his dependency just went missing.

What this does not replace

The three-horizon plan is a planning artifact, not a specification. It does not replace:

Design documents for specific features (write one-pagers before you build).
Architecture decision records for technical choices (short markdown files explaining why).
Customer research that drives what you choose to build in the first place.
Engineering metrics that tell you whether the team is healthy (DORA, cycle time, incidents).

Those are all real artifacts you still need. The three-horizon plan is the glue that ties them to what the team is actually doing week to week.

Counterpoint: some teams do need a roadmap

A caveat worth naming. If you are at a stage where you are selling to large enterprises who demand a committed feature roadmap as part of procurement, or if you are building a regulated product where rollout plans must be approved months in advance, or if you have 30+ engineers and need to coordinate across multiple squads, you probably do need a more traditional roadmap artifact. The three-horizon plan starts to feel too light at that scale.

The question is whether you are really at that stage, or whether you are cargo-culting the artifact because it feels more grown-up. Most seed-stage startups are not, and the answer is to stay light.

Your next step

This week, try the three-horizon plan as a straight replacement for whatever you currently use. Write the three horizons honestly — not aspirationally. Share it with your team on Monday. See whether the team feels better oriented at the end of the week.

After two weeks, evaluate. If the team is clearer on what to work on and the founder is clearer on what to say externally, keep it. If something is missing, adjust.

Where I come in

Setting up the three-horizon plan and the weekly ritual around it is one of the first things I do at new engagements. It usually takes about a week to establish, and the founder and the team feel the difference immediately. Book a call if your current roadmap is not actually describing what you are doing and you want help installing something better.