What is wrong with the feature-based roadmap?

Most of the time, we build features to fulfill some goal that we measure using some kind of metrics or KPIs. Human nature favors stating what needed to be done and the “how” which makes feature-based roadmap favorable for teams and leadership teams.

I’ve also noticed that people identify features first, and then do some research to measure the impact, and most of the time, the impact is acceptable.

Is delivering a feature considered a goal?

Well, it is debatable. In my experience, delivering a feature was never the goal. Solving a problem was. So why most organizations, at least most of the ones I worked with, favor feature-based roadmap: delivering a feature as the goal? Simply it is easier to communicate to stakeholders and customers, internal and external. It is easier also to predict when it is going to be delivered and what to expect. Outcomes, on the other hand, might not be as straightforward, especially if your organization is not strong at setting goals (Goal Muscle)

That said, delivering a feature could be considered a SMART goal, it is specific, measurable in the fact that you can tell if it was delivered or not, attainable within a specific timeframe, it is relevant to your roadmap, customers and stakeholders, and it is timely.

While delivering a feature or a product could be a SMART goal, in product management, and even in other types of teams, this SMART goal is not enough for a highly effective team. Product Managers usually add other things to assess the success of a feature, but it is not directly associated with the feature goal, like KPIs/metrics

The What and the How

In building a feature, you can tell yourself that this is the what, and let the team figure out the “how”: architecture, design, technology selection, etc. For example:

Goal: Build a new feature to allow users to group starred google documents together in a bundle and share them. Everyone is asking for it and it seems the right investment right now. Some product teams might do some research and test the validity of these assumptions. Let’s do some reverse engineering here using the 3WhysTree

The 3WhyTree uncovered some of the underlying reasons why you want to build it, now take the most relevant answers to the 3WhyTree, probably to the ones to the far right of it, and work backward, would building the Starred Bundle be the best solution to achieve that outcome? I would argue that it is not. There might be better solutions and maybe cheaper ones to get to the same outcome. Outcome? Yes, it is not clearly defined when it says: let’s build the feature unless you add some sort of KPIs to measure the success, but would you use that to validate the idea? Test if you can get to the KPIs before you build it? Or would you build it and then measure?

Starting with the outcome will force you to quantify it, this will shape the solution and will enable your team to be creative to exceed expectations or needs, feel fulfilled, and own the problem and the solution.

Start with the Outcome

Let’s revisit our google docs example, how would you start with the outcome? OKRs Brainstorming Canvas can help with that. You start with the Objective, then brainstorm and research all the ideas that might get you to the outcome, including the lag measures (Outcome is your lag measures in this case). The lead measure could be the feature(s) you want to build to achieve the outcome.

So what is the OKRs Journey Compass

It is the Outcome-based roadmap with a fancy name. Instead of listing the features you want to build, list the outcomes you want to achieve then add the potential features as part of the KRs: Launch feature X and Y. You can use the Features section to list more features needed to achieve the outcome but they are not the highest value ones. Here is the structure:

For brainstorming, I usually draw four lines on a big whiteboard and use markers to help the team brainstorm ideas. A better way is to use sticky notes so that you can move things around.

It is going to be difficult to think in terms of outcomes if you are new to OKRs and if you are comfortable with the feature-based roadmap. The Compass above will help you overcome that, simply start by filling in the feature sections first, then ask yourself (and your team), what is really the outcomes? Try to be open-minded and evaluate if the desired outcome is achieved by the features you listed. It is easy to get biased and you will be tempted to confirm that the features you listed are the right features for the desired outcome.

Please remember that your key features should be part of the Key Results (KRs). By definition, meeting all of the objective KRs should mark the objective as done/complete.

Note: Date/Cycle row could be granular, maybe a sprint, or as high-level as Now, next, and long-term

Why Outcome-based Roadmap

The feature-based roadmap is easier to construct and communicate, Outcome-based roadmap, or as I call it: OKRs Journey Compass is more impactful at all levels:

Enable creativity and innovation at all levels. This will give you access to a tremendous pool of IQ, creativity, and innovation.

Improve autonomy and moral

Impactful organization

Create amazing results

Improve ownership especially if you allow team members to contribute to some of the KRs if not all of them.

You can still specify the lag measures in the KRs and ask the team members to collaborate to come up with the rest of the KRs, it is up to you, but it will take time to find the right balance.

The OKRs Journey Compass tells a story, not just a list of features. The OKRs and the features tell a better story of your journey before you navigate it. Features alone say so little about your journey, OKRs Journey Compass tells it with lag measures you want to achieve, lead measures you need to commit to, and the impact you are looking to create.

Communicating your OKRs Journey Compass

This depends on your audience, you can communicate the whole compass to your team members (within your organization) and communicate the features sections externally if you need to. In my opinion, you have to have executive support to use this format as it will need some education on how it works and how it might affect directions. For example, if you are delivering the features, but you are not achieving the outcomes, there might be a pivot or change in directions.

What would you lose?

You are going to lose some predictability and will increase risk-taking. Over time, this will pay off big time if you can wait. If you can’t wait, then feature-based roadmap is the way to go for you and your team.