What I learned from Bruce McCarthy’s product roadmap workshop
In September 2020, I completed a 4 day product roadmap workshop run by Bruce McCarthy, a product guru who wrote the book “Product Roadmap Relaunched”. The workshop was run digitally with fellow other classmates from all around the world, the US, Mexico and New Zealand. It was a great 4 days with lots of activities to actually build a roadmap with your team and have Bruce give you constructive feedback along the way.
Throughout my career in product management, I’ve had a love and hate relationships with product roadmaps. No matter what I did, it seemed like I could never make my stakeholders happy. It got to a point where I was starting to think that the roadmaps are useless as it changes too often, we can never meet the timelines and it’s never detailed enough to show me how we are actually going to deliver what we said we’ll deliver. Well… it turns out that this is a VERY COMMON experience for many product managers. Let me share my learnings from Bruce’s workshop.
- A product roadmap is NOT a release plan / project plan or a delivery plan. A roadmap should NOT have a list of features with dates.
- A product roadmap is a STRATEGIC COMMUNICATIONS TOOL so that you can articulate the WHY of your product to your stakeholders.
- Think of your roadmap as a prototype of your product strategy.
- The roadmap manages the outcome not the output ie. a roadmap shows how a product can achieve the business objectives whereas the release/delivery/project plan manages the output.
- The time horizon for a product roadmap is 2 -3 years while a release / delivery / project plan is ~ 6 weeks to a quarter (at most).
This is a simple concept but it was an eye opener for me as it immediately showed me where I was going wrong with my roadmaps. My previous roadmaps were something between a roadmap and a delivery plan. It was too detailed with arbitrary dates plotted against the features. It definitely didn’t tell a story or articulate the WHY of the product. No wonder I was getting no luck convincing the CEOs and executive management that the roadmap I had put together was a good idea. I was also listing features as opposed to the themes. Often I spent hours researching and doing my due diligence before drafting a roadmap so I had confidence that the prioritised features in the roadmap addressed the customer problems and were the right things to build — BUT the roadmap never showed them why I was recommending these set of features. I wasn’t using it as a strategic communications tool.
So here are the 5 primary components of the product roadmap that Bruce recommends in his workshop:
- Product vision: This is your unique selling proposition (USP) and states how the future world will benefit from the product. A product vision should be tied to the company vision.
- Business outcomes: This is the internal benefits and should be tied to the company’s business objectives or objective key results (OKRs).
- Timeframes: This should be sequencing and guidance on timing not detailed dates against the roadmap items. Bruce recommends broad categories such as “Now”, “Next” and “Later” or H1, H2 or Q1, Q2, Q3 and Q4.
- Themes: These are the customer problems to be solved in order to realise the product vision. I think this is where I was going wrong. My roadmaps showed a list of features / functionalities, not a list of “customer problems or needs”. Even though the list of features was derived from customer needs, the roadmap didn’t connect the two.
- Disclaimer: This is to tell the stakeholders that the change is possible, even likely over time based on customer and business needs.
In the workshop we also learned to prioritise the “Themes” based a formula that rates each item.
Value / Effort x Confidence = Priority
- Value is the expected contribution to business outcomes
- Effort is the estimated resources to solve problem eg. engineering time / design & research
- Confidence is the accuracy of your score eg. how confident are you that the team is able to deliver that theme, the theme will have an impact on the business objectives etc.
You can use any scale to calculate the priority using this formula but we used a scale from — 2 to 2 to keep things simple. 0 = no value and — numbers = negative impact.
So the final roadmap looks something like this:
Obviously this is a simplified version of a product roadmap but I think this format works well. In my view, a product roadmap shouldn’t contain too much details about the theme or features. The purpose of the product roadmap isn’t to show how you are going to deliver but rather why you should build the product the way roadmap shows it.
Are you experiencing similar issues with your roadmaps? I suggest you try this method.
