OKR Leadership: OKRs Are Not Task Lists
What are we going to build? This is the question that kicks off product conversations in most organizations. Managing to outputs is easy. It’s binary. You either shipped the feature or you didn’t. It’s the default way most organizations think about their work. In contrast, managing to outcomes is more difficult because we’re not focused on delivering an exact set of features but rather driving meaningful, positive behavior change in the people that we serve. If our goal is to reduce the time it takes to complete a transaction on our app by 50% and the team achieves a 37% reduction, did they fail? Did they succeed? Should they keep working on it? It gets more complicated as we attempt to lead our teams forward.
OKRs Take Features Out of the Conversation
If done correctly, a well-written objective and key result statement doesn’t mention solutions of any kind. Leaders new to this way of setting goals get anxious. “What’s the team working on? When will it be done? What kind of ROI should I expect? What should I tell my boss? The sales team? The market?” In a bid to get concrete answers to these questions leaders will push teams to commit to specific features and deadlines. With fixed scope and time in hand they can confidently provide answers to these questions. The answers will largely be false and not materialize in the expected way but at least they have an answer.
Teams trying to reconcile their new outcome-focused goals and their leaders’ demand for predictability and commitment find themselves between a rock and a hard place. Every time they present their OKRs to their bosses they face the same question, “That’s great, but what are you going to build?” They can sense that their leaders value the list of features much more than their key results. The result of this is a slow but steady transformation of well-written OKRs into a task list of projects and initiatives the team will execute.
Task Lists Are Not OKRs
As much as OKRs are not your strategy, they are also not a list of tasks for your team to complete. If that’s what you demand of your team, you’re effectively neutralizing any of the benefits of using OKRs. In fact, you are pushing your team back into waterfall project planning. The agility, empathy and customer focus that comes from working towards outcomes is lost in favor of rigid commitments to features and dates.
Let me illustrate the difference and the consequence of each approach:
Objective: Provide the simplest online mortgage application process in the industry by Q4 2022
Recommended by LinkedIn
Output as Key Result: Ship the 3-click mobile mortgage application
Outcome as Key Result: Increase the number of accurately submitted mortgage applications by 35%
In the first key result, the measure of success is a feature (3-click mortgage application). The team will work to ship that by Q4. Will it improve application accuracy? Submission rates? It may or it may not. The team isn’t worried about that. Their sole concern is shipping the feature by the date.
In the second example, the measure of success is a valuable change in the behavior of our customers (increased accurate submissions of mortgage applications). The team working towards this goal has to understand how to best present the application to users. They need to experiment, test, learn and iterate on their ideas. They have to get to know their customers.
Is 3-click application the best way to do it? It’s one option. There are infinite combinations of code, copy and design that might drive accurate submissions up. The team itereates towards the optimal solution and changes course based on what they learn along the way (hint: that’s agile). The definition of value is better results for the customers and organization, not the delivery of one specific feature.
We Need to Ask Different Questions
As leaders, if we want OKRs to succeed, we need to start asking different questions. “What are we going to build?” will always push our teams towards creating lists of tasks for us to review. These task lists are a good indication we’re asking the wrong questions of our teams.
Instead consider asking, “What will our users be doing differently if we succeed this quarter?” This question is aligned with the OKRs your teams are creating. They should be able to clearly point you to the behaviors they’d like to change in your target audience as well as share some hypotheses about how they might do that.
Well Said, a problem stated is a problem half solved. No user is going to be bothered about a particular technology unless it solves their problem in a superior way. Hence it's imperative to build products that are user-centric.
Can’t go wrong with a #customerfirst approach!
Asking “What will our users be doing differently if we succeed this quarter?” helps put an outcome focus on your team's work ,
Once the right framework and strategy are in place, OKRs are a great way to measure success.
Very well depicted and great one Jeff Gothelf