Product managers can find inspiration for their products everywhere, and that’s great. But those inspired ideas can’t go straight onto the roadmap. A product manager first needs to subject a new concept to a process that involves making the case. For example, they can do this through research and weighing the idea against other items already on the roadmap. And perhaps most importantly, before you add or remove anything, you should gain leadership consensus.
As someone who has worked for years as both a product manager and a product leader, I can tell you this from firsthand experience (some of it learned the hard way). Do not let your product leader see any of the following on your roadmap.
Don’t make your product leader ask, “What’s this?”
Let’s say you’re working on a mobile app, and someone in your office mentions that connecting more deeply with Facebook would increase app engagement with specific segments of your user base.
That sounds like a great idea. And we all know how thrilling a product manager can find discovering an excellent idea for their product. (It’s one of the best things about this job.) Also, let’s assume you trust the judgment of the person who suggested it—a sales manager or a product manager who handles a different suite of apps. So, you immediately add “Implement Facebook Integrations” to the roadmap.
Then your product leader sees it and says, “Huh?”
It would have helped to discuss this with your team, including your product leader before the integration epic appeared on your roadmap.
Worse, you didn’t subject the idea to the full vetting before adding it to the strategic timeline. When your product leader asked about it, you weren’t ready with the answers to all the necessary follow-up questions, such as:
- Which persona will these integrations resonate with, and why?
- What will the anticipated increases in engagement do for the bottom line?
- How are we going to measure success with this initiative?
A great idea alone can’t earn a spot on a product roadmap. Only great, vetted, and agreed-upon ideas can.
2. Items that raise more questions than they answer
Don’t make your product leader ask, “How is this going to work?”
Now imagine that for a different item you’re adding to the roadmap, you’ve cleared the first hurdle above. You shared the idea with your product leader and the rest of the team, and it won’t take them entirely by surprise when they see it on the roadmap. Heck, the team may even agree in principle that the idea had merit.
And now you’re thinking: Everyone sounded enthusiastic about this idea. Why not give it a slot on the roadmap right away? So, that’s what you do.
Then your product leader sees the initiative on the roadmap and says, “Wait. Did we all agree on this? Does our development team have the expertise to build it? Have they agreed to the timeline I see here? Did we get the budget?”
Again, you’ve created friction with your team by short-circuiting the process of building alignment. You’ve also undermined your product leader’s trust in your judgment and your ability to guide the team successfully through development.
If I saw an initiative suddenly appear on one of my product managers’ roadmaps—and it raised more questions than it answered—here’s what I would be thinking: If I can’t count on you to gain team alignment around a new item before you slap it on the product roadmap, what else should I be concerned about?
3. Items that have disappeared without explanation
Don’t make your product leader ask, “Where’d that epic go?”
Assume your product leader and other executives will notice any change you make to your roadmap. If you decide to shelve an initiative that your team had been expecting to build, you first need to complete two strategic steps:
Step 1: Build and document your case
When you drop a feature or epic from your roadmap, your product leader will need to know why. They might have shared the item with the rest of the executive team or discussed it with sales and marketing. You don’t want to pull the rug out from under everyone now, and not without good reason.
Your development team, which may have already begun breaking down the initiative into stories and tasks, will also expect to know why it’s off the roadmap. If they have spent time and resources delegating tasks and creating a schedule, you owe them an explanation for why you’ve decided to change plans.
Step 2: Have the conversations
It would help to let your team know about your plans to table the initiative. Your first call (or Zoom or Slack or drop-in) should be with your product leader, and you’ll want to share your reasoning and then seek agreement.
If your product leader agrees, it’s time to update the rest of the team. That means having the conversation with development, sales, marketing, customer success, and any other people who could be affected.
Even if you don’t need their approval or agreement, you still want to offer everyone on your team a thoughtful explanation about why you’re making this change. It can ease the frustration of anyone who has already started working on the now-tabled initiative.
It will also show that you respect your coworkers and believe that they have a right to know not just what’s happening but why. That will help you strengthen these meaningful relationships with your cross-functional team.
Purpose-built roadmap app
By the way, this is reason number 7,329 to use a purpose-built roadmap app, rather than trying to maintain your product roadmap in a static file like a spreadsheet or slideshow. A native web app will let you make changes like this on your roadmap much more quickly and easily.
For example, with the ProductPlan app, you can easily switch any initiative from Planned (where you publish in-flight items on the main roadmap view) over to Parked with just a click.
Also, you can—and should—add a comment beside the Parked item to explain why you’ve chosen to park it.
If your product leader or other execs open your roadmap and notice something missing, they can easily find it in the Parked section, along with a brief explanation of why you moved it.
Better still: Before removing any strategic initiative from the roadmap, have that conversation with your product leader.
4. Technical details that fail to tell a story
Don’t make your product leader ask, “Why should we care about that?”
Your roadmap isn’t the place for technical specs, and it’s there to tell the compelling story behind your product.
Let’s say you’ve prioritized making your enterprise software more secure to meet customers’ regulatory needs in industries like healthcare and financial services. One project that came out of your research is to beef up your apps from 32-bit to 64-bit encryption. Offering that level of security will stop your software from getting eliminated from these customers’ searches. Solid plan.
But then, when you add that epic to your roadmap, it looks like this:
“Upgrade enterprise apps to 64-bit encryption.”
And your product leader says, “Why should we care about that?” Fair question. The encryption enhancement itself isn’t the goal, just a step toward achieving that goal.
The epic should read:
“Enhance app security to acquire more healthcare/FinServ customers.”
That tells a story!
With ProductPlan’s app, you can even add a blurb explaining your reasoning, which you can hide in the epic and make available by clicking on it. That description might read this like:
“Our research suggests health/financial markets are choosing our competitors because their regulators demand higher levels of encryption than we offer.
Remember, your roadmap should communicate your strategy and plans. Any technical details that fail to advance your big-picture story will only slow your readers down and make them ask, “Who cares?”
5. Lack of clarity about where the product stands now
Don’t make your product leader ask, “Where are we today?”
Anyone who opens your roadmap should be able to quickly figure out what strategic initiatives you’re working on now, the status of those items, and what projects are up next. But with the tools that most product managers use for roadmaps—spreadsheets, slideshows—conveying this information is difficult.
It would be best to keep that in mind when you build and share your roadmap. The roadmap should clarify and illuminate the details of your progress—not confuse your audience. When your executives review the epics on your roadmap, how will they know whether each one is complete, in process, or not started?
One simple solution—and reason number 7,330 to use a purpose-built roadmap app—is to create your roadmap using software that lets you update the percent complete of any item on the roadmap. The right roadmap software will also integrate with your project management apps. That way, you can sync the progress of each roadmap item with the relevant tasks your team is working on and tracking in their project management app.
In the ProductPlan app, that looks like the screen below. Those with access to the roadmap can click into a theme or epic, allowing them to see how much progress the team has made.
The key takeaway here is when you present your roadmap, or if you publish it live and invite the company to review it anytime, you always want to be able to answer—clearly and with data—the question, “Where are we today?”
Successful Roadmapping Always Comes Down to Communication
The common thread among all the pitfalls I’ve discussed in this post is lack of communication. When it comes to creating and maintaining a product roadmap that will benefit your company, the key is communicating with the relevant people every step of the way.
When you present the roadmap to your product leader or when people in other departments log in to your roadmap online to see where things stand, you want them all to find it clear, compelling, and consistent with their expectations. You don’t want to give anyone a reason to say, “Huh?”