A note for new subscribers: This post is part of a monthly series on my notes on technology product management (this is what I do for a living). You might notice that these posts often link to older posts in the series on LinkedIn even though they are all available on this blog. That is intended for folks who only want to follow future product management related posts. Finally, for all those of you who don’t build tech products for a living, I believe many of these notes have broader applicability. And, I hope you find that to be the case as well…
A quick overview of what we’ve covered on “Notes on Product Management” so far –
In our last post on Notes on Product Management, we covered how we’ll build our strategy. Thanks to the experience of going through the strategy creation process, you and the product team understand where you need to focus. The next step is to translate that into a product roadmap.
A product roadmap is a high level summary of what we will build to execute on our strategy. I’ve laid out the 5 steps that I’ve found helpful below.
Unlike prior posts, this post will very tactical and, thus, long. I’m going to do my best to share rationale – but, in many cases, there’s a lot of learning from various iterations (read: stumbles and missteps) baked into these notes. So, please feel free to ask questions in the comments and I hope you find it helpful.
Step 1 – The Roadmap brainstorm: The first step to building the team’s roadmap is a brainstorm with the entire product team.
The best scenario is when every person on the product team is present in-person. Co-location is very powerful. Even in the case of a largely remote product team, it is worth waiting to have everyone together as part of a team event to do one of these. A good brainstorm session can take anywhere between 2 hours to 4 hours. These can be shorter – but it is generally worth the time. (If you’re wondering about the remote version of this given the circumstances, don’t worry – I’ve got you covered below)
For details on this step, I’m going to get very tactical (forgive me):
i) Invite everyone on the team – below is a snapshot of the folks who may be on your invite list
ii) Book an airy room with a view – It is worth booking the best room in your building well in advance. You may even want to consider taking the team offsite to do this (you will just need a white board).
iii) Agenda –
a) Objective: This meeting will be successful if…. a) we get to know each other, b) align on context – strategy, data, and user feedback, and c) brainstorm product ideas to execute on our strategy. I also share that my success metric for this meeting is “% of shut laptops.”
b) Fun intros: Invest in doing something beyond having folks introduce themselves. Fun facts, 2 truths and a lie, interesting questions, cross introductions, etc., are ways to make this fun. Time invested in getting to know each other is always well invested.
c) Context:
i. Strategy: Remind everyone of the strategy.
ii. User research/feedback: Request the “Voice of user” team to share a 1 slide synthesis of user research/feedback
iii. Data: Similarly, request the “Voice of data” team to share a 1 slide synthesis of data
d) Brainstorm:
i. Prompt: Share the prompt – What are 3 features you would prioritize for us to successfully execute on our strategy?
ii. Brain-writing: Give everyone 5 minutes to write their individual ideas down on post its – this will ensure every member of your team (especially the quiet ones) have time to think
iii. (optional) Group brainstorming: Split folks into teams of 3 or 4 and ask them to discuss for another 5 minutes and further hone their ideas
iv. Summarize ideas: Go to a whiteboard and ask every person to share their ideas with their reasoning – as they share their ideas, cluster similar ideas in groups as themes will inevitably emerge
v. Prioritized vote: Next, and most important, ask every member to vote for their top 2 across all ideas and tally the top themes. Inevitably, 3-4 high priority areas will emerge.
It is impossible to over state the importance of the prioritized vote. It is the step that separates a successful brainstorm from a failed one. Failed brainstorms have organizers take back sheets or photographs of un-prioritized ideas. In successful brainstorms, the entire team walks out with a shared understanding of the few things that matter.
e) Next steps: Promise to synthesize the results of the brainstorm in a roadmap sheet that you will share with the team.
An outcome I’ve observed over the years – a team with shared context always converges on the right set of big ticket items that matter. This is the most magical part of well run brainstorms. You don’t need to pre-alignment meetings to get alignment within your team. Setting context will do.
And, if you are remote, there’s a way to do this remotely too. You just need to set up a spreadsheet where everyone can vote. Below is a screenshot and click here for a sample spreadsheet.
Step 2 – Organize your plan to ensure you are taking a portfolio view: The next step is to go through your plan and organize your bet into a portfolio view. The 4 buckets I’ve found helpful to use are –
3 common questions that come up when discussing these buckets.
i) Is there a correct allocation between the buckets?: No. This is entirely situation dependent. If you are going through a massive technical migration, you will have a large allocation on “Foundations.” If you are under urgent revenue pressure, your “Core” bucket may be heavily stacked. So, use your judgment.
If there is a mistake to avoid, it is over-indexing on “Core” to optimize for short term metric wins. I’ve personally found a ~20%-40%-40% balance between Foundational, Strategic, and Core to be optimal as it ensures we’re making progress across the board. I don’t generally make allocations for venture bets because those allocations are best made at the level of a business unit vs. in an IC PMs portfolio.
2. Where do you allocate time for fixing bugs?: There are two kinds of bugs – blockers/criticals and everything else. All blocker and critical bugs need to be triaged, by definition, immediately.
Other bugs that fall into “everything else” bucket require judgment. Often times, non-critical bugs point to workflows that need to be re-engineered – these can be incorporated in the “strategic” bucket. The rest is up to you. Different folks have different philosophies on it and these also need to vary between enterprise products and consumer products. I don’t know if there is a right one – the only thing that matters is picking the philosophy that works for you, your team, and your product.
3. What is the best tool to use to create this roadmap?: I don’t know. Maybe there is one – then again, there may not be. I’ve found spreadsheets to be wonderful personally. But, I also tend to be a minimalist when it comes to tools. So, feel free to experiment… just remember again that there is no right answer. Find one that works for you and your team.
Step 3 – Figure out if you can accelerate progress via partnership or M&A: Building a product internally is just one way to achieve your goals with a positive RoI. You can also accelerate your progress via two other strategic options – partnerships and, every once in a rare while, M&A.
If you believe there is an M&A target or two worth considering, build a strong working relationship with your investment/Corp Dev team to build out the investment case. In such cases, make sure your investment/Corp Dev team members have full visibility of your strategy and roadmap (invite them to that brainstorm!).
M&A aside, more often than not, you will likely find ways to partner. There are again two ways to do this –
Step 4 – Share a high level visual in your strategy doc: Bring this back to your strategy doc with a high level visual that breaks your roadmap either in quarters or 6-months/halves. Enterprise roadmaps can go as long as two or three years. But, if it is a consumer roadmap, 18 months is about as long as it probably makes sense (it is unlikely you’ll go 6 months before changing it again :-)).
Use this visual to check if everyone is bought in and if the timelines makes sense – this is especially important if you are running an enterprise product with go-to-market commitments. Below is an illustrative visual – it tends to be helpful to bring cluster features within initiatives that seek to help us execute on our strategy and drive toward metrics that matter. These strategy pillars and metrics, in turn, hopefully map straight to the user/customer problems we set out seeking to solve.
5) Set expectations both externally and internally: Once the team is aligned, the final step is to set expectations.
a) External: Your GTM partners will now use the roadmap to create the customer/user education plan. This may involve previews, presentations, updates to client decks, and the like.
b) Internal: The more tricky part is setting internal executive expectations. This is especially important if you are planning strategic bets or key infrastructure upgrades that may impact your metric forecasts. This is the biggest area where I’ve seen folks make mistakes – and it is definitely the area where I have some painful war stories myself.
The key here is to take the time to work through the first and second order effects of your planned roadmap. Ask yourself – what will be the impact to metrics that matter for each initiative? Then, think through what happens when all the initiatives roll out together – will there be any compound effects? Finally, think about initiatives partner teams are planning to undertake – do any of them impact your strategy?
When you go through that exercise, you will likely realize that there are a few curve balls that you need to further flesh out. If you are managing a business with revenue expectations, work through these steps diligently with your Finance and Ops partners so you know what to expect. Once you know what to expect, communicate and get exec support.
The better your own understanding of what lies ahead and the better you set expectations, the more freedom you’ll have to execute on your vision. Fail to do that and your roadmap will just be a spreadsheet full of ideas that never saw the light.
Building good roadmaps is a core aspect of an IC PM’s job. But, how these roadmaps get built is often misunderstood. It is the PM’s job to facilitate the conversion within the product team and use the team’s collective brainpower, insight, and perspective to create this roadmap. As a result, we can’t just walk into a new team and build a roadmap. Those kinds of roadmaps result in poor products.
Instead, we need to take the time to get to an understanding of the core problems, articulate them in clear problem statements, define a strategy with the team, and then build the roadmap. When we walk into a new team, we often have to do this in parallel with executing on an existing roadmap.
The outcome of a well run process is a team that is aligned and rowing in the same direction. And, a test of this is when they refer to the roadmap as “our roadmap” instead of “the PM’s roadmap” or “your roadmap.”
When that begins to happen (and it often takes time and a lot of reinforcement), good products and happy users/customers generally follow.
