Guest Post by: Nick Eckhart (Mentee, Session 8, The Product Mentor) [Paired with Mentor, Nis Frome]
Every product manager has made the mistake of thinking a perfect product roadmap would solve the problem in front of them.
For example, you’re sitting in a meeting with stakeholders at the end of a deliverable cycle. They need to report upward, so you’re going through the motions, updating them on the work you’ve done, are doing, and intend to do. You’re fielding questions about why something a stakeholder brought up in passing wasn’t completed. You’re frustrated since you’ve already spent an immense amount of time talking through priorities instead of actually doing the work. Every product manager has been there and thought “there’s got to be a better way – I just need a great product roadmap!”
Ah, of course, the product roadmap. The one-stop-doc to keep all stakeholders aligned. It’ll show them what you’re working on now and in the future. But wait, there’s more! It’ll also be the sacred place anyone can point to when a new priority emerges, replacing something that has become passé. Too good to be true, right?
Right! The product roadmap is the ShamWow of aligning stakeholders.
Make no mistake – aligning stakeholders is a real problem. However, through my experience I’ve learned that the product roadmap offers the same empty promises of an infomercial. In reality, due to rapidly changing consumer preferences and shifting stakeholder priorities, roadmaps need to be one of the most fluid, unreliable, and ambiguous tools to clean up the stakeholder communication mess.
And yet, you still need a product roadmap. In more than 10 years of doing product management, I’ve learned that not having a roadmap creates more challenges than having one. But I’ve also learned to have realistic expectations. The roadmap is simply a conversation piece that, coupled with other communication tools, can help you achieve the ultimate goal: aligning stakeholders.
To that end, I’ve helped introduce roadmaps at companies of varying sizes, with both onsite and globally-distributed stakeholders. There is no one size fits all roadmap, but there are some common themes that lead to optimal results.
What Works
Creating an accessible destination where the roadmap lives
I’ve found boards (wall in the office for onsite teams and Trello for globally-distributed teams) to be the most effective. Stakeholders love to see things move! It helps visualize progress and as a bonus often helps connect disparate projects and priorities for developers.
Keeping it up to date
The end goal here is to train stakeholders to go to the roadmap destination for information. I always politely say “check the roadmap” when asked for a status update. Over time, this trains stakeholders to go right to the roadmap and gives it credibility, but only works if the information is up-to-date. Note: Managing information in multiple systems sucks, but I’ve tried integrations to ease the maintenance (See: What Doesn’t Work below)
Adding the objective + goal
If you’re not already doing OKR’s, I’d highly suggest starting. If you’re already using them, it’s important to remind stakeholders why you’re executing tactics. The end goal here is to train them to give us problem instead of giving us tactics. It takes time to make this shift, but tying “feature request A” back to a goal such as “Increase user retention” gives us leverage to say “tactic a didn’t solve problem, but I have feature b + feature c that might. Over time, you can gain trust and eventually they’ll come with problems instead of solutions, but only if you make the why prominent in your roadmap.
Not relying solely on the roadmap
It’s important to continue to communicate in other ways. The product roadmap sets up the conversation around priorities, but reinforcing them over & over again is important. I’ve used a few additional supporting communications + documentation that help.
- Give status update via email regularly.
- Make this the place to get updates on project status
- Track readership by using link tracking within the email or asking for feedback/decisions
- Keep it short: use GIFS to help explain points and use short, powerful snippets* to get a key message across quickly (politicians tend to be effective at this, even though it often comes at the cost of painfully oversimplifying matters)
- Consider sending different emails to different groups based on what they care about
- Have a weekly meeting to make sure there is still alignment on agreed upon priorities
- Do not give updates on status here (see above!)
- Both having a single meeting with all stakeholders and separate meetings with different stakeholder groups have worked
- This is all about discussion and getting information from stakeholders!
- Justify the roadmap priority by using a Feature Rubric, which is a rationale for why you’re prioritizing something. If nothing else, it creates a perception of having made data-driven decision.
What Doesn’t Work
I’ve tried a lot of different approaches so I’m all for experimenting with new things, but I haven’t seen the following work.
Letting stakeholders own the roadmap
Stakeholders love to come up with “solutions” and the product roadmap is no different. Inevitably, I’ve been asked to add something to the roadmap. Some of my favorite requests are it needing to be a Gantt chart or needing to be colorized. In addition, stakeholders seem to always want more detail.
Instead of letting them having control
Hear their concerns and dig into why, but remember the roadmap is only one tool to effectively communicate with stakeholders. You may be able to address those concerns in other ways, but it’s most important that you are the arbiter on what information is roadmap worthy
Trying to automate too much
I’ve gone to great lengths and spent way too much time trying to integrate automations from my project management system (JIRA, Trello, and Asana) to the roadmap . Each time the outcome has been that manually updating the information in both places is easiest. It makes sense. A project management tool is a comprehensive list of bugs + projects broken down into technical tasks for designers, product, and developers. The product roadmap; however, needs to be high level details tied back to OKR’s for stakeholders.
In Conclusion
The ShamWow has a 4.4 out of 5 rating on Amazon. It’s not perfect, but it’s “good.” The product roadmap is also “good.” It’s one feature in a feature set to help solve the objective: stakeholder alignment. Like any feature set, you try to figure out what the MVP is and learn and iterate over time.
*Example: Instead of giving a bunch of data on why a feature you have is great — sloganize it: Our <feature> beats industry benchmarks for <metric> and <metric>.. Stakeholders will repeat that message vs. repeating a bunch of data supporting that claim.
Nick is a data driven nut and eventual member of the Copenhagen Consensus. Currently, director of revenue product for the old Gakwer sites.
More About The Product Mentor
The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…
Better Decisions. Better Products. Better Product People.
Each Session of the program runs for 6 months with paired individuals…
- Conducting regular 1-on-1 mentor-mentee chats
- Sharing experiences with the larger Product community
- Participating in live-streamed product management lessons and Q&A
- Mentors and Mentees sharing their product management knowledge with the broader community
Sign up to be a Mentor today & join an elite group of product management leaders!
Check out the Mentors & Enjoy!
Jeremy Horn
The Product Guy
The Product Guy 