Four issues that OKRs don't effectively address
Before I get into things, I'm grouping products, services, and experiences into one word–products. Yes, I believe there are differences. No, those differences aren't relevant for I'm sharing below. Yes, you can hate me for doing this. This is also full of my opinions and observations based on my own experiences.
As I mentioned previously, I believe OKRs are quite good for startups who are laser focused on building one product and getting it to the market. Other frameworks, like AARRR metrics, help teams focus on converting potential users into users. When startup teams are building products from scratch, the majority of the focus is on growth. These frameworks have helped lots of startups get initial that traction and growth.
But, I have a question for you: Are you, right now, working at a startup that is laser-focused on building one product? If so, groovy! This may not be relevant, but read on anyways! If not, you may be struggling with your OKRs.
When you're working on products in any other setting, there are four issues I see coming up time and time again that OKRs aren't effectively addressing:
Teams have more than one objective to meet
Shared objectives across product teams
Quality and desirability conversations remain subjective
Designers aren't fulfilling their potential
Teams have more than one objective to meet
Ok, let's talk about some real world shit. Picture this scenario:
After a great kickoff meeting, the developers, designers, and PM agree on what should be done. They're excited and enthused. Everyone heads off to do their work and eventually, has a 1:1 with their boss. At those 1:1s, the developer is told by their manager to increase their velocity. The PM is pressured by her CPO to meet adoption and revenue goals first. The designer is inspired by their team to improve accessibility across the interactions.
What started as excitement and enthusiasm turns into frustration and anxiety. Each member of the team is now stuck between two priorities; do what was agreed as a team or do what the boss said to prioritize. When this occurs, we know there's a major failure at the leadership level, but waiting for leaders to figure this out leaves the product team to sort it out by themselves. That's messy and complicated.
TLDR: Product teams want to make something great, but members can't make sense of how velocity, accessibility, adoption, and revenue are interlinked.
OKRs are set up to cascade individual objectives and key results down and across an organization. But you live in the real world. When you're debating with your colleagues on what to do or how to do it, you face pressures to meet functional area, product, and customer objectives. You're trying to achieve more than one outcome at the same time. You're on the hook for improving satisfaction AND engagement. You're told to increase revenue AND improve accessibility.
What does velocity have to do with revenue? What does learning a skill have to do with customer satisfaction? What does accessibility have to do with usability? What does engagement have to do with adoption? OKRs do not answer these questions.
We need a framework to show how different, important objectives relate to one another.
Shared outcomes across product teams
A few years ago, a PM asked for some help because their team was struggling the impact of their work and they wanted to know the impact of their work. The conversation went like this:
"Our team is responsible for adoption of the product. We're not seeing an increase in adoption.", confidently said the PM.
"Great! Are you responsible for the site where customers decide to use your product?", I responded.
"No. We work on the features the customers use after they've signed up.", said the PM.
"Huh. So, why are you responsible for adoption when you're working on the features that are used after adoption already occurred?", I said.
This was the first time this PM realized they had no way to impact the objectives the team was responsible for. This was the first time this PM realized the importance of having shared objectives with another team. This was the first time this PM realized their own leadership didn't have shared objectives across teams.
The majority of tech professionals that I've met or worked with have been passionate about one thing: building great products for customers. I love this passion. Yet, when different teams struggle to have shared priorities, working agreements, or collaboration across products, I have seen that passion turn into frustration in the blink of an eye.
Passion to make great things is not enough to collaborate across teams. You know how I know? Ask five different teams at the same company to define what objectives they're trying to achieve and you'll get five different answers. The reason we need shared objectives across teams is because customers deal with a variety of features multiple teams are working on. Customer don't adopt specific features that one product team is responsible for.
We need a framework to show how objectives can be shared across teams and how achieving them at the same time is possible.
Quality and desirability conversations remain subjective
By far, the biggest issue I've experienced is what I'll call The Desirability Gap. Successful products are created when they are viable for the company, feasible for the company to make, and desirable for customers to use. Guess which factor is the source of the biggest day-to-day debates. It's desirability.
Eventually, once a product reaches a certain level of maturity, conversations move from minimally viable* towards higher quality. That's where I've seen a lot of teams running into problems.
When teams are discussing quality, everyone has an idea or opinion of what that means. It's totally healthy and valid for colleagues to share their thoughts and beliefs. The problem is, when there's no shared understanding of what quality is or what level of quality is needed, thoughts and beliefs become personal. And when making hard decisions as a team becomes personal, oh boy!
In my experience, OKRs primarily focus on viability and feasibility. This puts WAY too much emphasis on the business benefits when determining quality. Revenue, costs, satisfaction, engagement, churn, velocity, etc. are all really important metrics to understand, but they're all in service to the company, not the customer. They don't tell the story of why a customer is satisfied or continue to engage, if engagement is actually healthy for the customer, or how to make more objectives decisions as a team in regards to desirability.
Remember, product team members are passionate about making great products for customers and great products "win" in the market. We have to add a little more objectivity to the conversation.
We need a framework to show business leaders desirability isn't so subjective.
Designers aren't fulfilling their potential
If you're a designer, you might not like what I have to say next. Designers are a big part of this problem too.
Within many product teams, designers are the ambassadors of desirability. They have positioned themselves as the experts and have been hired to make products more human, useful, meaningful... desirable. Yet time and time again, I see designers make a fundamental mistake when on the job.
They bring their design debates to product decisions.
Companies are not hiring designers to debate what great design is with each other or with their teams. Companies hire designers to have an objective and shared POV of what great design is for the products they're working on. When designers can’t do this, companies and leaders think they're making it up. Why would they trust designers with anything more than making things pretty if they think designers are making it up?
We need a framework to show designers aren't making shit up!
