The End of Product Development Roadmaps has come — finally!
Product development roadmaps — as we know them — promote dysfunctional behavior and spark the wrong discussions. Luckily, their time is up, and the alternative is already in place.
tl;dr This post criticizes the common approach on product roadmaps that tightly couple the things to be done and the time when they shall be done. This tight coupling leads to wasteful and busy pseudo-work that does not generate any value to the user. It also generates tension within the organization, sparks mistrust, and a ‘we-against-them-attitude’. This post suggests an alternative ‘portfolio-backlog’ approach where the things to be done are no longer specific solutions but problems or objectives. The time when things shall be done is not determined upfront. Shifting that supports flow, decisions deal with value for users based on specific monitoring, and tensions within the organization are reduced significantly.
Roadmaps are common artifacts among agile product development teams out there, especially when it comes to so-called ‘scaled agile’. Roadmaps come in various sizes and forms, digitally or physically. But all have in common that they visualize planned features, product improvements, and changes mapped on a timescale. You might have recognized that roadmaps look irritatingly familiar to Gantt charts, which is a good indicator of being flawed.
Follow me on why roadmaps in the well-known representation are problematic, how we may alter the visual representation of the work that needs to be done and the collaboration around that visualization in a more functional way.
Roadmap visualizations combine what presumably needs to be done and a specific anticipated time range when that work should start and end. In that way, you display and predict the upcoming flow of work.
Artifacts are an invitation to a dialogue. In the case of roadmaps, the dialogue usually happens within the product team or with different stakeholders. Typically, product teams use the roadmap artifact to get a shared understanding of what they want to achieve soon. This dialog shall satisfy the need for orientation, preparation, and relatedness.
The discussions with stakeholders have different tonalities. There are basically two reasons why stakeholders are so heavily attracted to roadmaps. First, they want visibility on what the product development teams will work on and when something will be done. Stakeholders also want the reassurance that the teams are working on the most important items. You may interpret that underlying needs may be safety, control, and relaxation. The second reason stakeholders love roadmaps is that they want to plan and manage what they mind their business ahead of time—for instance, coping with dependencies to other business units. Maybe the marketing team wants to plan upfront when they will send out their newsletter to inform users about that particular feature on the roadmap. Again we deal with the underlying needs of orientation, control, safety, and confidence.
Why roadmaps are problematic
There are some inherent negative consequences when we use roadmaps as we know them. Let’s take a look at those consequences first.
Although created under high uncertainty after some time, roadmaps create a sense of commitment for the people involved. Most likely, those people started to map their dependencies according to the plan or make commitments to third parties. To keep the fictitious ‘commitments’ intact wasteful ’artifact maintenance’ starts creeping in. Constant re-planning and communication to stakeholders and third parties arising immediately. This is a lot of busyness without any value-adding results. Since teams are usually involved in the whole planning theatre, it reduces delivery capacity and slows down delivery.
Moreover, roadmaps tend to become relatively rigid since updating and planning cause ripple effects across the organization. More than once, I’ve experienced that whenever items are on the roadmap, the plan becomes inflexible. Inflexibility is not helpful when dealing with complexity, where fast probe-sense-respond cycles are needed. That hinders experimentation and learning in product development. People tend to accept the predefined order of items in that plan. That’s what plans are made for in the first place, right? But now, product development teams become reluctant to sincere learning since they assume that they already know the next item to deliver. With that logic in place, it becomes harder and harder for experiments to prove the current undertakings wrong. I’ve seen product owners interpret the results of their experiments in favor of the roadmap to avoid re-planning and breaking those fictitious commitments.
You might have recognized that those negative effects become almost certainly the reality in all heavyweight planning processes. Nevertheless, those effects are problematic for roadmaps as well.
The underlying problem is that roadmaps couple time and work tightly together. The mental model behind this approach seems to be that you can know upfront what will happen. I am afraid that this mental model does not suffice in a world of complexity. In a complex world, the mental model alters to “we don’t know upfront, and there is no way to change that”. If you take on that mental model, you realize that this coupling of time and work is no longer appropriate.
What artifact do we use instead?
To support open, transparent, and continuous dialogues, we will need some visualization for the work that presumably needs to be done and some relation to when it will be done. We also need to satisfy the needs of the people involved; otherwise, the alternative approach cannot be accepted. The needs we’ve mentioned above are orientation, preparation, relatedness, safety, control, relaxation, and confidence. Moreover, the alternative to the current roadmap artifact needs to cope with the complex environment we face in product development, so we need to support flexibility, adaptiveness, focus, and effectivity structurally.
The alternative I propose is to visualize discretely prioritized business objectives (what you want to achieve) or significant user problems worth solving. Those objectives and problems are not time-bound, just ordered. I think it’s helpful to add some metrics (Key Results, if you will) to explicitly define when you think you’ve achieved your objective or when you’ve solved the problem. I highly recommend sharing those objectives and significant user problems in their respective order transparently to the company, which fulfills the need for orientation and preparation.
As soon as you’ve built up the backlog of objectives and problems, you start to think about the ‘pull mechanics that need to be in place to allow a constant flow of discovery and delivery without overwhelming the teams that do the actual work. The teams signal when they can start working on a new objective or problem. Those decisions by the team can be supported by constantly re-assessing if following an objective or problem is still worth pursuing. It’s like an investment decision. Are you willing to invest more time and ‘lost opportunities’ in the objective or problem that you’ve chosen in the last round?
You pull a new objective as soon as an objective is achieved or terminated. You may also want to put an ‘expiration date’ on every objective and problem to make decision-making more straightforward when terminating a running objective. As soon as team capacity is available again, you can decide what to start next. That is the right moment to recheck your prioritized backlog, re-order it if needed, and pull the next objective, add an ‘expiration date’, and start working (working may mean discovering the right solution first). That reduces wasteful discussions about priorities if no capacity to start working is available.
Some companies are used to displaying those ‘work-flows’ on kanban boards.
Steve Tendon and Daniel Doiron suggest visualizing this process as a portfolio board. Again, this visualization distinguishes between work waiting for teams and work that is already ‘in flow’.
Using explicit work in progress (WIP) limits for committed work (definitely coming next) avoids unrealistic expectations and fosters strict prioritization. The column ‘Full-Kit’ ensures that the work can be started as soon as it gets pulled into the flow of discovery and delivery. ‘Prioritization’ is usually done by all the stakeholders (including the delivery teams) based on predefined criteria. ‘Ranking’ is done by senior executives if no definitive order could be found by the stakeholders involved.
What this makes possible
This simple ‘company backlog’ approach changes the discourse on many levels. You step back from non-value-adding time discussions and focus on prioritizing, measuring success, and learning what works and what does not. You can genuinely adapt to what’s around you since there are no long-term commitments. You can build upon your latest learning from fast feedback from your actual users. You can stay focused on the anticipated value that new objectives add to your business concerning your business strategy. This also fulfills the need for control for the teams and the stakeholders. It also creates a sense of relatedness since continuous collaboration is encouraged.
What starts gets done or is terminated quickly. This clarity also creates safety for all participants in the process. Re-assessing the current investments in a continuous cycle addresses the risk of wasting time and money. The constant monitoring allows relaxation since all the participants know where they are heading and if the pace is appropriate.
This approach also allows you to talk about systemic impediments if something hinders the smooth flow of value generation. This is by far a more valuable conversation than talking about hitting arbitrary deadlines. Since teams are no longer busy with planning, forecasting, and context-switching, it most certainly becomes evident what is blocking the flow of work.
Since you’re no longer trying to negotiate with the teams how long the work on an ‘item’ will take but instead talk about generated learning and value and whether or not the undertaking is still worth the ‘funding’, it creates clarity, confidence, and trust. Just shortly after switching to this approach, you decently understand the true delivery capability of your ‘delivery system’ and how to improve it.
The rules in this ‘process’ are simple, and the measurement of the success or failed attempt is entirely done by the team. That again adds clarity, control, relatedness and eases the long-lived tensions between ‘us and them’ (teams vs. stakeholders).
Smooth operations
To let operations run smoothly, you often need effective combinations of artifacts, roles, and meetings. Since I’ve only discussed the artifact so far, I need to spend some sentences on the other elements as well.
It is common practice for teams operating in a complex environment to inspect and adapt continuously. This requires continuous observation, measurement, and planning, which requires time to reflect and decision-making. A two-week cycle seems to be the most common way to balance the chance of delivering something of value, measure the impact, and the need for quick adaptation if needed.
My suggested approach requires constant monitoring. How else would you know that you are heading in the right direction? What you monitor depends heavily on the objective to achieve or the problem to solve and whether you are in an explicit discovery phase, an explicit delivery phase, or somewhere in between. From a perspective of autonomy and ownership, it is best if the teams that deliver the value to the users monitor themselves. The teams then share their monitoring data openly to stakeholders to support a well-informed dialogue about the learning, the progress, and the anticipated moment to stop the current undertaking.
I think this proposed approach does not need explicit roles. However, you will need a group of people who are constantly monitoring the progress/success of the single ‘items’ in the portfolio and the progress/success of the portfolio as a whole. This group of people needs the necessary context information to prioritize the portfolio ‘items’ (objectives, problems) and the authority to kill, freeze or start those items. I have good experience with a team of teams that represents the whole organization.
By applying this lightweight approach using the ‘portfolio backlog’ artifact, you speed up your operations, have more meaningful discussions, and less tension within your organization.
Common concerns
Whenever I discuss changing the current roadmap to the ‘portfolio backlog’ approach described above, some legitimate concerns are immediately raised. That’s a good indicator that some underlying needs may not appropriately be met by the alternative approach, which makes it worthwhile taking a closer look at those concerns.
But we have deadlines to meet!
This concern is typically raised by middle managers who are in a somewhat unsatisfying situation that they are held accountable for something they cannot deliver themselves. To nonetheless feel in control, deadlines seem to be a probate solution. Investigating where those deadlines come from and why they are so commonly used is valuable.
Usually, those deadlines intend to foster a quick delivery. Most of the time, those deadlines are entirely arbitrary or are created to fit into a tight schedule of dependencies (“marketing needs it four weeks in advance …”). This deadline-fallacy is rooted in the assumption that those deadlines are the only suitable way to maneuver in an ocean of demands. Deadlines often substitute the missing overall priorities and direct attention in the running process.
In the ‘backlog approach’ mentioned above, we utilize complete control over the moment when we finish work by starting the work as late as possible. What might sound counter-intuitive makes sense if you consider that the need for all the deadlines stems from way too much work in process in almost every company out there. But if you start work only when the attention is needed and the capacity to deliver in one fell swoop is available, you have a much higher chance of finishing with the right timing.
Moreover, there is the ‘expiry date’ on every ‘item’ that has been started, plus you can decide to continue or terminate a running objective based on the team’s monitoring data every two weeks. This allows you full control over the capacity available.
I admit that there are some rare cases where external circumstances create a ‘hard deadline’. You can always prioritize the objective high enough to be addressed in time in those rare cases.
But when will it be done?
Of course, there is the concern that we now don’t know anymore when the started ‘items’ (objectives, problems) will be done if we don’t map them on a calendar. I respect the need for confidence and control implied in this concern. If I am cocky, I ask how well the ‘calendar-fixation’ has played out in the past, and the answer is almost certainly “not so well”. So it might be a good idea to look the devil in the eye and accept that writing a finish date in a calendar only delivers a feeling of relaxation but does not affect delivery reliability.
“Your process is unpredictable. What you may not realize, though, is that you are the one responsible for making it that way.” Daniel Vacanty *
There are great books on that topic out there — most notably by Daniel Vacanti that deal in-depth with the question of ‘when will it be done?’ (see additional sources below). Just let me address that concern quickly. Usually, that question is raised when the delivery predictability is low. Low delivery predictability is the effect of starting work too soon and having way too much work in process in parallel. Combine this situation with almost random prioritization on all levels (executives to teams), and you get a delivery organization that is by definition completely unpredictable. I know that the question ‘when will it be done?’ is entirely reasonable in that working environment. Nevertheless, you have to address the urge for that question rather than ask that question repeatedly.
The ‘backlog approach’ that I suggest in this post deals with that question by creating a stable working environment that supports a constant flow of value. As soon as you’ve got the starting and the termination of ‘high-level initiatives’ under control, the predictability increases. Six months later, you know precisely how long working on an objective or problem takes on average.
But we have more ideas than we can start with!
That’s a critical concern. No method in the world is going to change that circumstance. We will always have more ideas than we can deliver. This is partly because we produce vast amounts of solution ideas as long as we don’t completely understand the problem.
We have to deal with that situation. One way is to quickly figure out what problems are worth solving. A whole field of research invents new ways of fast product discovery (e.g., the design thinking school of thought). And we have to prioritize strictly. I know that this is common sense, but it’s not common practice. Having all those great ideas creates the temptation of starting work too soon, which again is the root of all sorts of evil. Don’t fall into that trap, and keep practicing and improving the process.
The suggestion above shall be a good starting point.
Underlying assumptions
This article is written from the perspective of a management consultant and agile coach who has a lot of experience working with companies in a very complex and volatile business environment. The suggested approach is highly applicable to those companies. Of course, some companies out there seem to be ‘blessed’ with more stability and thus predictability. I assume that those companies don’t understand the pain I have with the common roadmap approach, and I assume that there is no need for them to think about the suggested approach.
I’ve also worked with executives and teams who aimed for a common goal and who had established a decent level of trust over time. Nevertheless, I’ve experienced businesses with a lot of tension, mistrust, and isolation between teams, departments, business units, and their respective management. The alternative approach described above will not run smoothly on that suspenseful ground. However, working together may form bonds and help overcome the tension that is evident in some working environments.
Let me know how you handle your portfolio and if you’ve ever struggled with your roadmap!
Further sources
- Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects — by Johanna Rothman
- Tame Your Work Flow — by Steve Tendon and Daniel Doiron
- Actionable Agile Metrics for Predictability — by Daniel Vacanti
- When Will It Be Done? — by Daniel Vacanti
- Accelerate Your Enterprise Business Agility Journey — by Sally Elatta
- Team of Teams: New Rules of Engagement for a Complex World — by General Stanley McChrystal, David Silverman, Tantum Collins, and Chris Fussell
- Dual Track Development is not Duel Track — by Jeff Patton
- Starting late — The Superior Scheduling Approach
- Delivering sooner by starting later
- Simulating the Negative Consequences of Multitasking on Flow, Throughput, and Value Generation
- Mit cross-funktionalen Führungsteams zu effektiven Veränderungen
