Roadmap for an engineering team: what to show and what to hide

Every other version of this roadmap is an exercise in taking fields off. This one isn’t. The squad is the audience the file was built for, and the starting position is that everything stays on until there’s a reason to remove it. There’s exactly one field worth removing, and it isn’t the one people expect.

Turn off Now, Next and Later

Stage exists to answer when for readers who aren’t shown the dates. That’s a real job on a leadership or customer view, where a quarter is too precise and silence is too vague. On a view with actual start and end dates on it, stage is a second answer to a question the first answer already handled, and a slower one, because somebody has to keep it in step with the dates by hand. Two fields answering one question is where a roadmap starts disagreeing with itself.

Turn it off in the engineering view and leave it in the file. The leadership view reads it from the same items.

Quarters hide the thing you’re planning

Exact start and end dates, not quarters. A quarter tells you two items happen between January and March. It doesn’t tell you they overlap for three weeks in February, and the overlap is the entire question: whether one person can take both, whether the contractor’s window is long enough, whether the January hire matters.

This is the point where a roadmap starts to resemble a schedule, and the line is worth being deliberate about. Roadmap vs project plan sets out the difference in revision rules — a roadmap is expected to change, a plan changes through a process. An engineering view sits closer to the plan end without becoming one, and what keeps it there’s item size.

Where does the roadmap stop and the tracker start?

The link field is the boundary. An item on the roadmap names a problem and points at the ticket or the spec where the work is decomposed. When the item has shrunk to something a pair could finish in a sprint, it belongs in the tracker and comes off the roadmap.

Get this wrong and you have two systems holding the same status, one of which is always stale. Keeping a roadmap up to date is the general form of that problem. The engineering-specific form is that developers update the tracker because their own work depends on it, and update the roadmap because you asked them to, and you can tell which is which by looking at the dates.

If the squad already thinks in columns, a kanban roadmap template is the closer fit than a timeline: it keeps blocked and shipped as places an item sits rather than fields somebody maintains, which is one fewer thing to keep in step with the tracker. Keep status on the roadmap at item level only, and let the ticket carry the detail. One place per fact.

Leave the owner cell empty when it’s empty

The gap is the useful part. An item with nobody against it in the quarter you’re planning is either unowned work or work you haven’t staffed, and both need saying out loud in the session. Filling the column in advance with whoever will probably end up doing it removes the signal and commits them without the conversation.

Dependencies stay on for a matching reason. Turning the arrows off tidies the picture and moves the discovery to standup two weeks later, at a higher price.

What the squad view owes everyone else

One set of items, several saved views. Hiding a field is a property of the view, not of the data: the value stays in the file, the leadership view still reads it, and anyone you send the file to gets all of it. That’s what makes what to include in a product roadmap a question you answer once rather than eight times.

It also means this view can be the maximal one without costing anybody else anything. Every other audience is a subtraction from what the squad already keeps, so the work of serving them is done the moment this view is complete.