Roadmap for new joiners: what to show and what to hide

Every other audience in this family reads the roadmap to make a decision. A new joiner reads it to work out how the place fits together, and that single difference inverts most of the field list. The fields you hide from a board carry the most value here, and the field nearly every other view keeps is the one to turn off.

Owner is the point, not a risk

On every other view a name converts a discussion about work into a discussion about a person. Here it does something else entirely: it’s a directory. A new joiner’s real problem in week one isn’t knowing what is being built. It isn’t knowing who to ask about any of it, and that ordinarily takes about six weeks to assemble by accident.

An owner column collapses that to an afternoon. Same field, opposite call, because this reader has no standing to hold anybody accountable and no reason to want to.

Notes carry the part nobody writes down twice

Leave notes on, including the messy ones. The reason a decision went the way it did is exactly what a new joiner is short of, and an item without it’s trivia to be memorised and later misquoted in a meeting.

This runs against the usual advice, and deliberately. What to include in a product roadmap is right that effort estimates and ticket numbers fail the test on nearly every view. The onboarding view is the exception worth making, because its reader is trying to reconstruct two years of reasoning rather than approve the next quarter.

Leave the shipped work in

Start the window two quarters back, not at the current one. The product looks the way it does because of decisions already made, and a plan that begins today explains none of them. A new joiner who can see what shipped last spring understands why this spring’s work is shaped the way it is, and asks better questions in their first month as a result.

Status stays on for the same reason. It shows where the work actually is, so the first question is about something live instead of something that finished before they arrived.

A now next later roadmap template reads most clearly cold, which is the whole requirement here: its columns say what the team is choosing between instead of when things happen, and a reader with no history of the team’s estimates has nothing to misread.

Dates come off, and so do the arrows

A new joiner can’t tell a confident date from a placeholder. They have no history with the team’s estimates and no sense of which quarters have slipped before. So they repeat whichever one they read, and week three is when that lands in front of a customer. Quarters and stage, yes. Exact dates, no, for a reader whose judgement about them hasn’t formed yet.

Dependency arrows come off too, and the reason is worth saying because it isn’t obvious. To somebody who doesn’t yet know the systems, an arrow between two items reads as a fact about the architecture, and it gets memorised as one. Six months later you’re correcting a belief that came from a view you built to help.

It’s also where the roadmap gets confused with a schedule, which is a distinction worth handing over early — roadmap vs project plan is the short version, and a new joiner who has read it stops asking why the roadmap has no critical path.

What is the roadmap not doing?

It isn’t the onboarding. It answers what the team is working on, roughly when, and who to ask, which is more than most handovers manage and much less than a month of conversations.

Hand over the file as well as the picture. The roadmap json format is plain JSON, so somebody new can open it, read it and poke at it without asking anybody’s permission — which, in a first fortnight spent asking permission for everything, is worth more than the fields on it.