Changing to a new product roadmap at a brand new job might seem daunting.
As a product manager (PM), your responsibility is to maintain and help execute the best roadmap possible. 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’ll explore how you – as someone who just got hired after nailing a PM interview – can build a new roadmap at your new company with the team’s support.
1. Check pre-existing assumptions
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. Your first task is to check these assumptions and find out what they mean.
How to check assumptions in the roadmap
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’s 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 start making your own and tearing plans apart.
2. Find space to restart the roadmap
Restarting from a blank slate is a great tactic if the roadmap is chock-full of assumptions, junk, or no one agrees on it. Start fresh with new things you’re learning! But do so gently.
As for how to do this, check out some tips on how to admit roadmap bankruptcy.
You might need to help your new company break up with timelines and Gantt charts. 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 “project plan” – and that the new document is a real strategic roadmap. (You can reassure them that you’ll still need project plans!)
3. Rebuild the product roadmap
All of your conversations, other research, and what you’ve 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.
Rebuilding this product roadmap means establishing some other things within the team:
- Choose a prioritization model that suits your product and your team
- Choose a product backlog framework for all the items that don’t make it onto the roadmap
- Establish good backlog grooming practices to keep it organized!
Note: Don’t worry about leaving stuff off. People will probably notice something is missing and speak up. This gives you insight as to what’s really important. If something is that important, it will pop up again as a problem that you need to tackle.
4. Keep iterating and create buy-in
The new version of the roadmap you create should reflect the up-to-date understanding of the problems and the opportunities and the challenges ahead of you, and therefore should represent an up-to-date version of your product strategy.
The only way to get there is if you continuously have conversations with the different stakeholders and loop them in. The new roadmap might resonate with them immediately, but it probably won’t.
Think of this as your first draft of a prototype. It’s going to be a bit junk and people might have criticism. That’s good! Because what you’re actually doing is checking whether you’re on the right path or not. Get their feedback on the roadmap so far and keep iterating.
How to create buy-in
If you continuously have these conversations, you’ll help the team come around to the fact that they’re wasting less resources by not building the things that they thought were a good idea a year ago when they set the old roadmap. They’ll realize you’re actually preventing them from building stuff they didn’t want in the first place.
The other bonus is that when you present it back to people, they will feel as if this roadmap is theirs. And it is!
5. Re-introduce the roadmap
I’m not a fan of big reveals. Not only is there emotional tension built up around it, but also when multiple stakeholders are in the same space, you often stifle honest feedback. Outliers might not want to speak up in front of everyone, while other people might succumb to groupthink.
Plus, big reveals falsely give the impression that this roadmap is “your thing” that you’re presenting with full ownership.
Instead, keep it casual. You can even do several small reveals to smaller groups and some key individuals.
How to introduce the new roadmap
If you followed Step 4, this should actually be easy. When you’re ready to release the “official” new roadmap, everyone’s already seen it and feels invested. They know they helped with it, and again, it feels like it’s theirs.
You can say, “I’ve had all these conversations, and I understand that the problems to solve are X, Y, and Z. Based on what everyone has said, I think this is our roadmap.” Let them know it’s a first iteration, it can be added to and shaped, and that time estimates are never set in stone.
As you start using the new roadmap
Switch to a lean way of working. As the team finishes these projects, remind them that you won’t rush ahead to the next item on a list. Instead, you step back and revalidate the most pressing problem and the next best thing to build.
You can also begin looking at success.
Last word
Your job is not to create a new roadmap for a company by scrapping what they had before. That’s obnoxious and just bad product management.
PMs don’t have answers, we ask questions. We facilitate conversations, and we learn from them and reflect it back to them. We help the team find compromise, and then present the story that makes the most sense.
The post A New Job Means a New Roadmap appeared first on Product Management Software | ProdPad.
