The Roadmap Noose

Note: this article was originally published on 25th July 2016

If there’s one thing product managers love, it’s a roadmap. It can become a framework for a team to deliver amazing products, offering clarity and structure to the product vision. But roadmaps can also become a metaphorical noose around a product teams neck when it’s fundamentally created to set dates. Quasi roadmaps-cum-project plans don’t work for a number of reasons, but principally it’s as we’re horrible at estimating the time taken to perform a task.

As a product manager, it’s easy enough to ratify. Simply open your roadmap from this time last year and cross-reference what you thought you’d launch last year, and what you actually launched. This time last year I was fresh-faced in a new role and predicted we’d build a fully transactional app on never-used-before APIs within 4 months, and by the end of the year, we’d have taken the app to 3 new markets. In short, I was shooting for global dominance. In reality, we launched the app within 6 months and spent the rest of the year building out features and functionality in the app without taking it to a new market. Despite the chasm between the initial roadmap and reality, I firmly believe the whole team can look back with pride on what we collectively achieved.

If this is the case, that our plans and realities often differ, then why do we subject ourselves to this planning ritual?

Modern businesses want to harmonise strategic planning with agility, but falsely see roadmaps as a set of promises and commitments to delivery as opposed to a guide to the strategic direction of the product. For businesses to be truly agile, they need to accept the unknowns in the world. This is juxtaposed with the traditional view of roadmaps though, and therin lies the problem.

Roadmaps are often a mere reassurance for the business that a product team is focused on the right challenges. It’s not unreasonable for a business to want to understand what it’s potential product pipeline looks like, especially considering the financial implications this has. Businesses need financial predictions which often hinge on product launches and improvements. Given the financial pressure, it’s easy to see how the traditional view of roadmaps has developed, and why product managers are continually asked to produce them.

So given roadmaps offer value, it’s important to understand why they’re so often wrong.

History is littered with examples of human overestimation of the time needed to complete a task; arguably, it’s an inherent flaw.

One of the popularist theories on the matter comes Daniel Kahneman and Amos Tversky (1979) and their ‘planning fallacy’. Kahneman and Tversky theorised that predictions about how much time will be needed to complete a future task display an optimism bias, which research proved to be true. This phenomenon is true for both group and individual tasks, and across all industries.

For example, take the construction of the Sydney Opera House. According to original estimates in 1957, the opera house would be completed early in 1963 for $7 million… a scaled-down version of the opera house finally opened in 1973 at a cost of $102 million (Hall, 1980).

The Channel Tunnel faced similar issues. The builders predicted that the first trains would run between London and Paris in June 1993. The train ran in May 1994. The tendency to hold a confident belief that our own projects will proceed as planned, even while knowing that the vast majority of similar projects have run late, is the planning fallacy.

Rooted within the fallacy is the concept of wishful thinking:

Wishful thinking is the formation of beliefs and making decisions according to what might be pleasing to imagine instead of by appealing to evidence, rationality, or reality.

Sounds like a roadmap you’ve seen, right?

This is grounded in a self-serving bias, where we construct our previous experiences to reflect best on ourselves. We may take credit for tasks that went well and blame delays on outside influences.

This is most evident when creating roadmaps and estimating the time to completion. When assessing how long a task will likely take we try and relate it to similar tasks previously completed. Research found that people usually focus on previous occasions that justify an optimistic outlook; we almost never focus on episodes when we’ve encountered problems or failed to finish tasks as expected (Buehler et al., 1994).

The fable of deadlines is now popular in modern culture, with quotes and memes-a-plenty:

“I love deadlines. I love the whooshing noise they make as they go by.”

Douglas Adams, The Salmon of Doubt

So, we know roadmaps are required and can be useful, but we’re not great at estimating the time taken. What’s the solution then? We think we’ve found it.

After much pondering, procrastination and pizza (and a healthy dose of reading from our peers), we’ve changed our roadmaps to better serve all outcomes. We now prioritise themes into Now / Next / Later buckets. The Now bucket constitutes of the things we’re working on right now. The next bucket…you got it. It’s the stuff we’re working on next. And the later bucket usually contains big, meaty ideas that we’re not ready to work on anytime soon, but are important.

This allows the team to have a clear focus and ends debates about products and features that are months away. This provides the business with the reassurance that the product is moving in the right direction, and gives the product teams enough freedom that they’re solving problems rather than building out-of-date solutions proposed in a roadmap 12 months previous.

We can still talk about dates when required, but these are separate to the roadmap. The roadmap servers a clearer purpose this way; it provides tangibility to the product vision and provides a framework for success.

The first mention I can find online explaining this way of working comes from Noah Weiss here. It’s worth a read.

Here was our first stab at this, using Artefact Cards:

I feel liberated just looking at it.

How this will pan out in the long term at Travelex is yet to be seen; early feedback from Product, Design, Engineering, Marketing and our commercial teams has been positive, as has the reaction from the rest of the business. Time will tell if the idea sticks, but for now the metaphorical noose has been laid to rest and our teams are revelling in the freedom.


The original now/next /later post from Noah Weiss is here >

If you’re looking for a tool to help with this model, ProdPad is worth checking out >

This presentation from Janna Bastow offers a different view on this format and other facaets of roadmaps >

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Up ↑

%d bloggers like this: