The Living Roadmap

At some point after launch, every design system team has the same conversation.

Usually in a sprint review. Usually when someone from product asks why the new component isn't ready yet. Usually when the DS lead realizes they have been reacting to requests for six months and have not once decided proactively what the system should become.

I have worked in organizations where the funding cycle controlled the direction entirely. Every quarter, new priorities arrived from above. Design reacted to whatever got approved. Projects started, ran out of approved runway, and got put on hold half-built. There was no proactive design system roadmap because there was no stable direction to plan toward. The system grew in whatever direction the budget was pointing that quarter.

Half-built systems are not a resourcing problem. They are a direction problem. And a direction problem cannot be solved with more sprints.

This is the moment a design system stops being a project and needs to start being a product. Most teams miss it entirely.

What a Roadmap Actually Does

A product roadmap is not a feature list. It is not a backlog. It is not a Notion database of component requests sorted by number of upvotes.

A roadmap is a statement of intent. It says: this is what we believe the system needs to become, in this order, for these reasons. It gives every stakeholder a surface to disagree with — which is exactly the point. Because a design system without a roadmap has no surface for disagreement. It just has a list of things that got built.

A list of things that got built is not a strategy. It is a changelog with better branding.

It forces prioritization. It creates a record of decisions. And it gives the system a defense before anyone questions its existence.

A design system without a roadmap is not a product. It is a service with no SLA and no way to say no.

Why Most DS Roadmaps Fail Before They Start

Most design system teams build a roadmap once. In a planning session. With good intentions and a shared Figma file.

Three months later the roadmap is out of date. Six months later it contradicts the actual work being done. A year later it exists in a page nobody has opened since the planning session that produced it.

The planning session was good. The roadmap just wasn't connected to anything that moved.

I have watched an organization restructure around a design system roadmap that had been built with genuine care. People moved into different roles. The person who owned the roadmap was reassigned. There was no handoff. Not a bad one — no handoff at all. The document existed. The context behind every decision in it left with the person who made them. Six months later, nobody could explain why certain priorities were sequenced the way they were, because the only person who knew was now managing a different team entirely.

A roadmap that lives in one person's head is not a roadmap. It is a plan with a single point of failure.

Reason 1 — They Are Output-Oriented, Not Outcome-Oriented

"Q3: Button variants. Q4: Data table. Q1: Form system." This is a component list, not a roadmap. It tells no one why these components matter, what problem they solve, or how success will be measured.

An outcome-oriented roadmap says: "Q3: Reduce time-to-implement for new product squads by 40% through form system coverage." The Button variants might still be on the list. But now they are in service of something.

Reason 2 — They Are Not Connected to Engineering Planning Cycles

A design system roadmap that doesn't align with engineering sprint planning is a document, not a commitment. Engineering adopts what they helped plan. They tolerate what appears fully formed in their Slack channel on a Monday morning.

The difference between adoption and tolerance is where the conversation started.

Reason 3 — They Have No Owner

Every product has a product manager. Design systems usually have a designer who also does roadmap work between component requests. That is not the same thing.

A roadmap without an owner is a document with a last-edited timestamp. The timestamp moves. The roadmap doesn't.

How to Build a Roadmap That Stays Alive

Four components. In this order.

Component 1 — The Now / Next / Later Framework

Stop using quarterly dates. Dates create false precision and immediate obsolescence. Use three horizons instead: Now (in active development), Next (committed for the next planning cycle), Later (directional, not committed).

Each item in the roadmap gets: the outcome it serves, the user group it benefits, and the success metric that confirms it worked. Three fields. Nothing else is required.

Component 2 — The Request Intake Process

Every design system needs a public way to submit requests and a transparent way to see what happens to them. Without this, every stakeholder assumes their request is lost. And they follow up. Constantly.

The follow-up is not the problem. The absence of a visible process is the problem. The follow-up is just the symptom.

Component 3 — The Quarterly Review

Once per quarter: review adoption metrics, review open requests, update the roadmap. Make it a standing meeting with engineering and product representation. Not a design system team meeting. A cross-functional review.

The review is what makes the roadmap living. Without the review, the roadmap is just a document.

Component 4 — The Deprecation Policy

A roadmap that only adds things is a roadmap that will eventually collapse under its own weight. Every design system needs an explicit deprecation policy: how components are retired, how migration is communicated, and how long legacy versions are supported.

Deprecation is a product decision. It belongs in the roadmap, not in a Slack message sent the day before the change ships.

The Quick Win: A One-Page Roadmap

This week: take your current backlog and sort every item into three columns. Now. Next. Later.

For each item in the Now column, write one sentence that answers: what outcome does this serve?

Share it with your engineering lead. Ask them:

"Does this match what you understand the system to be working on?"

The gap between your answer and theirs is your alignment problem. The roadmap just made it visible.

The Argument

A design system that cannot tell you what it will become in six months is a design system that cannot defend what it is today. The roadmap is not a planning artifact. It is a survival document.

Disagree loudly. Inspire boldly.

And remind me — falsely if needed — that somewhere a design system roadmap exists and engineering has actually read it.

Does your design system have a roadmap — or a backlog you call a roadmap?