Get rid of feature based roadmaps (PWW #2)

Hi,

I hope you are having a great Friday!

Nearly every product manager / product owner can relate to "the roadmap struggle". Being forced - by stakeholders or senior management - to commit to a feature-based roadmap with fixed delivery dates. This goes directly against the Agile/Lean approach that most product people prefer to use.

Trying to stick to old-school, detailed, feature roadmaps ends with teams building the wrong things. It is a guarantee that people will focus purely on what's on the roadmap. And missing more valuable opportunities along the way.

You are creating a slower and more rigid organisation, as opposed to an agile and flexible one.

If that is exactly what you want: go for it! If it's not: this week I have gathered some alternative roadmap approaches.

Have a great day 👋

Wouter

Worth reading this week

Planning With Outcome Roadmaps by Itamar Gilad

This is an interesting read by Itamar Gilad. He writes about using outcome based roadmaps, as opposed to the output based roadmaps.

"One glaring omission in most output roadmaps is that there are no goals anywhere to be seen. It’s all output, no outcomes. A good starting point therefore is to try to plot the company’s goals on a timeline."

Working together with management to create an outcome-based roadmap is a great first step away from the traditional output-based roadmap. It combines the benefits of a timeline roadmap (providing insight into development time and planning resources) with the advantages of focusing on outcomes (providing clarity on goals, making it easier to link to the company's strategy, and being more business value-oriented).

Itamar proposes starting by mapping the most important company goals on a timeline. For each goal you would create these separate "phases" on the roadmap:

1. Research & Ideation (optional)
2. Product Discovery
3. Product Delivery
4. Effect Delay

The first 2 phases have a higher degree of uncertainty. Research & ideation and Product Discovery are meant to define a clear context, come up with ideas on how to achieve the goal, and do discovery to decide which idea(s) have the highest probability of success.

Once you go into Product Delivery, the scope for what is to be built is fairly clear. And the conditions for success are clear. This makes it easier to actually estimate or time-box the delivery phase.

The Effect Delay is a critical addition to a roadmap. It acknowledges that even after launching a feature or a product, some time will elapse before data can prove if you have succeeded. Planning should account for this delay. If, after the effect delay, the success criteria are not met yet, you may have to decide to go back to the drawing board.

Why I Invented the Now-Next-Later Roadmap by Janna Bastow

Going one step further in terms of Agile roadmapping would be the Now-Next-Later framework. This was created by Janna Bastow and is a very simple way of visualizing which initiatives or goals have been prioritized.

"The Now-Next-Later roadmap exists because timeline roadmaps aren’t effective, simple as that. Timeline roadmaps insist on deadlines, which means product teams are deprived of the flexibility that allows them to do their best work."

The Now-Next-Later roadmap embraces the fact that there are varying levels of uncertainty. It visualizes that uncertainty in three columns:

Now - Where are you now, and what are you currently working on in the short term? These are detailed initiatives for which you already have a reasonable idea of the scope and the approximate amount of time they will take from the team. In terms of the time horizon, these are your upcoming few sprints.

Next - What will you pick up immediately afterward? These are the highest-priority initiatives you want to tackle as soon as the current work is completed. These initiatives are less detailed, and the scope is sometimes not entirely clear yet. They could also be initiatives dependent on what you are working on in the Now column.

Later - What's on the idea list for later? These initiatives are still vague, perhaps only one-liners without detailed elaboration. The (technical) solutions are still unclear. You will further develop these initiatives as you progress in your Now and Next activities.

I personally am a big fan of a combination between Now-Next-Later and an outcome-based roadmap. To me, this is the most agile and lean way to do roadmapping while still giving stakeholders a clear insight into what's happening and what is coming later.

The Random Ticket Game by John Cutler

This is not a roadmap trick but actually an insightful little game to play as a product manager / product owner. It makes it very clear how well connected your backlog is to the overall company goals.

The "game" is pretty simple. You start by picking a random user story or ticket that is currently in progress. For that ticket, try to connect it to big company goals, using the format below:

"We’re working on that ticket to [the mission of that ticket] to help us [some higher level mission], which will help us [some even higher level mission], which will help us [some even higher level mission]….(repeating)"

Keep adding the "which will help us…" to the sentence until you hit some meaningful 12–18 month company mission. If this specific ticket connects to multiple higher level goals that’s OK… Continue on each “branch” until the endpoint.

How did you fare? Do the sentences make sense? Or do you feel you were grasping at straws trying to connect to a larger company goal?

And more interestingly: how would your team members do in this exercise? Do they have the same context as you? Or are they missing the bigger picture? You could easily try this with a developer, designer or other team mate.

It can also be worth trying this brief exercise when you are dealing with new requests from stakeholders. If a request does not pass this test, it may not be worth going into right now.

Recommended podcast

Product Owner Podcast - #95 Harry Heijes (KPN)

This is a tip for my fellow-Dutchies 🇳🇱 The Product Owner Podcast is definitely worth a subscribe. Related to the roadmap topic this week I selected a fairly recent episode featuring Harry Heijes, Director/VP IT at KPN. He talks about the senior management perspective towards product management, prioritisation and working with Product Owners.

I think as a PO it's important to understand all stakeholders, and that definitely includes management teams as well. Harry made a very interesting analogy for PO's wanting autonomy. He compares this to driving a car on the road. That works very well, but only because there are clear ground rules and some restrictions. Imagine if everyone would individually choose which side on the road they would drive on…

For product professionals this means that a management team's job is to make sure you have the clear goals the company needs to achieve, and set some guidelines on how to get there. But you as a product professional need to make sure you create the solutions that will actually achieve the goals.