Putting it all Together – Creating a Lean Objective-Based Product Roadmap

This blog post is part of a series. Get started here.

Creating Product Roadmaps – Top Down and Bottom Up

You are doing your discovery, you’ve updated your product vision, revamped your strategy. You’ve come up with your product objectives and know you can’t manage on objectives alone. What next? How do you combine the top down (product vision -> product strategy -> product objectives) with the bottom up of customer problems and feedback?

To bring these all together you need to revamp your roadmap to focus on initiatives that both solve customer problems and achieve your product objectives. We’ve covered the structure of these roadmaps in detail here, you might know them as thematic roadmaps, lean roadmaps or objective roadmaps.

Your objectives are the outcomes that show you’re delivering your product strategy. In order to achieve an objective, you need to make changes to your product – these are your initiatives. While you could try to manage without a roadmap and solely with objectives, in general this is not advisable.

Let’s consider an example to clarify the difference between objectives and initiatives: Your vision is to force the enemy to surrender, your strategy is to deny the enemy freedom to operate in the area of operations you’ve been assigned. Your objectives are to deny enemy access to the area of operations, dominate the area of operations, and establish defensive positions as needed.

Let’s consider the objective “deny enemy access to the area of operations”. An initiative that achieves this objective would be “establish control of road C”. Within that initiative are various steps you need to take to complete the initiative – such as plan the initiative, conduct a fighting patrol to hill B, route the enemy from hill B and establish a defensive perimeter on hill B to provide overwatch and fire lanes on the road.

The initiatives should be described as a problem or set of problems that, when solved, will help to achieve the objective. They should be able to affect the KPIs or Key Results, which are the measures to show you achieving or making progress towards the objective.

A key point to remember here is the assumption that executing this initiative will help to achieve the objective. You don’t know if it will, which is why it’s better to frame the initiative as a set of problems or problem statements. The steps you plan to take as part of the initiative then become experiments. These experiments will test your hypotheses, that certain changes to your product will solve customer problems and move the needle on the KPIs/Key Results. This indicates progress towards your objective.

Going back to our example, you might find that once you get to hill B it is impossible to seize. So that initiative won’t work. But you find that you can seize hill A on the opposite side of the road, which still allows you to achieve your objective. You can discard one initiative for another that achieves the same objective.

As you run the experiments you gather feedback and see the impact on the metrics. This in turn allows you to adjust your roadmap to best achieve your objectives and also to continually test whether the objectives are reasonable, if your strategy is working and if your vision is achievable.

This is why a roadmap is the prototype for your strategy. It’s not set in stone, and should be adapted as you learn.

Right Sizing

It’s important to start solving problems as soon as possible, and ensure you don’t waste time building things that aren’t useful, by using smaller initiatives that are part of a bigger problem set. That way, you can test whether you’re on the right track and that the problems are worth pursuing. Iteration and measurement of outcome is the way to confirm that you’re doing the right thing.

While you confirm that the initiatives are working, your team can move on to other initiatives that address problem sets and, ultimately, objectives. The aim is not to focus exclusively on one objective and then move on to the next. Instead the aim is to move forward on all fronts, to avoid falling down a rabbit hole and neglecting the overall product strategy and vision. Delivering a product strategy is never about achieving a single objective but instead delivering multiple objectives together that combine to deliver the product strategy, and therefore the product vision.

It is the interplay of objectives that delivers the product strategy and product vision.

Your roadmap then becomes a mixture of smaller initiatives, some related, some not, targeting various product objectives.

Should you break down all the initiatives right away? No, this is where time horizons are so powerful.

Initiatives that are slated for “later” are broad and large, too big to be deliverable without further analysis. As the initiatives move from right to left, they become more granular and deliverable. Some initiatives will never progress and will be removed from the roadmap. Other times only parts of the original initiative will progress.

Assigning Objectives

Initiatives aren’t limited to one objective. Many initiatives will have more than one objective, sometimes because the objectives are very similar, other times because the initiative tackles multiple objectives at a fundamental level.

You need to be careful that an initiative doesn’t collect objectives – only add the objective if its associated metrics are expected to change. The initiative has to have some reasonable explanation (hypothesis) for why it can help to achieve the objective.

The requirement for a reasonable, causal link between an initiative and an objective is a strong barrier to featuritis. If a good idea can’t be tied back to the product strategy via the objectives then, while it is a good idea, it isn’t for your product right now. This is particularly helpful when managing expectations of other stakeholders.

When your initiative is slated for “later”, limit the assigned objectives to the strategic objectives. These are the broad-based objectives that directly spell out your strategy. As they move left into the next and now columns the initiatives will gain more tactical objectives and relevant company objectives.

Prioritization

With so many choices of initiative – some dependent on others on the roadmap, others potentially dependent on initiatives in other roadmaps, or even on initiatives undertaken elsewhere in the company – how do you choose what to do? How do you prioritize?

Prioritization often depends on your knowledge of the customer, the product, the technology, and then the business. But there are some rules of thumb you can use.

Generally, you should focus on initiatives that have a high impact and low effort. But your product doesn’t live in isolation to the wider organisation and you can’t consider initiatives in isolation from each other, so that’s probably not enough. This is where the rules of thumb come in.

Rule 1: The more disparate objectives the better

If an initiative or series of related initiatives helps to achieve a disparate set of product objectives then these initiatives should be prioritized before all the others. In this case it is important that the objectives being achieved are not related. The more related the objectives are, the less important this signal is when prioritizing the initiatives.

If you’re trying to prioritize between two initiatives that both have multiple objectives, the disparity between the objectives is an important consideration. For example, if you have an initiative with objectives of “increase users” and “reduce churn”, it could be low priority than one which has objectives like “Enter the US market” and “Increase user satisfaction”. The latter example hits two very different (and much more specific) objectives, so the return on investment is likely to be higher.

Rule 2: Alignment with company objectives

If your company or organization is using objectives, alignment of the initiatives with the company objectives is another important signal. The more the initiatives support the company or organizational objectives, then the higher the priority. However, you should remember that you need to start with the product objectives before prioritizing via the company objectives. Otherwise you end up prioritizing for the company strategy and not the product strategy. You want to achieve alignment between the delivery of the product strategy and the current company objectives.

Rule 3: Look to your dependencies

Many initiatives will be dependent on initiatives in other products in the organization or initiatives in other teams in the organisation (such as sales, marketing, customer support, security and finance). At the same time your initiatives may be a dependency for those of other products or teams. You may need to bring forward work that is needed to support others and you may need to push back your plans if the other teams haven’t finalized the initiatives you’re dependent on.

The priorities of the initiatives are indicated by the relative position in the roadmap columns. Initiatives in the “now” column are highest priority, followed by the “next”, and then “later” columns. Within the columns, the higher-priority initiatives are nearer to the top. So an initiative at the bottom of the “now” column has a higher priority than one at the top of the “next” column. However, priorities are fluid and changing company objectives, product objectives and dependencies can all mean initiatives move back and forth between and within the columns. You can’t lock your priorities and not be responsive to changing fortunes.

Summing it Up

Having started with product vision which led to the product strategy and then onto the product objectives, a roadmap of initiatives driven by the problems of customers tied to the product objectives now exists.

The initiatives that get onto your roadmap should be tied to the problems you’ve identified through continuous product discovery and tied into your product objectives. As those initiatives move from right to left they should become more defined and granular, collecting more tactical objectives and company objectives as they move left. The priority of the initiatives is indicated by the column they sit in and position within the column.

You now have a roadmap that aligns your customer-focused initiatives with both the product objectives and company objectives, showcases your priorities and helps you to communicate progress to stakeholders. As you learn more about customer problems and the effectiveness of your product vision, you will need to adapt your product strategy, keeping in mind the constant change in company objectives. The only constant in life is change – and that’s why your roadmap should not be static.