Roadmaps that survive contact

The roadmap as a document format was built for a world where changing your mind was expensive.

Shipping something took eight months of committed engineering time. So you needed a plan you could defend against every new request arriving mid-quarter, and you needed dates, because dates were the only thing that let you say no to the fifth person asking why their thing wasn't on it yet.

That world produced the Gantt chart. Rows, bars, dates on everything, a document whose entire job is answering one question.

Did it ship on time.

Answerable. Almost useless.

A team can hit every date, ship exactly what was planned, exactly when it was planned, and still have built nothing anybody wanted.

The format has no room for that outcome. It was never designed to measure whether the work mattered. Only whether the work happened.

Track only "did it ship" and you'll eventually manage a team that's excellent at shipping and has no idea whether any of it worked.

Three horizons, one honest document

Now, Next, Later fixes this by matching detail to certainty.

Rather than pretending you have the same certainty about everything on the page.

Now is committed, scoped, in flight or about to be.

It earns a date, because you've done the work to know the date is real. It earns specifics, because the ambiguity is already resolved.

And if something in Now has no date, that's a signal. Not a gap to fill with a guess.

Next is direction without a date.

You know roughly what problem you're solving, and roughly why it beats the other candidates. You haven't scoped it, and scoping before you need to is wasted work you'll redo when circumstances change. Which they will.

Giving Next items a date is the single most common way roadmaps lose credibility. That date gets read as a promise by everyone who sees it, then missed, because it was never real.

Later is a bet, not a plan. It might not happen.

Writing it down at all says it's on your radar, worth naming, worth a rough outline, and genuinely uncertain whether it survives contact with what you learn between now and then.

Later items dressed up with target quarters are lies with better formatting.

None of it works if rows are all you publish.

A row tells you what. It doesn't tell you why this is Next and not Now, or what would have to become true for a Later bet to move up.

Publish the reasoning beside the row. Even one sentence.

Now the roadmap stops being a list of promises. It becomes a record of judgment your team can be questioned on, argued with, and trusted because of rather than despite.

The date that isn't earned yet

Somebody senior will ask for a firm date on a Later item.

Not a hostile act. Usually it's a person with their own commitments to make upstream, and a roadmap that hedges reads to them like a team that hasn't done its homework.

The instinct to hand over a date and end the conversation is the instinct that destroys the format. The moment one Later item gets a date to keep the peace, every future refusal reads as inconsistency rather than principle.

Answer the actual question underneath the request instead.

They don't want a date. They want to know whether they can rely on this in a way that lets them plan.

So tell them what would have to happen for the bet to firm up. What you're watching. When you'll know more.

That's a real answer. A fabricated date isn't, and it comes due exactly when you can least afford it.

The roadmap only tells you what you intend.

Whether any of it was worth doing lives somewhere else.

In a changelog, paired with a short note on what you learned once the thing actually shipped and people had used it for a while.

Not "launched feature X." What happened after. Did usage move. Did the problem it was meant to solve actually go away. Did you learn something that should change what's in Next.

Without that pairing, a roadmap can only ever prove your team is busy. With it, you get the other half of the sentence.