Product Clinic
Most roadmaps fail because they are trying to do too much for too many people. Chances are your roadmap is either too in the weeds to communicate with management, or too macro that your scrum team can't fully engage to deliver tangible value to the user.
12 May 2020 · 6 min read
They aim to:
When you think about it, that’s a lot of stuff to put into a single visual. Making a stellar roadmap to solve all these problems creates a concentration of pressure. As a result, we see many teams fumble while trying to tick all these boxes.
In a world where there is growing specialization in skills, techniques, and in turn software, why are we still trying to squeeze all this information into one tool?
Recently, I had the pleasure of (virtually) meeting Marty Cagan from the Silicon Valley Product Group and author of the seminal product management book, Inspired. One of his key messages during a Q&A session was that product teams waste so much time developing and estimating feature roadmaps, when they should be focused on build, measure, learn cycles. That is, focus on product outcomes, their priority, and buy time until you have data-informed tactics.
This does a couple of things:
You can read more about Marty’s thoughts on this here and here.
Bottom line: the intent of a feature in a roadmap can be interpreted subjectively, and as a result we have seen teams drift from their original goal during execution. Whereas an outcome on a roadmap is unambiguous, offering a constant reminder of your desired goal throughout your delivery cycle.
Examples of drift range from:
We spend a lot of time reviewing product roadmaps with our portfolio companies at Tidal and many more in review sessions over my lifetime a product leader. We tend to run into this issue consistently. So we created a practical guide on developing a connected roadmap that leans on complementary artefacts to address the goals above.
Here is a visual map of how we will progressively leverage a set of common artefacts to achieve a connected roadmap:
Visual map of how we will achieve a connected roadmap. Part of reducing the pressure on a roadmap is to focus it on doing one thing well. If we extend this philosophy to all company goals (via OKRs) and agile delivery (via Scrum/Kanban), we make each fit for purpose. We'll use each artefact to separate concerns.
Before getting started on a roadmap, we need some guidance from leadership. Your company goals form this guidance. We will use the OKR (Objectives & Key Results) format to frame them with a business lens.
This is what it might look like:
Example of simplified company goals in OKR format framed from a business lens. Planning cycles may be between 6-18 months. The smaller the business the shorter the cycle, with the happy medium at 12 months. Taper your expectations to this timespan.
Use this checklist to inform your roadmap:
Finally, are the company OKRs you are accountable for grounded in rational optimism? You want to be ambitious, but it needs to be coupled with a reality check that considers cadence, dependencies, and the timespan for achieving the result. While this is not specific input into building a roadmap, it's worth asking if you are set up for success?
Posing the checklist and your own situational questions helps develop a shared understanding with stakeholders and is half of the solution for aligning on value.
Now that you have tightened up the business OKRs, let's connect them to your product roadmap.
The fundamental challenge with most feature-based roadmaps is they are used to convey product strategy to stakeholders but are rarely self-explanatory. They require a talk track to explain how tactics (features) ladder up to strategy (outcomes), rather than stating the strategy itself and making it accessible. This way, your feature doesn't get in the way of your outcome. If your feature fails the goal, you can pivot without changing your high-level roadmap.
Outcome-oriented roadmaps help you defer and switch tactics while maintaining the original intent that stakeholders are aligned on:
Feature roadmap
versus
Outcomes roadmap
This is what it might look like:
Example of a simplified outcome oriented roadmap connected to company objectives. Force yourself to prioritise each outcome before your business leaders ask you to. When known capacity is challenged due to unforeseen events, you will be always ready with the necessary priority trade-offs.
Here are the ways to convert typical roadmap elements into an outcome-oriented roadmap:
You may be thinking an outcome-oriented roadmap lacks the depth of the feature roadmap. But what you lose in detail you gain in clarity of purpose. It is the other half of the solution for aligning on value and illustrates how you intend to prioritise value delivery.
Now that you have expressed your product strategy using outcomes, let’s connect your strategic outcomes to your feature tactics.
In agile development, epics encapsulate a set of related stories. Often a few epics may be required to achieve a desired outcome through gradual iterations. The simple use of a progress bar within each (outcome) bar connects strategy to tactical delivery. It also enables stakeholders to track progress in delivering user value, associated with the outcome, and finally the business OKRs.
This is what it might look like:
Example agile board connected to an outcomes roadmap. Tag cards to outcomes to track progress on your roadmap and use columns that reflect your delivery cycle. This caters to your team audience and still connects them all the way to product and company strategy.
We do not prescribe a specific agile methodology. That is very much a team decision. However techniques like User Story Mapping or Jobs to be Done are a useful methods in curating what actually gets on your backlog.
The mindset of having a groomed epic backlog should be strong opinions, loosely held. Each epic merely represents a way to capture your thesis of the user value impact for a given feature; and why it is a suitable leading indicator to the outcome's lagging indicator in your roadmap.
Here are ways to tweak a typical Scrum or Kanban board elements to connect your roadmap:
By tuning your board elements this way, you have connected to your roadmap, and in turn the company goals. Congratulations, time to celebrate.
Adopting a connected roadmap may resolve unwanted pressure by allowing each artefact to have a clear purpose. Everyone in the organisation should have more clarity as they can cascade up or down through each view and see how value is aligned, prioritised and consistently defined at each level.
Let’s recap the benefits of using a connected roadmap:
Thanks to Tash, Andrea, Georgie, teams at Bonjoro, Shippit, and Secure Code Warrior for contributing and reading drafts of this article.
Get our latest newsletters delivered right to your inbox
We’re delighted to have led Asseti’s Seed round, working with the team to realise their mission of building the world’s leading intelligent asset management platform. Asseti uses high-quality imagery and machine learning to predict and prioritise asset needs, minimising downtime and maximising lifespan.
OG technology evangelist Guy Kawasaki joined Tidal Managing Partner and Co-Founder Grant McCarthy to discuss the characteristics of remarkable founders and how to navigate the long and exciting journey of being an entrepreneur.
I’m Kieran O’Neill, Principal at Tidal. I’m known for combining my finance background and time in the trenches, founding my own startup, to help founders see around corners and get to their next stage of growth. Keen to get to know a little more about me? Well, read on.