Roadmaps—Useful or legacy practice?

Key Challenges 

• The use of roadmaps to lock in delivery is counter-productive to organisations building software products that require flexibility to continually discover and gain feedback from users and stakeholders.

• Cross-departmental collaboration is not addressed by roadmaps alone and is required for successful product delivery and launch. Prioritisation discussions are a cross-departmental activity. Organisational structure often makes this challenging. 

• Product development can often become a technical or marketing led activity missing key input from stakeholders.

Recommendations 

• Use of outcome driven roadmaps that are closely aligned to organisational strategy.

• Use of Objective Key Results (OKRs) to ensure that all areas of the organisation are in alignment and working together for common objectives.

• Co-creation of roadmaps.

Analysis 

Improving product roadmaps and making them compelling is quite a common issue product managers and teams encounter. Organisations in diverse industries and maturity phases of their products and practices are wrestling with roadmaps everyday. Roadmaps are an important part of the product development process. While a product manager would never start building a solution without first understanding the problem to solve, similarly when it comes to improving roadmaps one must question the following:

1. What is the intended purpose of roadmaps? 

2. How do product roadmaps help us? 

3. Who is the target audience of roadmaps? 

When there is clarity on the answers to the above questions, tools and frameworks become easier to understand as well best practices to capture the imagination of customers. When there is clarity on the overall objective it naturally becomes quite evident who from within the organisation needs to provide input into the development of the roadmap. 

Roadmaps are a legacy from physical products 

The development of operating models led to planning processes in organisations that were typically building physical products. Physical products are more expensive to change, unlike modern software which has low change costs and is built with the expectation that it will change, progress, and pivot. As a result, these organisations adopt command-and-control models for making decisions, optimized for predictability and certainty. This necessitated the need for roadmaps that had the following characteristics:

• Roadmaps are developed from annual planning and budgeting

• They provide context for executives who make funding decisions

• Are informed by executive knowledge & upfront traditional market research/strategy 

• Are used to track progress against promised delivery

How relevant is this in organisations that are building software products? When a roadmap becomes a promise of delivery this hinders the ability for teams to continually discover value, ideate and solve emerging opportunities. Typically organisations that are using roadmaps in this way do not employ product managers but rather project managers that are tasked with delivery to an existing plan. So if an organisation is building software how should it use roadmaps and more importantly how can it prevent old habits that inhibit creativity, innovation and delivery for teams that are attempting to execute a strategy? What is more important, delivering to a plan that might be wrong or delivering outcomes that benefit your organisation? The misapplication of roadmaps is a symptom of larger problems that likely exist within the software development culture of organisations. 

The purpose of roadmaps in software organisations

Vision and strategy are arguably galvanizing artifacts that help to create alignment from the executive level and team levels across the organisation. Roadmaps, on the other hand, are a tactical tool, lower level detail that highlight how the strategy will be executed, its a higher level extraction of the backlog focusing on outcomes over feature and implementation detail that is found in the backlog. This isn’t necessarily something senior executives will be interested in but rather heads of departments. The roadmap should be used to provide visibility to ensure that the appropriate stakeholders can make necessary arrangements to support the delivery of outcomes. Examples of interested parties include sales, customer service, marketing, support, operations and finance. This is perhaps where roadmaps are being misused and are attempting to serve as a vision and strategy document as opposed to tactics to execute on a strategy. Given roadmaps are used to provide visibility to stakeholders around the organisation in service of delivery of outcomes what are good practices and frameworks to build a roadmap?

Recommendation 1 – Use of outcome driven roadmaps that are closely aligned to organisational strategy 

Having established that roadmaps are outcomes that are targeted to execute a particular strategy its imperative for organisations to be clear on what outcomes are desired. 

1. A great framework to understand desired outcomes is Jobs To Be Done (JTBD). At its essence JTBD articulates the product’s raison d’etre, what progress are users trying to make and why would they hire the product and in doing so what products would they need to fire to take up the new product. This is something that product teams are able to evaluate over time using, qualitative and quantitative data that can be gathered through research as well as existing data that could be available across a number of teams and departments within an organisation. These outcomes can then be organised in a way to help highlight the plan to meet strategic objectives in order to reach the product vision. 

2. Outcomes are not features – Features reside within a teams backlog not in a roadmap. This is an important distinction as a crucial attribute of roadmaps is flexibility. Teams need to continually evaluate the appropriate solutions to achieve the desired outcomes when solution details are unknown teams need to avoid miscommunication of features that might inadvertently create traction in parts of the organisation now expectant of particular features. There is a tendency to fall in love with features, which makes it harder for teams to move onto something else particularly if that something else is far more simple but achieves the same outcome. Hence it's best practice to stay away from features in a roadmap. Leadership and management of organisations have put extensive pressure on product teams to provide feature lists within their roadmaps perhaps as a hangover from legacy practice. Long feature lists hinder the creativity and innovation of product teams, guidance on outcomes and strategic goals are more valuable to product teams. 

3. Use of horizons – For teams that are using incremental delivery methods, the use of horizons is best suited to ensure discovery activities continue throughout the development process. The horizons used are, ‘Current, Near Term and Future.’ When using horizons it's possible to provide greater detail on the how and what for ‘Current and Nearer term’ work but for ‘Future’ activity it's better to remain at a higher level and perhaps even include learning objectives to validate assumptions. Once again leadership and management teams need to be comfortable with the ambiguity. Product teams will not know everything and what they think they know will always be subject to validation. Productive organisations are comfortable with the ambiguity and trust in a customer-centric approach to ensure bias is removed from the requirements collection and prioritisation process.

4. Collaboration and iteration over a fixed plan – Roadmaps are not a substitution for collaboration between product teams and other parts of the organisation that facilitate the delivery and launch of products. Roadmaps need to be treated as living documents that are updated regularly in close collaboration with stakeholders and anchored against strategic objectives. 

Recommendation 2 – Use of Objective Key Results (OKRs)

Use of objectives and metrics – The closer a roadmap can align to strategy the more effective it will be. The more successful organisations use Objectives & Key Results (OKRs) to ensure there is greater alignment between vision, strategy, roadmaps and backlogs. This permits teams to use hypotheses when developing products. This is a great way to involve stakeholders to ascertain how successful releases have been, there might be oversights by the team or implementation issues that require attention to achieve the desired results. In cases where results have been far greater than expected teams and departments can work together to understand if the key results outlined were under-estimated or if they have discovered greater potential that can be further targeted. 

Less is sometimes more – In a large number of organisations, roadmaps are still used to evaluate funding for initiatives. This diminishes the value of roadmaps with teams attempting to fit in as many items into their roadmap as possible to secure funding. This is where bias creeps in and a user-centric approach is lost. With the use of OKRs and horizons as outlined previously this is less likely. Leadership within organisations can help to prevent this behaviour by adopting metred funding models based on achievement of OKRs. When adopting these approaches teams become laser-focused on meeting the OKRs and not on attempting to cram as many features as possible. A feature-led approach often leads to an incoherent product with usability issues which ultimately results in complexity, loss of revenue and in some cases rewrites. Ironically, the attempt to fit in more often results in a stagnation of delivery. More features leads to more complexity and when under pressure to deliver can result in an accrual of technical debt. There is a point when the sheer number of features diminishes the user experience to the extent the JTBD is no longer clear for the user. This is usually when feature delivery stagnates as teams analyse what has gone wrong and arrive at the conclusion a rewrite is needed. This is of course is a worst case scenario but nevertheless highlights the impact of a feature race. Leadership teams should advocate for the 80/20 rule and ensure features are validated but also drive towards specific OKRs.  

Recommendation 3 – Co-Creation of Roadmaps 

Some stakeholders interested in product roadmaps:

Sales

• Marketing
• Support
• Data Analysts
• Operations 
• Customer service

This is to name but a few. What’s important is that leadership and management levels need to facilitate collaboration across departments and not isolate product development as a technology or marketing led activity. Product development is not an exact science, there will be continuous discovery, short feedback loops to get input from stakeholders as well as customers. Organisations need to be designed in a way to be as effective as possible to accommodate the ambiguity. An indication that this is not the case is when department heads and managers are surprised by roadmaps and have not been able to make the necessary organisational changes and activities to facilitate the product build. This is a direct result of product teams working in isolation of their stakeholders. A roadmap if presented to stakeholders might be too little too late, product managers need to be collaborating with the aforementioned departments and teams to co-create roadmaps and ensure the necessary timelines are realistic and dependencies are addressed. 

For organisations to be successful an expectation of cross-departmental collaboration needs to be established. Any organisational constraints preventing the effecting collaboration with these functions and product teams need to be addressed for the overall success of the product and organisation. 

Conclusion 

To recap, roadmaps are a legacy from organisations used to building physical products. They do have a place in a world of modern software development however, the characteristics of roadmaps have changed dramatically. Roadmaps are living documents, that highlight product development priorities and current thinking. Roadmaps are the outcome of cross-departmental collaboration and not the means to collaboration itself. When the organisational structure that facilitates cross-departmental collaboration is in place, and when the processes and frameworks outlined above are adopted roadmaps can demonstrate how a functional organisation can operate to create meaningful outcomes that capture the imagination of customers.