Is an OKR-Roadmap Hybrid methodology the best of both worlds?

We’re all victims of the echo chamber effect, and if nobody asks the right questions, how are you to know any different?

I’ve worked with some brilliant minds over the years, and they have one thing in common; they stop, think, and ask questions about the actual objective. Not just understanding the feature itself, but the purpose. What’s the goal? Why are we even spending our time and hard-earned revenue on this initiative?

Nobody likes the grumpy guy in the corner who hates everything for the sake of hating. I’m not at all advocating that behaviour. However, constructive questions and thoughtful feedback are fundamental in strategy. In war rooms, you’ll have commanders and chiefs evaluating a range of strategies devised by an army of analysts. Yet, in the technology industry, I often see boardrooms where features are dreamt up and put onto a roadmap with a plan that sounds a lot like: “we should get that done in say… 3 months. Then get started on the next feature straight afterwards.”

There are many articles online about OKRs not being roadmaps. However, this method argues roadmaps are an important tool as they allow other initiatives to be planned around them. It can also help when communicating updates or changes to the product.

Here’s a real-world example of an OKR-Roadmap Hybrid. As you can see, it was a measurable success:

The structure of the roadmap looks like this:

• Cohort - Time frame to implement changes to solve the objectives. You’ll also evaluate the result of your changes from the previous cohort. Just be careful not to skew the data with a release in this cohort that could falsely report the last cohort. You can also ensure that there haven’t been any regressions on historical cohorts.

  • Objective & Priority - The business objective. You can have multiple objectives per cohort. Just be mindful of your team size and how many objectives they can work on—usually, 1 per team at any given time.

    • Key Result & Priority - Method of achieving the business objective. You can have multiple OKRs per Objective. These should be pretty targeted. In the example above, the stakeholders didn’t care as long as it was an improvement. You may want to say: “Improve by x amount”.

      • Discovery Results - The teams’ assessment of the OKR

        • Build Actions - A proposed solution for the OKR could be multiple, as you could have marketing and development working on the same OKR with two different actions. Usually, backlogs consist of this column and this column alone.

      • Test Plan - This is how you validate the problem and measure the Key Result. You’ll run this test before the team start and record the answers, then rerun the test after the update to see if the changes were successful.

      • Pre-Test Results - Before the change.

      • Post-Test Results - After the change.

You start with your cohorts. These are sections of time where we will build improvements while measuring the results of the previous cohort. I recommend that your cohorts be around every three months. However, your business or industry will likely require six or even twelve months. I’ve worked in EdTech, where twelve months made the most sense, as we could have a cohort per school year for several reasons, the largest one being that the schools didn’t appreciate us making significant changes mid-year. We can measure student scores throughout a school year and compare them against other years.

Now start outlining your objectives/business pain points/opportunities.

Objectives

• Increase mobile sales in the UK

• Time taken to onboard suppliers isn’t scalable.

• Significantly reduce the cost of our logo design services and cater to early-stage startups that want a cheap logo. It is potentially using an AI to make a logo from templates instead.

These should be identified in a dedicated workshop to discover these; however, before the workshop, make sure that you’re preparing and bringing with you:

• User Personas (often I go through this exercise in the workshop, but I know some people prefer to do it as a separate activity)

• Previous User Testing Results

• Previous/Recent Market Research Results

• A review of the product analytics (usage trends, etc.)

• Technical requirements!!! What do the devs want time to achieve or address? This is often forgotten, but tech debt is a killer if left untreated (follow for a future blog post on this topic).

• Financials, operational reports, stability reports, and anything else the business might find important.

Next, you should validate the objectives and assumptions of the workshop. To do this, you can try several tools and activities to get an accurate picture:

• User Interviews or Questionnaires

• Smoke tests, conjoint, market research, copy tests.

• Update your analytics to capture specific metrics.

Key Results and Test Plans

Now you’ve validated the objectives and assumptions. You can now start looking for lower-level objectives that you believe would resolve a high-level objective. These lower-level objectives are your Key Results. This should be done with consultation from the team. It’s ok to go away and perform the tests yourself, but use refinement ceremonies to regroup with the team and get the questions out in the open. Usually, you’ll need assistance from the team to get the Test Plan and the test results.

Example Key Results & Test Plan

Objective: Time taken to onboard suppliers isn’t scalable.

Key Result: Allow suppliers to be onboarded without any manual effort.

Key Result: Reduce the time to onboard a supplier by 50%.

Always try to get the test plan written out before you start solutionising. You want to do this as early as possible and get it approved by all stakeholders because it’s an artefact that reflects the stakeholders’ interpretation of success. If you design a solution before the test plan is agreed upon, how can you be sure your solution would satisfy the stakeholders?

Once your OKRs are in place, start measuring your current value using the OKR test plan as a baseline. This will also help validate the OKR. Then work with stakeholders to find a likely target result after the change.

Your backlog refinement session then becomes a review of the research for each Key Result, any discovery/spike tasks completed by the team to find out more information, and prioritise the OKR’s so the teams are constantly working on the top priority objective.

The discovery phase and planning phase is a cycle. You’re continually reviewing the objectives, taking the feedback from the team’s research results, and assessing the overall strategy. Through research, prototypes, and testing, the teams can accurately determine the feasibility of the target set. If it is feasible, the team should discover the solution that will be the most effective. The UX team can investigate changes to the interface and optimise for your objectives. The marketing team can produce copy that optimising for your objectives. The solutions here are endless.

If the target isn’t feasible, that gets reported back. The overall strategy is reviewed, saving money and time in the long run and ensuring you’re always working on the most effective and impactful tasks. While not spending too much effort on an unachievable objective.

Assuming the target is feasible, the discovery phase should output some Actions. These are your solutions and your “roadmap” items, which are due to be delivered by the end of the cohort. You may need more time to deliver the items, in which case, it should be planned for the next cohort. Your actions shouldn’t consist of only the development activities. All parties should share a single list of high-level actions to achieve a key result. This way, everyone is aware of what others are working on, which fosters a collaborative working environment and a feeling of everyone working towards the same goal.

Summary

With all of this in place, the role of CEO, CPO, COO, or similar can ensure the teams are working on the most prominent objectives, rather than trying to figure out which feature should be done first and hope the team will solve their problem with that feature. The teams are all aligned on their objectives, how they can achieve them, and an agreed understanding of the measure of success. You also have an excellent roadmap broken up into large windows of time that illustrate when the benefit of the work will be realised.

This might be a controversial way of working, but it maximises communication and transparency. Allows the teams to be creative and utilise their skills effectively. The senior leadership or c-suite can focus on strategy rather than solutions, and the product managers have a vehicle for communicating openly and transparently.

It’s also encouraging the planning team to perform Market Research as a routine task.