How to Make and Get Others to Respect Your Product Roadmap
As a product leader for over 10 years, I often get asked by colleagues, investors, and founders I advise one simple question that has no one correct answer - how do you create a product roadmap? This will look different given the size of your organization, but in this post I'll focus on early to mid stage startups by breaking down my process, why it’s important, and how to communicate it in the most persuasive way possible.
Why a roadmap is important
In short, it’s for your sanity. The most common and threatening thing a product person has to fight against is thrashing. This can come in many forms but often times it looks like conflicting customer feedback, quickly changing competitive environments, or emotional leaders applying pressure to abandon plans based on the most recent data point they’ve received. All of these things can create an environment where researching, designing, building, and shipping improvements in a product can become incredibly difficult, cause delays and waste significant resources. It’s for this reason product leaders need to have a plan to point to that’s been socialized and agreed upon in order to move forward to execute a winning product strategy.
Where to begin
A roadmap can’t just be a list of things you want to build or a high level gantt chart. It needs to be a well-informed strategy that you come up with from a variety of sources. So you will need to start with an open mind in collecting ideas and information to help inform what you should build. This is in part as much fact-finding as it is a way to allow others to feel heard.
Time to start your research - it will come in 3 forms: user research, internal stakeholder interviews, and analytics.
User Research
If you’re reading this then you probably have your ways to create customer feedback loops. Some of my favorites are:
Surveys through Typeform
Interviews in-person or video calls
App reviews
Customer service tickets
For your surveys and interviews, be sure to ask open-ended questions that will allow the respondents to be flexible. This is critical in minimizing the threat of confirmation bias when people report shortcomings within your product or their desires for new features.
But don’t be fooled! This is not the holy grail and should only be taken as one of many inputs to your roadmap.
Internal Stakeholder Interviews
Ok, this one is critical for a couple of reasons. First and foremost you have to realize that you are not an expert at everything and you are surrounded by smart, subject matter experts that can be amazing resources for you. So take advantage, and make sure you sit down with them to understand where they think the product should be headed. Just like in your customer-facing research, ask your colleagues broad, open-ended questions like:
What’s the one thing about our product that’s stopping us from achieving our goals?
What’s one thing you wish our product had and why?
What should we not support anymore?
What would the product have that would make your job easier?
Not only will this give you an entirely different perspective on what is important about the product for their particular roles and how they view your users, but it will make them feel heard. This will be hugely valuable when you get buy-in for your proposed roadmap. Don’t think you need to incorporate everything you hear, but it will inform you on how to frame your story internally to ensure you get to move the product in a direction you think is best for your company and users.
Analytics
This one is pretty straightforward. Hopefully, you have some type of attribution and product analytics integrated within your app. You should use these to identify key pain points of the user experience as well as what is working well within your product. As it relates to your roadmap, you will use this as a way to help tell your story behind the strategy. It will provide your audience with a sense that you are making well informed, impartial decisions and is absolutely critical when getting buy-in from your company’s leadership.
Synthesize and extract themes
At this point, you have a ton of data points, ideas, and feedback - probably more than you’ve ever wanted. But this is the fun part because this is finally where you begin to exercise your critical thinking, creativity and product intuition. It’s time to extract themes!
These themes are whatever you want them to be - there is no right or wrong here. It’s really just extracting the patterns you identify through all your sources of data. I’d recommend not having too many, maybe 3-5 as over categorization adds needless complexity.
The important thing here is that when you create the themes, know that everything you add to your product roadmap will be mapped back to one or more of these themes. So keep them broad but directional in nature. They can be something like:
User growth
Infrastructure
Revenue
Time to create the actual roadmap
Congrats on getting this far! You’ve successfully gathered information from your customers, colleagues and product analytics. This has helped inform you of any blind spots you had within your organization or customer experience. And you have taken a critical look at all this information and synthesized it into specific themes that will help provide guide rails to your roadmap and tell the story behind the strategy.
What to include
Your roadmap is not just a list of features you want to build, it’s a story. Here are the important sections to include in your roadmap to properly frame the discussion, provide context, and communicate the strategy moving forward.
Product vision - The product vision describes the what and the why. It’s highly aspirational and long term
Company KPIs - Defined, agreed-upon metrics and goals the company is striving to achieve
Timeline - Specifying how long the product roadmap is covering
Risks - Calling out what could happen that would stop the team from achieving everything that is laid out within the roadmap
Themes - Some context as to what these are and how they were created
Proposed roadmap - List of features/epics that are tied to one or more theme and KPI
What was considered but did not make the cut and why - Critical in giving credibility to the suggestions made by stakeholders or customers while communicating why they did not make the cut this time
The roadmap itself can come in many forms but will most likely be either a document or a deck. It should reflect how you feel best to communicate this information based on your company culture.
How to prioritize
KPIs, KPIs, KPIs. These are the backbone of your roadmap and what you will ultimately use to prioritize work and defend your plan. I won’t get into the best way to formulate your company-wide KPIs in this post, but just know that you’ll need to have a short, prioritized list of metrics agreed upon by the leadership of your company in order to build your roadmap.
When thinking of the best way to prioritize the work ahead just know that this is not an exact science. Some people like to use grading rubrics to help standardize the process but it’s not necessary. Similar to how you chose what form your roadmap will take, the way you prioritize features should be reflective of how you best tell your story and your audience. The one key thing to remember here is you will need to be able to justify your prioritization based on how impactful you think any given feature will move specific KPIs. It will help to have data to help back up your justification in the form of customer feedback and analytics.
Time to socialize
It’s critical to get buy-in from your company’s key stakeholders and leadership. These are probably the same people who’ve interviewed previously, so set up 1:1 meetings with each of them again and walk them through the proposed roadmap. Be sure to listen to their feedback! Again, it’s critical to make sure these individuals feel heard and are ultimately supportive of your strategy.
Final steps
Amazing. You’ve actually created a product roadmap and got buy-in from leadership. Well done, but your job isn’t completed yet. Now you need to communicate this out to the rest of the company and to the Board. The way you present these two groups will be very different, but I find the questions largely remain the same.
I will leave you with a few examples of common questions that are asked and suggestions on how to defend:
Why is X prioritized over Y?
Refer to prioritized KPIs and use data from customers and analytics to justify your proposal
Why was X not included?
Refer to what did not make the cut and the comment on why
Ask what should be removed from the roadmap to that is less important
Ask for data to support their suggestion
I don’t think X should be on the roadmap - why was it included?
Refer to customer feedback and analytics
If you follow this process, and answer these questions in a confident, tactful manor, you’ll find that not only will people respect your position as product owner, but also give you the space to execute efficiently and effectively.
Happy mapping!
