How to create a product roadmap from scratch

A blank roadmap is one of the more intimidating documents in product management. There's no data on the page yet, no obvious starting point, and a nagging sense that whatever you build first will set the template for everything after it. It doesn't need to be complicated. Here's a practical, step-by-step way to create a product roadmap from nothing, covering structure, statuses, what belongs on it and how to keep it fed once it's live.

Step 1: pick your format before you pick your tool

Before opening any software, decide on the shape of the thing. Most working roadmaps use one of two formats: a timeline with dates, or a status board with columns like Planned, In Progress and Shipped. Timelines look precise but need constant rework as dates shift. Status boards are less precise but far easier to keep accurate, since a label like 'In Progress' stays true whether the work takes two weeks or two months. For a first roadmap, especially a public one, a status board is almost always the better starting point. You can always add a rough time horizon later once you've proven you can keep the board itself updated. Deciding this early saves a lot of back and forth, because the format you choose shapes almost every decision that follows, from what software you need to how you word each item.

How to handle competing priorities early on

Even a brand new roadmap has to deal with competing demands. Sales wants a feature that helps close one big deal. Support wants a fix for the issue generating the most tickets. Engineering wants time to pay down technical debt that slows everything else down. There's no formula that resolves this cleanly, but a public vote count gives you a shared, visible reference point everyone can argue from, rather than each team quietly assuming their priority is the obvious one. It won't remove the disagreement entirely, but it moves the conversation from opinion to evidence, which tends to be a shorter conversation.

Step 2: choose three statuses and stick to them

Resist the urge to add more than three statuses. Planned, In Progress and Shipped cover almost every situation a product team faces, and each one has a clear, testable definition for whether an item belongs there.

Step 3: decide what goes on the roadmap and what doesn't

A roadmap that lists everything the team has ever discussed stops being useful. Being deliberate about scope is what keeps it trustworthy.

• Include features and improvements with real, demonstrated demand
• Include work the team has actually accepted, not just floated in a meeting
• Include a short, plain-language description for each item
• Exclude speculative ideas that haven't been through any kind of review
• Exclude internal engineering work like migrations or refactors, unless it visibly affects customers
• Exclude anything you wouldn't be comfortable being asked about again in three months

Step 4: feed it from real votes, not guesses

The single biggest difference between a roadmap that stays useful and one that quietly dies is where its items come from. Roadmaps built from internal opinion drift toward whoever argues loudest in planning meetings. Roadmaps built from a public feedback board reflect what users actually ask for, repeatedly, in their own words. Research from the Nielsen Norman Group on discovery methods makes a similar point about product decisions generally: structured, ongoing input beats occasional, informal conversations. If you don't already have a way to collect that input, start with our guide on how to collect customer feedback before you write a single roadmap item.

Step 5: write each item in plain language

Every item on the roadmap should be readable by someone who has never used your product. Avoid ticket numbers, internal codenames and engineering jargon. 'Add CSV export for reports' is a roadmap item. 'REPORT-482: async export pipeline' is not. This isn't just good manners, it's practical: a roadmap item that needs translating loses most of its value as a communication tool. The same plain-language instinct sits behind the W3C's guidance on accessible writing, which recommends short sentences and familiar words for exactly this reason, so that the widest possible audience can follow along without extra effort.

Step 6: set a review cadence

A roadmap without a review schedule decays the same way a garden does without watering, slowly, and then all at once. Put a recurring slot on the calendar, weekly for a fast-moving team, fortnightly for a smaller one, and use it to move at least one item forward. This doesn't need to be a long meeting. Fifteen minutes checking which items should change status is usually enough. The habit matters more than the length. Attach the review to something that already happens, like the end of a sprint planning session, rather than creating a brand new meeting that's the first thing to get skipped when the week gets busy.

Step 7: publish it somewhere public

A roadmap that only the product team can see can't build trust with customers or reduce support questions. Host it on a page that needs no login, loads quickly, and can be shared in a support reply or a welcome email. Our guide on building a public roadmap covers the setup in detail, including where to draw the line between what's public and what stays internal. Feedlark's roadmap is free to publish; the Pro plan is only needed if you want a custom domain or private boards.

Step 8: close the loop every time you ship

The step teams most often skip is the simplest one: telling people when something they asked for is done. Move the item to Shipped, publish a short changelog entry, and notify everyone who voted for it. HubSpot's service research reflects a pattern that shows up across industries: customers who feel their feedback led somewhere are far more likely to stay engaged. Our guide on how to write a changelog covers a format that takes minutes, not hours, to keep current.

A short anecdote: building one in an afternoon

A five-person team we spoke with put off building a roadmap for over a year, worried it would turn into a big project. When they finally sat down to do it, the whole first version took under three hours. They exported forty support tickets and feature requests into a spreadsheet, grouped the repeats, sorted them into Planned, In Progress and Shipped, and published the result on a single page linked from their help centre. The hardest part, by their own account, wasn't the roadmap itself. It was trusting that three plain columns really were enough, after a year of assuming they'd need something far more elaborate.

Common mistakes when building your first roadmap

• Trying to plan a full year in detail before publishing anything at all
• Adding a status for every possible edge case instead of sticking to three
• Copying internal ticket titles straight onto the public roadmap
• Forgetting to link roadmap items back to the feature requests that inspired them
• Treating the launch as finished, rather than as the start of a review habit

“We spent longer debating the name of the third column than we did building the actual roadmap. In hindsight, any of the options would have worked fine.”

— Founder, six-person productivity app