Product roadmaps as strategy

A common trap people fall into when moving from project to product is mistaking a product roadmap for a project plan with milestones…

Aug 21, 2022

A common trap people fall into when moving from project to product is mistaking a product roadmap for a project plan with milestones, committed dates to features etc. That is called a Gantt chart.

When you do product you want to keep your options open, you are always learning what your customers behaviors are and you want to balance delivering features with invalidating your hypothesis and learning.

If you and your product teams are committed to deliver ‘xyz’ requirements for the next 18 months, there isn’t going to be much innovation going on, just a feature factory approach to get stuff out the door.

That sounds a lot like waterfall…

Here’s a much better answer from Janna Bastow (inventor of now, next, later, started mind the product, product tank and co-founder of ProdPad)

What is a roadmap? An artefact that communicates the direction you’ll be going, in order to fulfil the product vision. — Janna Bastow - source talk: Ultimate Guide to Roadmap by Janna Bastow

One of the often-overlooked areas of product management and something that can poison a roadmap is a lack of product discovery / optionality. This is all about discovering the user value as cost effectively as possible. This helps de-risks your product roadmap and allows you to incrementally delivery value whilst delivering value along the way.

That doesn’t mean neglecting your architecture and non-functional requirements — it just means that you don’t need to over design for things your customers or stakeholders don’t need or won’t use.

I see many teams building things that are never used (originating from a senior executive who has never done a product role).

“You can release all the features you want, but if it doesn’t solve the underlying business problem, you haven’t really solved anything.” — Marty Cagan, Inspired (2nd ed.)

This is a tricky position for product teams to be in but thankfully this is exactly where product discovery can help. I don’t suggest you tell the executive they are wrong and go away; instead, I’d suggest taking their input and validating it with data as quickly as possible and sharing the results. Over time the executive will learn that your approach to discovery is saving money, effort and delivering more value along the way.

I prefer the idea that the person prioritizing the products roadmap is also accountable for the products outcomes. If you disconnect the two you create an ‘us and them’ mentality which tends to produce feature factory teams. That leads to teams pumping out features mindlessly and not having the time to experiment and learn, talk to their users, and deliver innovative / creative solutions to the customers' problems.

If you are looking for more innovation in your organization and it isn’t happening, I suspect it is the result of teams not being empowered to make their own decisions and owning product outcomes.

Outcomes and value are either a hypothesis or unknown until they are invalidated through discovery of user testing. If you are working on a product not yet released to the market a eating your own dog food approach can be taken or as a Swiss colleague of mine suggests ‘drinking your own Champagne’. Clearly things are more refined in Switzerland.

Based on my experience to date, a three-layered approach to different views of information allows you to split out granularity and uncertainty for a given audience. One crucial point (thanks Jocko Selberg), the further the horizon, the more ambiguity, the less certainty about the future (incomplete information). You reduce risks by getting more information through experiments / probes / user testing / discovery etc. As you learn your roadmap gets updated, product roadmaps should not be set in stone.

What you share as your roadmap isn’t necessarily what you use in detail for your teams and vice versa.

Product strategy view (this is the roadmap): from now to longer term — that conveys strategy and product evolution, looking like a set of breadcrumbs to help you realize your product vision (potentially spans years but won't state number of users).
Product options view (this is the product backlog — user story map): from now to medium-term view that shows the highest value options in the products backlog that the product is going to address (spanning 2–3 months and detail is more focused on things like jobs to be done / personas / specific markets or pain points). This view can be used for planning releases and for stakeholders with regulatory deadlines (see more detail below).
Product delivery view (this is the prioritized / iteration backlog): a short-term view that includes stories that are ready for delivery (the discovery work has occurred or is underway) and work is ready to be pulled into the teams backlog as prioritized or ready for the next iteration (typically no more than six or 2–3 iterations worth of detail).

Note: for those working in heavily regulated environments thinking — ‘that’s great — we have deadlines to commit to’. Product roadmaps are not intended for regulators, they are there to convey strategy and alignment to product vision.

If you are faced with a deadline, you can leverage a release plan to align on understanding and more of a time centric view. You don’t need to commit to specific features by a certain date but if you slide your stories sufficiently you can show how often you can deliver and what the scenario is for ensuring readiness ahead of a deadline.

If you lack clarity on what is required to meet a deadline, then you should focus on solving that first. Get to the stage where you understand exactly what problems need to be solved. You can validate as cheaply as you want, however don’t neglect non-functional aspects such as an increase in load / performance required for the new regulation.

Slicing the problem into smaller slices can be helpful in proving things out where you have ambiguity. You might not have a polished UI / dashboard — but you should be able to show the end results of what is needed to make sure that the finished output (if a report) looks like so that feedback can be provided early and often to the teams.

If teams can't estimate work due to uncertainty or lack of clarity — they may be in a situation where they might have built that thing (or something like it) before e.g. a new technology (e.g. cloud) or architecture (e.g. moving from relational databases to a data lake using Spark and an object store).

Don’t conflate building something with figuring out how to build it, if you have uncertainty an architecture spike might be needed to figure out how to build things.

This may not be useful to your users or stakeholders initially, but it is useful to the teams building the product because it helps reduce uncertainty.

Imagine learning to walk a tight rope, the very first time you see one. Teams should have a safety net and time to learn the skills needed.

An ode to Discover to Deliver

In the incredible book Discover to Deliver by Ellen Gottesdiener and Mary Gorman — there’s some amazing pearls of wisdom. Not enough credit is given to their work. I see a lot of influence in other product people these days too — more kudos is needed!

In their book, they break down the levels of plans into three views (Big-View, Pre-View, and Now-View) which very naturally link to the three views above.

https://www.discovertodeliver.com/image/data/Resources/visuals/DtoD-Planning-Views1.jpg

Ellen and Mary give the plans specific names, provide a purpose, and set of partners who participate in each plan. In the digital version it is the 98th page, but the page number in the book itself is page 80.

The book talks about structured conversations for working through the three views and supports a discovery which applies to each level. (Explore — Evaluate — Confirm as a cycle).

They also have a wonderful view of ‘7 product dimensions’ which are a great way to enrich how you think about your product roadmap, plans and stories.

Where to next?

What other resources do you recommend on product roadmaps and horizons of planning?

I think taking a complex adaptive approach could be interesting, an overlay of the Cynefin domains on top of user problems and product goals. How to address each type of roadmap item and what kind of approach.

Contextual Healing

Discussion about this post