How should a product roadmap be written?

I’m a novice in the field of product management, and I’m responsible for writing the product roadmap. Can someone kindly give me some advice on how to proceed? To what extent are the details to be covered? It would be quite helpful if you could offer some templates.


I hate it when employers treat new PMs in this way. What are they genuinely hoping to accomplish with this?

What an absurd way to instruct someone, even as a thought exercise. “Go try something with no prior understanding about how to accomplish it or even where to begin.”

Here is a really high-level place to begin. Fill out each project (epic) with whatever pertinent information you may have based on the prioritized lists of projects your team hopes to complete over the course of the next six months or more, broken down by quarter. If your firm hasn’t already defined an epic, there should be some templates available online.


Isn’t researching and navigating through ambiguity the most important skills a PM should possess? A quick Google search should yield a wealth of information. The OP’s article here is another example of how to deal with uncertainty. Although I wouldn’t say it’s the best practise, a PM shouldn’t be surprised by it.


Personally, I think it’s becoming a profession-wide tendency to set individuals up for failure.

To behave as though we all had it figured out on Day 1 doesn’t augur well for the future of product management because we ALL had to start someplace.

Recent readers of this sub will see a growing trend of folks who are absolutely burned out and seeking new roles. Furthermore, there is a culture of PMs failing upward in our organisation. taking on a role and then, when they weren’t even successful in the first role, moving on to a better role as quickly as feasible. creating generations of PMs who are essentially just acting the part for about a year at a time.

Both of those issues, in my opinion, are brought on by the lack of training that occurs early in a PM’s career, which forces people to make decisions about their careers that will allow them to survive rather than thrive.

I agree that there should be some experience working with ambiguity, but to leave the OP in the dark and lead them on a wild goose chase in my opinion is just bull, and from having been in those situations numerous times, it only serves to reinforce a bad culture.


Product Roadmaps (the super-aspirational, beginning-of-year variety) are typically created by more senior members of the product organisation who don’t perform the daily work with the products. I find it exceedingly unlikely that an intern with almost no organisational context would be hired for this position.

Building a product plan is not the best thing to assign an intern; work on genuine, legitimate product features would be.


@LawrenceMartin, Actually, no. In many small or medium-sized businesses, each project manager can essentially establish their own plan (in negotiation with stakeholders and other teams).


@AhmadBashir, we are discussing different things, in my opinion. In either example, the OP failed to specify the parameters of the roadmap they are expected to complete. I still think that roadmap work is not good intern work. They should be assigned actual product work.


Normally, though, they’re aiming to train them. One must begin somewhere. On Google, there are a ton of resources. Actually, coming here to post before browsing the web is a pretty bad idea.


@JoelSchulman, no, not at all. Google will return a million different results, some of which may be utterly contradictory. The driving force behind this sub is real-world experience, thus having individuals give you advice and “watch out for” potential hurdles is priceless.


I don’t disagree, but don’t be scared to encourage beginners to get started. Doing things and getting exposed to the material so they can ask better questions is at the heart of all things.

Start here and keep digging.

Product Roadmaps : An Introduction

They’re a newbie. The best thing you can do is push to be self sufficient.


I won’t assign you the entire book, but The Build Trap does a great job of handling the topic.

There are roadmaps at all levels, from extremely detailed feature, component, or team level planning papers that lay out your plans for the upcoming few weeks to very broad strategic set of challenges.

The core of the roadmap is stating the challenges you want to address and the order in which you intend to do so. It’s intended to serve as a tool for gathering feedback on your comprehension of the product and what stakeholders want.

I like the now, next, later format personally.


@NathanEndicott, This. Determine the issues that must be resolved. Establish a priority. This should make it clear how to start creating a roadmap.

Read or watch Marty Cagan

Things that ought to come first in the roadmap Product Strategy and Vision.


@MarioRomero, For an intern project, hopefully the product vision and strategy already exist. Learning to nest your smaller strategy and plan inside of the broader intent is crucial for a junior PM.


A straightforward table with the columns now, later, and next is created. Then, depending on talks and research, I will add rows in accordance with what I have previously established to be the essential features or aims.

A dispute could be something like “resiliency” or the demands of a particular character that you must meet (my current project has about a dozen rows).

List the objectives you must accomplish in the near future in the “now” section. You may use “24x5 availability” or “99.999 uptime” to indicate resilience. Be selective and only include what is truly necessary. You might just require 8x5 if all users are in the same time zone and only access during business hours.

This matrix represents your theory or educated hunch regarding the route. To validate it, consult with as many diverse stakeholders as you can.

Work with your engineers to determine how long it will take to deliver the “now” column. Will it take one month? three months? your planned increment is that (PI). To complete this properly, you could require one or more focused days.

Now that your roadmap is publicly available, everyone may examine it and suggest improvements.

Bottom line: collaboration is more important than the item when trying to solve a problem.


So here are a few things to remember: As an intern, it is not your responsibility to create the road map. That is something that the leadership should seriously consider. Why isn’t the CEO, CPO, or product leader doing this? The reason I’d bring that up first is because the roadmap will serve as the company’s and the product’s direction, so it’s an intriguing decision to outsource it to someone who isn’t in a leadership role.

It’s crucial to clarify the expectations of the person who requested that you create a roadmap now. The phrase “roadmap” has different meanings for those who are involved with the product versus those who are not.

A roadmap should and always will convey the following:

  • What you want to achieve,

  • Why you’ve decided to concentrate on those areas.

  • For whom you are creating things.

  • How these elements fit into the goals of your business and products.

However, the phrase “roadmap” frequently refers to a timeline with start and finish dates for individuals who lack a thorough understanding of the product. A release strategy, not a roadmap, is what that is.

Define what they want to know and, more crucially, why they want to know it, I said above.

A roadmap is also based on the vision of the business and the product. The CEO or CPO should make sure you understand this. A product canvas should be completed alongside your product leader, whoever that may be, after doing some research on what one is. This will make it possible for you to create a roadmap based on choosing a course that will assist your team in realizing that vision.


@EvaRichardson, according to the audience, the roadmap must provide certain details. Many times, all that is required is a spreadsheet with a list of tasks prioritized.

The most important thing to keep in mind is to avoid making any concrete plans for the future. Sooner or later, your roadmap will be attacked by a grenade from business objectives and strategy.


Although the level of detail may change, the message is always the same. Saying that a roadmap is simply a list of things to do is risky since that is how feature factories are created. Above all, a plan should be flexible and dynamic.

The roadmap outlines the course that the business or product will take in order to realise its larger goal. Depending on who is seeing the roadmap, different information will be shared with them.

A release plan, which is a prioritized list of tasks that have been given the go-ahead, should be used in conjunction with a product manager’s roadmap, which is not the only document that exists for them.

Map = strategy: what, why, objectives, and results

Release plan: what, how, and when to execute


You can have roadmaps for features. For example, the iPhone Settings app can have its own roadmap that’s little more than a list of things. Communicating general direction isn’t a goal in that case.

If it’s a high-level product roadmap then yes, all those things you mentioned are important.

1 Like

A roadmap is intended to be high level.

A roadmap could include features. Yes, as long as you are aware of your intentions.

I want to ask you this: Would you understand exactly what it means if one of your goals for the iPhone settings was to improve user guidance and make the UI easier to use? No. You must first do a discovery to ascertain the issue. Therefore, even if certain things might already be features, not all problems are first properly characterised. Because of this, you ought to place less emphasis on “features” and more on first comprehending the issue. Why first, then why, then the remedy.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.