Most internal roadmaps are a list of components with quarters attached, and not one line names a person outside the platform team who is waiting for it. This is the blank board you fill in yourself: vision, problem inventory, now / next / later, published non-goals, and an adoption target with a named consuming team on every item.
The trap most platform teams walked into: write the roadmap as a list of technologies with quarters attached, so success means the service catalogue exists, publish no non-goals so every loud request lands somewhere on the board and nothing is ever refused, then report progress as percentage complete against a plan written nine months ago for an audience of one platform team.
What the platform teams who keep their funding do: name each item after the problem, the squad that has it and what it costs today, carry an adoption target with a date that a named team lead agreed to out loud, publish at least four refusals with what a team should do instead, and report progress as aware, tried, using, relying on.
A roadmap without non-goals is a wish list, because every request that arrives has to land somewhere. Refusals get their own table here, and the second column carries the weight: what a team should do instead. Refusing without an alternative is how platform groups earn the department-of-no reputation they then spend two years apologising for. Write at least four, and say them in the review.
Sixty percent adopted is a number nobody can act on. The template tracks four stages instead. Aware means the team knows it exists. Tried means it ran once in a real repo. Using means it is in the normal path for new work. Relying means they would raise an incident if it broke, and only that last stage protects a budget.
Now holds three items, and a fourth means one of the three is not really funded. Next carries no dates at all, because the entry condition is a slot opening in Now rather than a calendar month. Later is reviewed quarterly, and anything that has not moved twice running gets deleted. Quarters on the second and third columns are promises you will break.
Five columns: problem, whose pain, evidence, cost today, confidence. Evidence is a pipeline number, a ticket count, an incident, or a dated quote from a named engineer. Cost is hours a month, delayed releases or spend. A row with no evidence and no cost is a preference, and preferences do not get engineering quarters.
Any team can do the outcome in a stated time without the thing they hate. Name the time and name the thing. Then write the clause this vision is deliberately not about, the squads you are designing for, the squads who will adopt late, and the two numbers everything rolls up to.
Three items in Now, each with a named engineer, a named consuming team and an agreed adoption target. Next needs evidence already in the inventory and two teams sharing the problem. Later is watched, not planned. Then fill the non-goals table, four rows minimum, with the alternative in the second column.
Take the three items in Now to the named team lead and have them restate the target and the date. Record who agreed and when: 80% of Payments schema changes through preview environments by 30 September, agreed with Dana Okoye on 14 July. Anything that cannot survive that conversation comes off the board this week.
No, because of the entry conditions. Now holds three items with a named engineer, a named consuming team and an agreed adoption target with a date. Next requires evidence already in the inventory and two teams with the same problem. A backlog accepts everything and refuses nothing, which is the failure the non-goals table exists to fix.
Then it is not a roadmap item. Something no lead will commit to in front of their own team is a preference the platform group holds, and it belongs in Later or
in the non-goals table. That conversation is cheap this week and expensive after a launch nobody attends.
Give dates on Now only. Quarters on Next and Later are promises you will break, and each broken one costs you a consuming team. Offer the adoption funnel instead: teams at relying on, per capability, by date. That is a harder number to hit and a much easier one to defend in a budget round.
Two sessions and a week. The problem inventory needs a week of collecting evidence and two people can do it. The board and the non-goals take ninety minutes with the platform team and two consuming-team leads in the room. Getting the targets agreed out loud takes another week of short conversations.
VPs of platform and heads of DevEx who own an internal platform and a budget line. It assumes you already have a roadmap of some kind, most likely a component list with quarters attached, and a review coming where somebody asks which teams rely on what you shipped last year.
Drop your details and we'll send Zero Non-Goals On The Median Platform Roadmap. That Makes It A Wish List. straight to your inbox - no spam, unsubscribe anytime.
Secondary: Book a 30-minute roadmap review (logiciel.io)
Download the template