jtbd
okrs
goals
Objectives, Key Results - valuable tool or overcomplicated theater?
OKRs have become a staple with companies that shifted to the Product Model. The past few years have seen the development of OKR Consultants.
Between these two parties, OKRs have become too complicated with a hefty amount of product theater to boot.
We've seen three key pitfalls with how companies and consultants alike have taken a simple tool and overcomplicated them.
- Cascading OKRs, probably the biggest overcomplication
- Key results that aren't meaningful - vanity metrics
- Heavyweight process and theatrics around the OKR cycle
Cascading OKRs
While good intentioned, having cascading OKRs that start at the top and products and portfolios needing to ladder up to them is a signification burden to leadership and teams.
We all want to create value.
- First and foremost, at the top level, leaders should set the content for a broader timeline than a quarter.
- Poor product and team definitions reinforce a focus on delivery
- Teams spend precious time each and every cycle creating a story to ladder up to the top level OKRs
This should be a no-brainer, but it's a very common anti-pattern, top level product leadership creates OKRs on the same cycle as products and portfolios.
If these were truly strategic outcomes they are focusing on, they tend to be broken down into delivery focused Key Results.
It's certainly possible to look at incremental improvement, to want to improve a metric by single-digit percentage.
But this misses the point of using OKRs.
OKRs are intended to be used to create step-level change, not incremental change.
We're using the wrong tool for the wrong job, a hammer to pound in a screw.
Depending on the corporate strategy cycle which could be 1,3, or 5 years, the product strategy cycle should ideally focus on 1 year.
Product leaders can work with the executives to support the 3 to 5 year strategy cycle, while creating clarity for products and portfolios that is broad and ambitious enough by setting OKRs annually.
Products and portfolios then can look quarterly with their OKRs while thinking strategically on how to support the annual OKRs.
For product leaders, you should then expect product and portfolio leaders to think broadly on how this quarter fits with a broader annual focus.
(This is an opportunity for talent assessment and development.)
But what if the broader strategies change at some point?
Then change them, and ask the teams to determine the impact to their OKRs.
If top level OKRs are truly strategic, outcome oriented, there shouldn't be much change.
If they are tactical and delivery focused, that's possible there is a lot of change.
But you also aren't really doing strategic OKRs either.
Poor product and team definitions reinforce a focus on delivery
It's a common anti-pattern for product (or engineering) leaders create products and portfolios around "things" instead of anchoring to customer value.
A customer-centric approach is to organize teams around the Jobs-to-be-Done and assign a portfolio-level product leader to own a particular Job.
From an engineering perspective, this requires an 'inner source' working model where teams have open repos. (More on this later.)
What each portfolio will then need to understand is who the customer is and what is their Job-to-be-Done.
They need to understand how the customer measure progress on the Job AND be able to relate that back to how the company makes money.
The product portfolio leader needs to have a set of leading and lagging metrics.
From there the product teams within the portfolio can be defined.
Since this work isn't often done, teams will use 'engagement' and other vanity metrics to prioritize and gauge success against.
Heavy weight process and theatrics around the OKR cycle
Two thing
- Define who your customer is. If you are B2B, define your users, and even consider who the 'technical buyers' are.
- Start to organize all your research around the customer and read it all.
- What to do about stakeholders? It is common to create a stakeholder map. You may want to create this. I would definitely prioritize the first two tasks before this. Politics in large companies, might dictate doing this first. This is why most companies are losing.
- Ok, what should you not do? Don't start writing a bunch of job stories ( a reframing of user stories) for the team to start building. Job Stories were created by Alan Klement to shift the focus away from User Stories and more about the context of the Job-to-be-Done. These are helpful when you're trying to reshape your thinking around the customer outcome/Job. But they are a higher level of abstraction than a User Story and we've seen teams start to use them in place of a User Story. That's not what they are for, don't make the mistake.
These are the first steps to becoming truly customer-centric.
I just read a response to a post on LinkedIn where a Doctor with '30 Years Marketing, 25 Years Customer Experience', in other words, a 'thought leader' advise a Poster to not 'push this customer thing too far'. This gave us quite the laugh.
</section>