Split Product and Engineering Roadmaps, an anti-pattern

Explore the pitfalls of separating tech and product roadmaps and discover how unified planning enhances team efficiency, fosters better prioritization, and leads to overall company success.

Apr 10, 2024

A common challenge for Engineering Leaders is the need to balance product improvements with technical work: maintenance, refactoring, version migrations, etc.

Following a LinkedIn post that attracted a lot of attention, I've decided to write an essay to share my thoughts on a common anti-pattern I've observed: tech roadmaps separate from product roadmaps.

Understanding the phenomenon

The story often goes like this:

✅ A team focuses entirely on quickly iterating on the Product in search of Product Market Fit

✅ During this period few efforts are spent on code maintainability, security, scalability, etc

📈 At some point, the company starts to grow and all those non-concerns suddenly become real problems

🤔 The Engineering leadership is now presented with a new challenge: how to find time to address those problems as the roadmap is filled up completely by “product” items?

I’ve seen Product and Engineering teams become very creative at this stage.

As this is a new problem and people often feel they lack the time to think it through, they often end up choosing convenience over effectiveness.

This leads to solutions that are built around avoiding rather than facing the difficult prioritization decisions between product and engineering.

Common examples include variations on the following:

You reserve x% of the team's capacity for “Tech Stuff”. This number is often in the lower 2 digits, usually around 20% or 30%.
For every X iteration (sprint, cycle, etc) you do one full iteration on “Tech Stuff”.
You come up with a Tech Roadmap, and no clear plan on when to execute it
You create a sub-team that only focuses on “Tech Stuff”, a team that has no product counterpart.

All these attempts originate from good intentions, yet I think they miss the key point of prioritization.

As such, I believe they are all expressions of the same flawed approach, thus anti-patterns.

One Team, Two Roadmaps, Three Headaches

Except for the sub-team approach, they all tend to fall into the category of having one team with two different roadmaps.

This might sound great on paper because it provides both the Product and Engineering leaders with their own space to get stuff done.

No more fights! No more discussions!

Why don't we stop talking to each other's altogether?

Jokes aside, I believe that this category of approaches focuses too much on optimizing for the leaders’ comfort and convenience, at the expense of company results and the team's effectiveness.

I like to group their side effects into three types of headaches

Sub-optimal prioritization
Promoting Context-Switching
Creating tension in the team

Let's see them in order.

🤕 Sub-optimal prioritization

The aim of prioritization is not simply to have one or more lists of priorities.

Good prioritization is achieved when you have the right priorities.

Let's take the example of a team that allocates 20% of its capacity to technical initiatives.

How do you know that the activities they'll be working on as part of that 20% of their time are more important or higher priority than any of the non-technical activities that didn't make the cut for the remaining 80%?

And please don't start with the usual "they'll always prioritize short-term revenue" rant.

It's your job to be able to articulate the importance of initiatives that don't directly correlate to short-term revenue numbers. I've written extensively about this in another article, which is referenced at the end of this article.

Conversely, how do you know that all the product initiatives that make up the 80% bucket are more important than the initiatives that didn't make it into the 20% bucket?

Maybe you need a quarter or two where you spend 30%, 40%, or even more on technology initiatives because those are the ones that will give you the best return on investment.

In other words, if you have separate roadmaps, you are optimizing for the local maximum.

The Theory of Constraints has shown how this usually leads to sub-optimal results.

There is a reason why all the different flavors of Agile focus on the idea of a prioritized backlog, where no two items have the same priority. At any given time, you should have one and only one clear priority for your team.

I've recently learned something very interesting about the word priority. It came into the English language in the 1400s. It was singular. It meant the very first or most important thing. It stayed singular for the next five hundred years. It was only in the 1900s that we pluralized it and started talking about priorities.

I'm not trying to say that it was better in the old days, but perhaps there is a lesson there for how we approach prioritization in this context.

🤕 Promoting Context-Switching

Human brains do not work like CPUs. We are very inefficient at multitasking because jumping from one context to another takes a lot of mental energy. We are much more effective when we work sequentially.

Because teams are built by people, this is also true at the team level.

A team that tries to work on too many things at once tends to have a higher cognitive load, which ultimately undermines its ability to make a lasting impact.

As a leader, you are responsible for the team's results and the well-being of its members. As such, you should strive to minimize the number of context switches they need to make on a daily basis.

Instead, separate roadmaps and percentage time allocations between them promote a division of attention, both at the team level and at the individual level.

They may force people to switch back and forth between different contexts because the bell just rang and we're not in the 20% tech time.

They will also encourage the idea of having a lot going on in parallel, with team members working in isolation, each on their own thing, which defeats the purpose of having a team in the first place.

🤕 Creating tension in the team

We all know that estimates aren't accurate predictions of the future.

More often than not, projects take longer than originally estimated.

Daniel Kahneman wrote extensively about the planning fallacy in his famous book Thinking Fast and Slow. In his research with Amos Tversky, they demonstrated the tendency of individuals and organizations to underestimate the time, costs, and risks of future actions.

We tend to be overly optimistic in our estimates in general, and we have plenty of evidence of that by now.

What's interesting is that whenever something takes longer than expected - and that happens a lot - you are required to make explicit tradeoffs.

When you have two separate roadmaps for product and technical initiatives, every single tradeoff becomes a source of tension within the team. Because you have not done the work upfront to define relative priorities, every unexpected situation requires you and the team to make ad hoc decisions.

These ad-hoc decisions tend to be stressful and distract the team from the work they're supposed to be doing: building things. They tend to create a lot of waste. Decisions that may end up sacrificing items on the technical agenda - which is often the case - are often perceived as setbacks by the team.

Some might argue that too much up-front planning is Waterfall and that a true Agile approach requires you to favor just-in-time decisions.

This is only partially true, as there is a clear difference between chaos and agility. If every little bump in the road requires long discussions and debates, you're not being agile, you're being haphazard.

Work upfront is very important to set the right priorities and a system to deal with priorities effectively.

Having separate roadmaps is a perfect recipe for the opposite.

☝️What about the sub-team approach?

All the headaches mentioned above cover the one-team, two-roadmaps case. The other approach I mentioned is to create a sub-team within the existing one to focus entirely on technical projects. The first temptation is to call this team a platform team, for lack of a better term.

In an earlier article, I covered some of the pitfalls I see when teams are mislabeled as platform teams, and you can find it in the reference section.

Here I'll only cover what's specific to the discussion at hand.

First, platform teams have several costs and implications that are often underestimated. By creating a platform team, you introduce an external dependency. This will make it harder, not easier, to plan and prioritize because you'll have more people to align with and more requests to compete against.

Platform teams, when operating effectively, will increase the overall throughput of the organization, while the latency of responding to a change request will likely increase due to the additional overhead.

If you introduce this separate team to simplify planning, you will likely end up with the opposite result.

Maybe you didn't want to create a full-fledged platform team, just some sort of technical team focused on delivering the technical roadmap in isolation.

You will still face the same planning and coordination challenges.

Changes in the underlying technology will require the "product team" to invest a non-trivial amount of time in migrating, refactoring, or other activities required to take advantage of the improved underlying solution.

And then you're back to square one: finding a way to align priorities and roadmaps, only now you have to do it across two teams.

Finally, technical debt management should be the responsibility of every single team and every single engineer.

Having a dedicated team take care of it is akin to having certain teams focus on building features and other teams focus on fixing bugs.

It creates the wrong incentives, and it's an eerie reminder of the throw-over-the-wall approach to delivering software that predates the advent of DevOps principles.

Don't treat the symptoms

I think in most cases where teams end up with a separate technology roadmap, it's because they're focused on treating the symptoms rather than the root causes of difficult planning.

If you can't agree on a single roadmap for your team, it could be due to a combination of factors, such as

You're too focused on the short term, so you choose the "easy" solution that allows you to kick the can down the road while feeling good about making progress.
You and your product counterpart are not working well together. You may say they "don't understand" why certain things are important. They may say you're speaking a language they don't understand. These are all signals that the relationship is not where it needs to be. As long as it is, your team will suffer the consequences.
You may simply dread the idea of having to spend long hours planning with other people, and your brain may trick you into finding workarounds that save you from short-term pain.

I would recommend that you spend some time identifying the root causes in your case, and then decide what the best approach should be going forward.

Focus on solving future problems rather than short-term pain, and you may be on a very good track.

🏁 Conclusion

Today we looked at why I consider tech roadmaps separate from product roadmaps as an antipattern, and we looked in detail at the consequences of choosing this type of approach.

If you're in this situation, there is one useful question you can ask yourself:

Are you promoting the idea of a separate tech roadmap because you think that's the best approach, or because it makes your life easier in the short term?

Be honest with yourself, and if you still believe that this is the best approach, then you'll be able to back it with strong arguments. 👏

If that's the case, I'd be very curious to know more about them, as I always like to engage with different perspectives. Please share your thoughts in the comments section 💬

Thanks for reading and see you next week