For many of us, roadmapping season is starting or about to start…
We’re coming up to the end of the year and embarking on our new year. And every year we walk into roadmapping with just a little dread. “Ugh, another 2+ months of research, debate, and planning gymnastics!” “No one looks at it!” “By mid year, it’s blown up anyway!”
I’m here to tell you that if you approach it with the right principles and effort, the roadmap can be a great ongoing galvanizing operating mechanism in your company. It can actually help you avoid shiny object syndrome too!
We should start with a couple basics…
Definition of Success of a Product Roadmap:
- Enables the business to achieve it’s goals; on time, within expectations
- Provides a way for the entire organization to understand the prioritization, timing and relative sizing of solving major customer problems
- Drives long term platform development scope & timing
We presume you have a documented business strategy and objectives that are used as a rudder throughout this process. If not, we tell all our product managers…propose them and get agreement, so that you can build a supportive product roadmap. I say that loosely, because it’s not that easy. But without business strategy and clearly defined objectives/measures, what are you aiming for? We have an online course for facilitating the definition of both if you find yourself in this position.
Okay, now for the main act…Here are some tips in achieving roadmap success:
Start with the Customer
No duh. Right? Well, lets step back a second. For many, this means “let’s do the features that our customers requested.” That is not what we mean here. Instead, it’s making sure that you have clear persona(s); personas that your team/company has agreed to. This is not easy. But if done right, you can actually ward off shiny objects that address problems of customers outside your persona sweet spot. Having a clear persona helps people understand who you’re NOT going to solve in your roadmap as well. We’ve got a couple posts on our blog about personas…try this one. Contact one of our rebel leaders if you need a simple template that works!
Clearly Define Problems You’re Solving – Your Roadmap Themes
Most roadmaps are organized by 2 dimensions…time being the obvious one…and themes which are basically problems, strategies, or objectives for the business. Each theme should be solving a very clear customer problem. Having a clearly defined problem statement will help galvanize your team around what you are and are NOT solving for. Having clear problem statements will help ward off shiny objects as well…”Hi Mr. shiny object thrower! How does this shiny object serve the problems we agreed to solve in our roadmap?” Most of the time you get “Well…uh…hmmmm….You’re probably right. Let’s table it for now.” The persona and problem statements help you justify tabling a shiny object. If you don’t have those, it’s easy to get into an opinion-driven debate that usually ends up with that shiny object being added to the pipeline and other important initiatives are delayed or worse, never completed.
Facilitate Innovation/Design Thinking
You may already have clarity on target persona and a clearly defined problem AND a previously discussed set of initiatives that serve both. Hopefully they are fully agreed to by the extended team. But if you are questioning any one of those inputs or if you don’t have a shared vision on those inputs, then I would step back and ensure you are flexing your design thinking muscle. Problem-driven brainstorming (with choice-ful attendees…creative minds, market experts (internal or external,) customers, partners, etc.) and other design thinking techniques will ensure the most impactful ideas are considered vs. just the squeaky wheels. A quick set of customer interviews (5-10 targeted interviews can do wonders,) a brainstorming session, and a vote will drive far more committment than status quo thinking or focusing on the “sacred cows” in the organization.
Build Shared Vision…and Commitment
As a product manager, you’ve probably felt the pain at one point in your career of a lack of committment to the product roadmap…either someone from your leadership team, your development team, or your design team doesn’t agree with the prioritization or existence of some initiative and it makes it a painful process every time you have to justify it and ensure it’s given the attention it requires to be successful. We’ve all been there. Your job in this process is bringing team members in at the right time…Providing them the customer context (having them hear from customers directly is even better,) getting their feedback and hearing what their dependencies or concerns are, getting their ideas, agreeing on the criteria for prioritization of themes/efforts, etc. …And ensuring they are onboard before the final presentation of the roadmap. Ideally, your development and operational leaders are standing beside you when presenting to the leadership team and show as much ownership over the roadmap as you do! Yes, I have experienced this myself!
Understand ALL Your Critical Path Dependencies
Most product managers guess at their dependencies or don’t cover them all. This is just a word to the wise. Go through your draft roadmap with your major partners to get their input and understand what they’d have to do (development or otherwise) to ensure the initiatives can be successful in the timeframes you are expecting them to be. As what their biggest concerns are or believe to be the biggest risks. You’d be surprise at what you learn by going through your draft roadmap with your teams beyond just the dev team… support, operations, marketing, IT, etc. We always think about it in terms of inputs, process, and outputs. What are the input decisions, development, or partnerships required to begin the dev on any given initiative? What is needed to actually develop the functionality; 3rd party software, partnerships, critical-path platform tech, etc? And what needs to be released or ready by the time that functionality needs to be in market; partnership support teams, partnership technology or marketing, marketing technology, packaging, etc? Think beyond mainline platform dependencies!
Ongoing Management
Once complete, we usually have a couple versions…one that’s all polished and summarized for the leadership team and one that is used for ongoing discussion as we learn more and have ongoing discussions with our core team. We recommend reviewing the roadmap every month or two to ensure you’re managing the backlog accordingly and you’re communicating any major learning and associated pivots in the roadmap to the leadership team. You can also use the roadmap as a tool in shiny object discussions. “You want that shiny object added? Are you willing to push this theme out X months for it?” When you can have a discussion about the implications of a shiny object as it relates to a roadmap that the entire team helped build, you avoid opinion-based discussion and ensure you are doing what’s best for the customer and business. It’s a much easier discussion.
Don’t have a clean process to take into account all these best practices? We have a process framework that has worked for us. It’s a ratty ol’ powerpoint, but its a proven process that enables the most targeted, impactful, and committed roadmap.
Happy Roadmapping Season!!