Red Vs Blue Roadmaps: Why Most Roadmaps Suck

The Tax of (False) Predictability

There are two kinds of roadmaps as a Product Manager:

1. Roadmaps that make your job easier

2. Roadmaps that make your job more difficult

As you’ve probably already experienced as a Product Manager: most companies have roadmaps that make your job more difficult.

Sometimes it’s so bad how the company does roadmapping that it makes people want to quit. I’ve been there and got the t-shirt. Think meetings about meetings, slow and ineffective decisions, and lots of unnecessary up-front legwork that only undermines our ability to do our job.

If we want to understand why roadmaps frequently suck and what the difference is between Blue and Red Roadmaps, we must first talk about Penguins.

The Penguin Principle For Roadmaps

Adélie penguins mainly inhabit the continent of Antarctica and nearby islands. You often see these penguins huddled together in dense groups near the water. Every penguin is reluctant to enter the water and waits until an unlucky individual (accidentally) falls in the water.

When the water surface stays calm and doesn’t turn red, the coast is clear. Other penguins rush to jump into the water to hunt for food. When the sea turns bloody red, it means sharks, leopard seals, or killer whales are around.

When they see blood, The penguins then decide it is better to stay on the ice and wait until the danger has passed. Most companies have bloody Red Roadmaps filled with sharks, leopard seals and killer whales that make your job as a Product Manager more difficult.

The Penguin Principle:

“Your roadmap exposes your organizational flaws. The more bloody red your roadmap becomes, the more sharks and internal obstacles are present in your organization that can make delivering the roadmap nearly impossible.”

The more internal obstacles your roadmap contains, the more red it becomes. Red Roadmaps are inside-out: they expose our internal organizational struggles and are optimized for the logistics of our organization - overcoming the internal struggles we’re facing.

You can easily spot Red Roadmaps because they usually have the following characteristics:

• Operationally taxing (big room planning, PI planning, release trains and other nonsense)

• Slow decisions

• Push work to the teams

• Solutions

• Coordination

• Cannibalization & Unproductive Conflict

• Operationally expensive

• Plans resistant to changes and lots of politics

Some companies, usually with lower organizational complexity like start-ups and scale-ups, have Blue Roadmaps that are strategically taxing and operationally easy to produce and adjust. Blue Roadmaps are outside-in: they expose our struggles with solving real-world problems. and are optimized for helping teams make decisions based on the latest and best information.

You can easily spot Blue Roadmaps because they usually have the following characteristics:

• Strategically taxing

• Fast decisions

• Teams pull work as real-world capacity permits

• Problems

• Collaboration

• Creative Conflict

• Humble and emergent plans inviting possibility and curiosity

Why do roadmaps turn bloody red, and what can we do about it?

The Tax of False Predictability

Most companies want things to go according to plan.

Delivering as planned is what gets you promoted. Stakeholders flash beaming smiles at you and pat you on the shoulder for a job well done.

Half-baked plans are a considered a sign of incompetence, but what if I told you that half-baked plans can actually be a sign of competence? Plans that look great on paper are actually the plans that should worry you the most, at least in the context of software development.

Let’s explore the tax of false predictability by talking about neural networks. What’s counter-intuitive about predictability is that by trying to completely eliminate the risk of failure, we can exponentially increase our risk of failure.

This can be explained much better using the Plasticity - Stability Dilemma that applies to Neural Networks. Let’s say you work at a company that develops a neural network that can detect whether a hot dog is present in an image. They want to update the image model to also be able to detect hamburgers.

To be able to learn through new information, the model must exhibit plasticity. Plasticity is what allows the neural network incorporate new information to detect hamburgers. However, a model must not only have plasticity, it must also remain stable. Stability is what allows the model remember what it learned in the past about detecting hot dogs.

If the model exhibits excessive plasticity, then it will no longer work for detecting hot dogs. If the model exhibits excessive stability, then it will only work for detecting hot dogs.

In a nutshell:

• Plasticity: you want the system behavior to learn and change from significant events

• Stability: You want the system to remain unaltered by insignificant events

How do plasticity and stability relate to planning and predictability?

Organizational systems exhibit the same kind of characteristics as neural networks. I call it the Predictability - Adaptability Dilemma.

The Predictability - Adaptability Dilemma

On the one hand, companies want predictability. Teams must limit surprises, foresee the unexpected and deliver exactly as planned. Companies that want predictability, often focus on Front-Loading decisions. They spend lots of time to nail the plan before starting the work.

On the other hand, companies want adaptability. If the unexpected happens, the teams must deal with it as necessary or maybe even turn it into an opportunity. Companies that want adaptability spend more time on Backloading Decisions using humble and emergent plans. Doing planning as it’s necessary when better information becomes available.

Adaptability and predictability are inherently at odds with each other. As I’ve expressed in the past:

“The more we try to prevent sucking at predicting, the more we will guarantee to suck at adapting.”

We can visualize the Predictability - Adaptability Dilemma as follows:

Red Roadmaps are optimized for predictability. Blue roadmaps are optimized for adaptability. I want to stress, both Red and Blue Roadmaps require extensive planning. The key difference is the type of planning and when the planning takes place.

The redder your roadmap, the more you’re planning like all the cards are already on the table. Red Roadmaps are taxing to create and focus on operational planning. Red Roadmaps are great if what you’re doing is highly predictable, you have lots of internal obstacles, and innovations isn’t important.

Blue Roadmaps are optimized for adaptability. The bluer your roadmap, the more your back-loading decisions until a later point of time when there are more cards on the table and you have better information to make a decision.. Blue Roadmaps are strategically taxing: lots of thinking is required to keep our plans emergent and decide what decisions we can postpone to the last responsible moment. Blue Roadmaps take into account reversibility and optionality when making decisions.

Blue Roadmaps are great when what you’re doing is unpredictable. You expect to encounter many surprises and you want to innovate. You focus on keeping your roadmap focused on the real-world challenges you’re trying to solve in a novel way.

Blue Roadmaps Aren’t Better Than Red Roadmaps

Blue and Red Roadmaps exist on a spectrum. Organizations may work in a way that exhibits characteristics of both roadmaps. The crucial thing is that you work in a way that fits in your situation.

If you have a Blue Roadmap, even though what you’re doing is highly predictable, then you end up in the following situation:

caption...

You are underfitting your plans and not thinking enough steps ahead. This can create huge operational waste and sometimes may even make rework impossible. You should spend more time on planning and making sure you create adequate plans that are operationally taxing.

If you have a Red Roadmap even though what you’re doing is unpredictable, then you end up overfitting your plans and thinking too many steps ahead. This creates huge operational waste and sometimes may even make rework impossible as well.

Red Roadmaps Should Be an Intentional Choice

Most larger organizations have Red Roadmaps, not by choice, but because the Penguin Principle comes into play: the roadmap exposes their organizational flaws. They are thinking lots of steps ahead not because the problem they’re solving demands it, but because it’s necessary for their organization to function and deliver anything at all.

These are the kind of companies that use Scaled Agile Framework (SAFe). As long as they keep on using SAFe, they will never fix their problems. SAFe is optimized for Red Roadmaps and operating in an inside-out manner which will won’t allow innovating and dealing with uncertainty effectively.

Most smaller organizations have Blue Roadmaps, not by choice either, but because they have extremely few organizational obstacles to overcome. The natural tendency then becomes to make your roadmap in an outside-in manner, so you’re better able to deal with the real-world challenges you’re facing.

But small organizations become big and as organizations become bigger and the kraken (internal bureaucracy) grows, their roadmap will naturally become more red.

The important you should be asking yourself: do we have a Red Roadmap because what we’re doing is highly predictable and not innovative, or is it red because we simply trying to survive and deal with our internal obstacles?

If what you’re doing is unpredictable and uncertain, then you should work on fixing your organizational struggles, because focusing on predictability will actually make you less predictable by cannibalizing your adaptability.

Remember in the context of complex work: the more you try to prevent sucking at predicting, the more you will guarantee to suck at adapting.