What to Put in a Public Roadmap for Your Project

If you are wondering what to put in a public roadmap for your project, start with a simple rule: write down what you plan to do, why, and how sure you are. Everything else is decoration. A roadmap is a promise with a confidence level attached, and users read it that way whether you mean it or not.

This guide walks through the parts a roadmap needs, two formats to choose from, how to word each item, what to keep out, and how to keep the page honest over time. It ends with a worked example you can copy.

Why a public roadmap is worth building

A roadmap answers questions before people ask them. "Is this project alive?" "Will it ever do X?" "Should I build on it or wait?" Without a page that answers these, users guess, and guesses tend to be pessimistic.

It also helps you. Writing the plan down forces you to rank things. If you cannot say why item three comes before item four, you have found a decision you have not made yet.

A roadmap is not a changelog and not a wish list. A changelog is what already happened. A wish list is everything anyone asked for. A roadmap is the short list of what you intend to do, in a rough order.

What to put in a public roadmap for your project: the essentials

Keep each entry small. For every item, include these parts:

A plain name. Use the words a user would use, not your internal code name.
The problem it solves. One sentence on what is hard or missing today.
A status. Planned, in progress, or shipped. Three states are enough.
A time signal. A quarter, a season, or a bucket such as "next". Not a precise day unless you control it fully.
A confidence note. Say whether this is firm or exploratory.

Add a short intro at the top. Say what the project is for, who the roadmap is written for, and when you last reviewed it. If you have not written a project description yet, how to write an about page for your project covers the context a roadmap sits inside.

Choose a format: now, next, later vs dated timeline

Now, next, later

This is the safer format for most small projects. You sort items into three buckets:

Now: work that is under way.
Next: work you have committed to start once "now" clears.
Later: ideas you want to do but have not scheduled.

It shows order without making date promises. If a "now" item slips, nothing on the page is wrong.

Dated timeline

A timeline with quarters or months suits projects with outside deadlines, such as a compliance change, a deprecation or a coordinated release. It gives users something to plan around. The cost is that every missed date is visible.

If you use dates, keep them coarse. "Q1" is easier to keep than "14 January". You can also mix the formats: use dates for the next quarter and buckets for everything after.

Pick the one you can maintain. A simple roadmap that is current beats a detailed one that is stale.

How to describe items so users understand them

Write from the user's side. Compare these two lines:

Refactor the sync engine to use the new queue.

Faster sync. Large projects currently take a long time to update. We are changing how changes are queued so they finish sooner.

The second says what changes for the reader. The internal detail can stay in your issue tracker.

A reliable pattern for each item is:

Name it in user terms.
State the current pain in one sentence.
State the intended result in one sentence.
Give the status and time signal.

If you are unsure why an item matters, run it through a root-cause check before you list it. 5 whys or fishbone: which one to use for your problem helps you tell whether you are fixing the real problem or a symptom.

What to leave out of a public roadmap

Every request. Keep the full backlog elsewhere. A roadmap with 80 items says nothing about priority.
Vague slogans. "Improve performance" and "better UX" give users nothing to hold you to or to plan around.
Internal tasks. Dependency upgrades and cleanup matter, but list them only if users will feel the result.
Unconfirmed commitments. If a partner, a funder or a legal review has not agreed, do not list the item as planned. Put it under "exploring" or leave it off.
Security-sensitive detail. Do not describe an unfixed weakness in a way that helps an attacker.
Dates you do not control. If a release depends on someone else, say so instead of naming a day.

How to collect feedback and show what shipped

A roadmap that only talks is half a roadmap. Give readers a way to respond, and show them you listened.

Collect feedback. Tell readers one place to send input, such as your issue tracker or a contact address. Ask a specific question next to uncertain items, for example: "Do you need export as CSV, or is JSON enough?" Specific questions get useful answers.

Show what shipped. When an item is done, mark it shipped and link to the release note. Keep shipped items visible for a while. A visible run of finished work is the best evidence that the plan is real.

Explain what you dropped. If you cancel an item, say so and give a short reason. People forgive a dropped item far more readily than a silent one.

If you want a trail of context, write a short article for each major item when it ships: what the problem was, what you chose, and what you left out. Over time those articles become a record of how the project thinks. That is one way to build knowledge around a topic on Electrified, and the topics page shows what other writers file their posts under.

Keep your roadmap current and honest

A stale roadmap does more harm than none. Set a review rhythm you can keep, such as the first week of each month or each quarter, and put the review date at the top of the page.

At each review, do four things:

Move finished items to shipped.
Move slipped items back and say that they slipped.
Remove items you no longer plan to do.
Add at most one or two new items, with the same fields as the rest.

Use plain verbs. "We plan to", "we are working on" and "we are not sure" are all honest. "Coming soon" tells the reader nothing.

Be careful with strong claims. Do not write that something "will" ship unless you would be comfortable being held to it. Hedge with "plan" and "aim" where the outcome depends on things outside your control.

A worked example

Here is a short roadmap for an imagined note-taking tool, in the now, next, later format. Last reviewed: October 2026.

Now: Faster search. Search is slow on large collections. We are changing how notes are indexed. Status: in progress. Confidence: firm.
Next: Export as Markdown. You cannot take your notes out in a plain format. We plan to add export. Status: planned for next quarter. Confidence: firm.
Later: Shared collections. Teams cannot work in one collection. We are exploring it. Status: not scheduled. Confidence: exploratory. Question for readers: how many people share one collection?
Shipped: Dark theme. Added last month. See the release note.
Dropped: Mobile widget. We decided against it because the maintenance cost was too high for the number of requests.

That is five lines, and a reader knows what is happening, what is not, and where to weigh in.

Frequently asked questions

How many items should a public roadmap have?

Aim for a handful per bucket. If you cannot hold the whole page in your head, trim it, and keep the long backlog somewhere else.

Should I put dates on my roadmap?

Only if you can keep them or an outside deadline requires them. Otherwise use now, next and later, or coarse periods such as a quarter.

How often should I update a public roadmap?

Review it on a fixed schedule, such as monthly or quarterly, and show the last review date at the top. Update it sooner if a major item slips or is dropped.

What if I miss something I listed?

Say so on the page, give a short reason and give a new time signal if you have one. Visible honesty costs less trust than silence.

Get started with your roadmap on Electrified

You can publish your roadmap as an article on Electrified. In the editor, choose Article, add a title, and start each section with ## and a heading. Lists, quotes and links work as the formatting hint shows, and the Preview tab shows the page as it will look. Save a draft first: only you can see it until you publish it.

You can add up to 5 topics of your own choosing, and each topic links to a page of every post about it. When an item ships, write a short follow-up article, and your page keeps the run together. Readers can follow you, like and comment on published posts, and pick up your posts through your own Atom feed at /@handle/feed.xml. Links in posts may carry a rel value of nofollow, so write for readers, not for search credit. If you want ideas for promoting your work honestly, see the promote your work topic.

Make an account on Electrified: write about your product, topic or idea on your own page, one article at a time, and let readers follow along.