Roadmapping

Introduction

The importance of roadmapping for successful product development

One of the things we share as product owners, is the countless and countless times we are asked: “Can you please put this or that on our roadmap?”, or even better: “In which quarter (or even sprint) is this feature on our roadmap?”. While these are valid questions in a product context, they overlook what a roadmap actually is. There are so many misconceptions about the purpose of a roadmap, its form and its position among all other product management artifacts in the organization that it can be very difficult for you as a product owner to choose the right approach.

The 3rd edition of our Product Owner Circle focused on unraveling all these misconceptions and offering concrete tools with which you can be more successful through the right creation and use of roadmaps.

Guiding product development and measuring success

A roadmap is more than a prioritized list of features. When the roadmap has been created correctly, it becomes a strategic document that aligns with the mission, vision, short-term goals and long-term goals, providing direction to the product development organization. However, let's start from the beginning...

Company vision, mission and product vision

In software scale-ups, having a clear company mission and vision is the cornerstone of success. The mission outlines your company’s purpose and values, serving as a guiding star for all stakeholders. It tells everyone in the company why we’re doing what we’re doing. Vision, on the other hand, paints a picture of the future state, providing direction and motivation. Mission and vision are sometimes combined into one guiding statement.

The company vision informs the product vision, ensuring alignment with broader goals. And the product vision in its turn, translates the company's aspirations into tangible products. A well-managed interplay between these visions enables you as a product owner to create a roadmap that resonates.

Although not set in stone, note that visions must be fixed for as long as possible. Strategies, however, are adaptable and reactive, driven by factors like new knowledge and market behaviour. Many frameworks will serve you well when translating vision into strategy and plans. At 25Friday, we like the simplicity of the OKR framework.

Turning mission and vision into strategy by defining OKRs

Setting objectives and key results (OKR) has proven itself as a great way to steer software startups toward success. By defining ambitious and inspiring, objectives and quantifiable, timebound key results, you create a strategic framework that effectively provides alignment and motivation while closely measuring progress. OKRs thus not only guide development but also foster a culture of keeping focus, propelling your company toward sustainable growth. Note that OKRs are time-bound and can be applied to different time spans; e.g. the company might define a structure of yearly company OKRs as a guidance framework for the quarterly OKRs that are set by teams individually.

In the first quarter using the OKR framework, objectives may not be fully met as teams are adapting. Don’t be surprised. We have seen many of our customers fail at their first attempt to successfully use OKRs. It is essential though, to make sure that the teams as well as the leadership hold on to the framework after this somewhat expected setback. Introducing or strictly enforcing a framework like this means organizational change. And it’s the people in the organization that are changing, not the organization itself, so don’t rush into conclusions too soon. Over time, as the framework becomes ingrained in the company culture, teams will surely improve their focus and goal achievement.

Now that you have a clear picture of what you want to achieve and when, it’s time to start setting up your product roadmap.

This article summarizes our Product Owner Circle on roadmapping in a product-led organization, which took place in May 2023.

Roadmap Realisation and Prioritisation

Why you need a roadmap

A roadmap serves as a strategic document. It outlines priorities and milestones essential for achieving the objectives and, consequently, realizing your product. An important - if not the most important - goal of your roadmap is to provide your team, your stakeholders and the rest of the organization with a clear sense of direction and vision fostering alignment.

Prioritization of work

By creating a roadmap, development teams can effectively prioritize their tasks. They can separate features, improvements, and fixes that need to be addressed now from the ones that may be handled later, enabling resources to be allocated efficiently and minimizing bottlenecks.

Communication

Roadmapping also facilitates effective communication, both within the development team and with your stakeholders. It helps manage expectations and enables teams to transparently communicate progress, challenges, and plan adjustments. This transparency builds trust and promotes a sense of ownership among team members, leading to more motivated and engaged employees. Depending on the role and context of your stakeholder, you might even want to tailor the roadmap to specific needs, by adjusting the level of detail or focusing on e.g. dependencies rather than the items themselves.

The process of product roadmapping

How to get from objectives to roadmap items

Before we continue, you must understand that there is no point in even thinking about roadmap, if there’s no company-wide consensus about objectives. So, if you've made it this far and there's even the slightest suspicion of misalignment, don’t waste your time and go manage your stakeholders. It’s really a matter of garbage in = garbage out here. But let’s assume that all this is set and done. The first thing you want to do is get together with your stakeholders to try and figure out how the objectives you all agreed upon could be achieved, within the given timeframe (e.g. quarter). This will result in lists of jobs to be done and features or enablers to be implemented.

Depending on the size of your company, you as a Product Owner can take the lead in this process or leave this up to someone up the chain. Also, there’s the question of who to involve. Some companies are open to a cross-team exercise, while for others a per-team approach may work bettter. Look into different brainstorming techniques and choose what you think fits best. For larger scale-ups, borrowing the “Quarterly planning” principle from the Scaled Agile Framework (SAFe) could be really helpful.

Prioritizing roadmap items

Once you know what needs to be done to achieve your objectives, it’s time to prioritize. After all, you want to invest your time and resources first into delivering things that offer the most value to your customer in the shortest amount of time.

One way to prioritize items is by categorizing them into Must-haves, Should-haves, Could-haves, and - if you like - Won't-haves, following something called the MoSCoW method. Another method is to also look at what will make users really happy (delighters) and what's essential (basics), using a model called the Kano Model. Unlike MoSCoW, this model also takes the investment that implementation requires into account.

A third option is the RICE model, which stands for Reach, Impact, Confidence, and Effort, along with Weighted Scoring. These tools help measure how many people a roadmap item will affect, how important it is, and how difficult it will be to build.

Value vs. Effort

At 25Friday we like to use a combination of value and an estimation of effort. Your starting point is the list of items that resembles everything that needs to be done to achieve your objectives.

1. Assign Value Scores: for each item on the list, assign a value score. This score should reflect the perceived value that the item will bring to your product. Factors to consider when assigning value scores can be: customer impact, revenue potential, strategic alignment with goals, and user feedback. Be sure to involve stakeholders to gather their input on the value of each item.You can make this as complicated as you want by e.g. weighing the scores against the hierarchy of objectives that an item aligns with. However, for first use, we recommend keeping it simple and just using a numerical scale (e.g. 1 to 10).
2. Assign Effort Scores: evaluate and estimate the effort required to execute each item. The effort can include various aspects: development time, design work, testing, and any other resources or dependencies needed. Again, use a numerical scale to rate effort and for first use, you might want to start with just development time. It is essential to involve your team members or ask subject matter experts to provide accurate effort estimates, as without this, your roadmap loses support among those who were supposed to carry it out. The more senior a team is, the easier the process of assigning effort scores will become. If your team is reluctant to provide concrete estimates, using T-shirt sizes (to be converted into quantitive scores later) might be a way to overcome this hurdle.
3. Calculate the Value-Effort ratio: now, calculate the value-effort ratio for each item by dividing its assigned value score by the effort score. This ratio tells you which items provide the most value relative to the required effort. Visualizing the result in a value-effort quadrant has proven itself to be a great way to make your stakeholders understand the outcomes. The formula: Value-Effort Ratio = Value Score / Effort Score
4. Prioritize and create the roadmap: as a last step, prioritize the items based on their value-effort ratio. Items with the highest ratios should be placed at the top of your roadmap, meaning that they should be executed first.

While this method seems to provide you with a click-and-go roadmap, be aware of other factors, such as market conditions and resource availability, that may also influence your prioritization decisions. Review the output with your stakeholders, be flexible, and adjust your roadmap as necessary. It’s never set in stone.

Roadmap timespan

In our opinion, a roadmap covers a timespan of two quarters maximum. Generally speaking, roadmaps that look more than two quarters ahead, tend to be subject to radical change and thus lose their value. Moreover, scale-up companies often set their objectives on a quarterly basis, and looking ahead two quarters is difficult enough already. That does not mean however that you should not or cannot make a long-term roadmap: going beyond that 6 month line is still possible and can be crucial for some stakeholder groups. Keep in mind though, that the the part after the first two quarters will be less fine-grained. In other words, the further you look into the future, the more high-over the roadmap items will become.

Conclusion

1. Roadmaps need to be goal-oriented and tightly connected to the product strategy
2. Roadmaps can have many practical forms and lengths, tailored to a specific audience or purpose
3. Roadmaps are shared and commonly understood by their audience
4. Roadmaps are agile and need to be kept up to date constantly
5. Roadmaps resemble a plan, not a planning
6. Underpromise & overdeliver

Adapt and improve

By integrating the methods above into your everyday practice, you will not only improve your individual performance as a PO but also drive the success of your product to the next level. As with the development of your product, your approach must be based on effort and impact, and trying to improve all at once may be a long shot. So analyse your own daily practice and take a close look at what is already going well and what leaves room for improvement. Try to pinpoint where you can achieve a big effect with only little effort.

If you need advice or help with implementing your new way of product roadmapping, don’t hesitate to reach out! We’re happy to help.