{"id":78150,"date":"2023-08-22T14:25:42","date_gmt":"2023-08-22T13:25:42","guid":{"rendered":"https:\/\/www.prodpad.com\/?p=78150"},"modified":"2025-01-13T16:25:05","modified_gmt":"2025-01-13T16:25:05","slug":"a-new-job-means-creating-a-roadmap","status":"publish","type":"post","link":"https:\/\/www.prodpad.com\/blog\/a-new-job-means-creating-a-roadmap\/","title":{"rendered":"A New Job Means Creating a Roadmap"},"content":{"rendered":"\n

Changing to a brand-new new job and having to create a product roadmap<\/a> might seem daunting.

As a product manager (PM), your responsibility is to maintain and help execute the best roadmap possible<\/a>. When you join an existing team, this might mean completely throwing out or overhauling their existing roadmap.

Bold? Yes!
Necessary? Maybe.
Obnoxious? Not if you do it the right way.

In this post, we\u2019ll explore how you \u2013 as someone who just got hired after nailing a PM interview<\/a> \u2013 can create a product roadmap at your new company with the team\u2019s support.<\/p>\n\n\n

\n
\"Exploring<\/figure>\n<\/div>\n\n\n

Steps to take when creating a roadmap at your new job<\/h2>\n\n\n\n

1. Check pre-existing assumptions<\/h3>\n\n\n\n

So you just started a new job. Oftentimes, most of the time you’re adopting somebody else’s roadmap, which will be full of assumptions made by the PM and\/or the team at large. <\/strong>Your first task is to check these assumptions and find out what they mean.<\/p>\n\n\n\n

How to check assumptions in the roadmap<\/h4>\n\n\n\n

Have lots of conversations! Chat with everyone around you, especially all the key players, and get their read on what the roadmap is, learn who\u2019s had eyes on it thus far, and try to understand why they think certain things are on there.

You want to understand their understanding of the roadmap.

You also want to understand their understanding of the problems that need to be solved.

The key here is to not make assumptions about the roadmap yourself! Those assumptions have already been made. You want to find out why they’ve been made before you <\/em>start making your own and tearing plans apart.<\/p>\n\n\n\n

2. Find space to restart the roadmap<\/h3>\n\n\n\n

Restarting and creating a roadmap from a blank slate is a great tactic if the one you’re working with is chock-full of assumptions, junk, or no one agrees on it. Start fresh with new things you\u2019re learning! But do so gently.

As for how to do this, check out some tips on how to admit roadmap bankruptcy<\/a>.

You might need to help your new company break up with timelines and Gantt charts<\/a>. A great justification for restarting the roadmap is to move away from using deadlines and due dates.

You can explain that the old roadmap is more of a \u201cproject plan\u201d \u2013 and that the new document is a real strategic roadmap. (You can reassure them that you\u2019ll still need project plans!)<\/p>\n\n\n\n

3. Rebuild the product roadmap<\/h3>\n\n\n\n

All of your conversations, other research, and what you\u2019ve learned about the company objectives should help you identify what the real problems are that need to be solved. Now you start organizing them into a product roadmap everybody understands<\/a>.

Rebuilding this product roadmap means establishing some other things within the team:<\/p>\n\n\n\n