While the post is dedicated to those who build tech-based products and services, people in other roles can learn from it as well.

You can find the original article at SVPG's website. This post is also available in Portuguese.

Marty’s Note:

My co-author for this article is the product coach Felipe Castro. I have known Felipe for many years, and he has collaborated with me on the outcome and OKR-related content in each of my books. Felipe specializes in helping companies move from output to outcomes.

At the highest level, moving to the product model is about moving from outputs to outcomes.

Conceptually, this is very straightforward and the value is intuitively clear to most people, but in practice, this is hard.

We’ve been talking and writing about the move to outcomes in all of our books, for many years.

The good news is that many other people have realized that just shipping features that don’t actually help the customers, or help the business, is not very meaningful. And today, many strong teams and companies have successfully moved their focus to outcomes.

But for many companies, the move to outcomes goes nowhere fast.

In this article, we would like to try to address some of the most common mistakes and confusions that come up when organizations attempt to move to outcomes.

We’ll also discuss some of the important nuances for those that have already thought about these concepts for a while.

The Concept of Outcomes

The basic idea behind outcomes is easy to explain:

We all know that some of the things we build make a difference, while others do not. That difference might be improving the lives of our customers, or improving the health of our business, or even helping our teams work more effectively.

Moving from outputs to outcomes means shifting attention from what we build (the outputs) to the difference we want to make (the outcomes).

But as anyone that has tried moving to outcomes can tell you, this is much easier said than done.

Framing Outcomes

When we talk about an outcome, we frame it around a problem to solve and the measures of success.

Specifically, this requires:

• Giving teams clear and meaningful problems to solve.

• Helping teams define how they’ll measure if they are truly solving each problem.

• Instrumenting the product so teams can immediately understand if they are achieving the intended outcome (i.e. solving the problem), and make adjustments based on the data.

While this framing may sound straightforward, many companies struggle as it can represent a significant behavioral and cultural change.

Common Mistakes When Moving to Outcomes

– Thinking You Can Move To Outcomes Without Moving To The Product Model

Far and away the single most common problem is thinking that you can move your organization to focus on outcomes, without actually doing the work of moving your organization to the product model.

This is understandable as outcomes are intuitive and conceptually simple, and it’s not immediately obvious to people why they would need to make a set of additional foundational changes in order to enable outcomes.

This is what happened to the countless thousands of companies that thought that they could layer in the OKR technique on top of their existing, output-based product roadmap processes, and expect any meaningful change. This mistake is what fueled the backlash to OKR’s in so many companies.

But the OKR technique originated from, and is predicated upon, the product model.

The OKR technique is quite straightforward if you already have established the product model as your way of working.

Moving to the product model involves significant changes to how you decide which problems you need to solve, how you solve those problems, and how you build, test and deploy your solutions. But realize that every aspect of the move to the product model exists to enable your organization to deliver outcomes.

So the most important thing to understand is that moving to outcomes is the consequence of moving to the product model.

– Letting Existing Metrics Dictate Problems to Solve

We often see companies limiting themselves to the outcomes that can be measured by their current indicators. For everything else, they use outputs.

However, quite often we’ll find that some of the most pressing customer or business problems are not yet properly covered by established KPI’s.

Strong product leaders don’t let existing metrics dictate which problems to solve or which measures of success to use. They know they have to focus on the most critical problems, even if they have to define new indicators or do some additional instrumentation work to do it.

A simple technique is ensuring we define a clear and meaningful problem before committing to specific metrics.

– Vague or Ambiguous Problems to Solve

Feature-team companies are often filled with vague goals that no executive can properly define or measure (e.g., “provide integrated platforms”). When all you measure is project completion, it doesn’t really matter if your goals are vague.

In contrast, strong product model companies invest time upfront to define clear problems so they can ensure they’re working on the right problems, and save substantial time down the road.

Here are several examples of what clear problems look like:

• Help customers solve issues without having to contact us

• Increase the percentage of shipments delivered with next-day delivery

• Make it easier for patients to reliably share data with their doctors

• Reduce the cost to acquire a new customer

• Reduce the operational costs of fulfillment

• Reduce the subscriber churn rate

• Reduce the time required to deploy a new or updated service to production

• Connect job seekers with more suitable jobs

• Reduce the average time spent handling a customer service call

• Reduce the time for a user to produce their first monthly report

Note that problems exist at different levels of granularity or “altitude;” some problems are more specific and can be tackled by a single product team, while others are broader and need to be tackled by multiple product teams collaborating closely; and some involve close collaboration with others in the company beyond the product teams.

Problems around optimizing existing metrics are usually the easiest to articulate (e.g., increasing conversion on the checkout page). In other scenarios, getting to clarity can be quite challenging, but often that’s where the major opportunities are.

Most measurement and alignment challenges are actually clarity challenges. When you have a clear definition of what you are trying to achieve, it makes it easier to measure success, create alignment between stakeholders, and discover effective solutions. Achieving outcomes requires clarity.

– Not Having an Intentional Product Strategy

The examples above are all potentially important problems to solve, depending on the company’s product strategy.

But as we’ve discussed many times before, many companies do not have an intentional or explicit product strategy. They have business goals, and they have roadmaps of product ideas they hope will generate positive results.

The product strategy represents the data, the logic and the decisions that lead from our top-level business goals to the specific problems to solve, and outcomes to achieve, from the various product teams.

When some people hear the word “outcomes” they immediately jump to top-line and bottom-line definitions of business results – revenue and profit being the main examples.

These top-level goals are certainly examples of outcomes, but they are more typically the end-result of many different outcomes, at many different levels of granularity, all contributing to the ultimate result.

For example, are our customers getting their needs met with our products? How long does it take to sell our products? How long does it take for a customer to start receiving the value? How long do our customers continue to use our products? These are all outcomes that can contribute real impact to end-results such as revenue and profitability.

Instead of seeing outcomes in isolation, sometimes it’s easier to think of them as dominoes, with each piece helping to topple the next.

This is where strategy becomes essential: a proper product strategy helps identify the most critical problems that need to be solved to deliver on the business objectives.

Another important dimension when choosing outcomes is whether or not it’s within a given product team’s ability to directly impact the desired outcome.

A team won’t feel empowered to come up with an effective solution and achieve the necessary outcome, if they lack the access or ability to make the changes necessary.

They also will be unlikely to discover a solution that will work for the customer and the business if they can’t measure if they are making the necessary impact.

– Measuring the Wrong Things

When we look at the measures of success, we’re trying to define how we will know if we have truly solved this problem? Certainly just launching a feature is not enough.

Some people confuse outcomes with the much more general concept of KPIs (Key Performance Indicators). KPIs are simply analytics that measure some aspect of a product or business.

Most businesses have hundreds or even thousands of relevant KPI’s, which help the leaders evaluate the health of a product or a business. While outcomes are measured with KPI’s, the vast majority of KPIs are not helpful measures of successful outcomes.

Every KPI is a data point, and that data point may provide clues or supporting information, but we’re looking for the KPI (or KPI’s) that are true measures of our desired outcomes.

As a simple example, the gas gauge and the tachometer on the dashboard of a (gas powered) car are KPI’s, but if the outcome you care about is improving fuel efficiency, these KPI’s are not really measuring if you are solving the problem (e.g. increasing miles per gallon).

That’s why we want to define a clear problem to solve before discussing the metrics. The goal is to measure if we are solving the selected problem, even if that means defining new KPI’s that we don’t yet track today.

One useful technique for finding good KPI’s to measure outcome is thinking about the desired changes in user behavior (for example, the percentage of our customers making in-app purchases).

But keep in mind that many important problems do not necessarily impact user behavior. Also remember that problems-to-solve can refer to customer problems, and/or our company problems.

– Neglecting Data Collection

Another item that becomes non-negotiable if you want to move to outcomes is the need to instrument whatever we release (referred to as telemetry) so teams can immediately understand if they are solving the problem, and make adjustments based on the data.

Yet many companies are still not gathering and analyzing their data as they need to—focusing on outputs allows them to treat analytics and reporting as a “nice to have.”

Additionally, as discussed above, many teams shy away from adopting the proper measures of success simply because they don’t already have the necessary instrumentation in place.

If you want to focus on outcomes, you will need to commit to continuously improving your product’s telemetry, creating new KPI’s and collecting additional data where necessary to measure if you are solving the necessary problems.

Common Confusions Regarding Outcomes

– Alternative Ways To Frame Outcomes

Several people have been exploring the mechanisms and the consequences of this move to outcomes, and there has been some truly useful content written on the subject.

Some of our favorites are Jeff Patton’s outputs vs outcomes vs impact, and Teresa Torres’ distinction between product outcomes and business outcomes.

We often refer to the outcomes tackled by product teams as product outcomes, and they roll up to contribute to business outcomes (aka “business results”).

Another way to frame this is to distinguish between outcomes (the difference we make by solving important problems) and impact (the top-level business results these outcomes help achieve).

These conceptual distinctions and simplifications can help people feel more comfortable with their role in the move to outcomes.

But it’s also important to realize that we want to encourage product teams to embrace work outside of their direct purview, in order to understand the issue, and what they can and should do to solve the problem.

For example, to understand what will be necessary to solve a problem that is showing up during the sales process, it is not unusual for a product manager to spend time with sales, going on sales calls, observing the interactions, to see where the issue might be.

– Inputs vs Outputs

Amazon is one of the best examples of the product model, but internally they use some language around the term “output” that can cause confusion when Amazonians use that language externally.

Amazon emphasizes the importance of focusing on the inputs, not the outputs.

This means focusing on the “input metrics” (e.g. selection, price, and convenience) that will drive the “output metrics” (e.g. orders, revenue, and profit).

When Amazon emphasizes the need to “manage the inputs, not the outputs,” this means focusing on managing the causes, not the effects.

This is also an important point, and relates directly to product strategy, but is not to be confused with the definition of outputs which are the things we build.

– Keep The Lights On

It’s critical to always remember that not everything needs to be a problem to solve with an outcome.

There is always a set of “Keep The Lights On” items that are like a punch list of typically minor work that our business partners need to be able to keep things running.

Summary

There’s no question that delivering outcomes is much more difficult than delivering output. It requires new competencies, new skills, and a different approach to defining and assigning work.

There are a number of other items relating to outcomes beyond what we’re highlighting here. The book EMPOWERED: Ordinary People; Extraordinary Products provides a much more comprehensive explanation with detailed examples and case studies.

But for those product teams that are serious about delivering real value, solving the underlying problem for our customers or our business, and delivering the necessary business results is the only real measure of success.

What do you think?

Hi, Felipe again here.

What do you think about this article? Hit reply and let me know.

Connect with Felipe

• Are you new to the newsletter? Subscribe for free

• Follow me on LinkedIn for more insights

• Contact me to organize an in-house workshop or keynote for your team.

This post is also available in Portuguese.

Subscribe now

In the previous article, we saw that the 80/20 rule can help companies avoid getting distracted building lemonade stands in front of the gold mine.

I'd bet that you have a few gold mines right in front of you—a small number of things that will drive most of your desired outcomes.

The 80/20 questions (“What is the 80/20?” and “What are the critical success factors?”) can prompt great conversations and help you find those nuggets of gold hiding in plain sight.

The classic way to apply the 80/20 rule is by doing a quantitative analysis.

But using the 80/20 rule as a qualitative technique can be even more powerful, as it can help clarify strategy, creating focus and alignment.

Let's see how you can use both options in practice.

How to use the 80/20 rule in a quantitative analysis

For a simple example, imagine three product teams trying to achieve the same outcome: reducing the crash rate of their apps.

Team #1

Team #1 decides to move fast and starts working on projects they believe will reduce the crashes.

The team tracks the total number of crashes, but they only have a superficial understanding of the causes. When the crash rate fluctuates, they struggle to explain why, as they lack supporting data.

Team #2

Team #2 identifies 15 “P1” bugs causing crashes. They set a Key Result to reduce these bugs to zero, but struggle to choose which to fix first.

They start by working on all 15 bugs in parallel, but that slows them down. Then, they resort to fixing the easiest bugs first, regardless of their impact.

Team #3

Team #3 begins by asking themselves the 80/20 questions, “What is the 80/20? What are our critical success factors?”

To answer these questions, the team uses a simple quantitative method to analyze the data:

• List all the bugs causing crashes.

• Calculate the percentage of the total crashes created by each bug.

• Rank the bugs from highest to lowest impact.

• Create a graph to visualize the critical success factors and the supporting cast.

  (Google Pareto chart or Pareto analysis for a full explanation and templates.)

The graph clearly shows that just four bugs are responsible for 86% of the crashes:

Instead of getting distracted like the other teams, team #3 focuses on these four bugs—their critical success factors—to ensure they'll make a real impact.

We'll discuss how to apply the 80/20 rule as a qualitative technique after this short break.

Building your outcome muscles

Develop the muscles and mindsets you need to focus on outcomes and get better results with OKR by attending one of my workshops.

I designed them to help you unlearn the model where teams are always chasing multiple conflicting deadlines.

Instead, we'll shift to a model that gets everyone moving in the same direction, focused on the outcomes that really matter.

Contact me to organize an in-company workshop or keynote for your team.

Using the 80/20 rule to make the implicit explicit

Gold mines often remain implicit. They may be locked in people's heads, buried under a pile of "priorities," or lost in the fancy language of a strategy document.

Using the 80/20 rule as a qualitative technique can help make the implicit explicit.

The 80/20 questions can offer a new lens for thinking about priorities and equip people with a clear language to separate what's critical from what's merely useful.

A common scenario is that one person has already spotted the gold mines but struggled to communicate it to others.

I remember when I asked a group the 80/20 questions. The engineering leader promptly answered, “The critical success factors for our development pipelines are speed, security, and ease of use.”

However, the team members looked at each other as if it was the first time they had heard that.

Deep down, they probably knew these factors already. But no one had made them explicit or stated it with such clarity and simplicity. Their gold mines were hidden under a pile of “priorities.”

Another common scenario is when a group has to work together to make the gold mines explicit. Using the 80/20 questions paired with visual tools can be quite powerful.

As a simplified example, I was once working with a financial services company when a product team asked for help:

- We are struggling to decide which outcomes our team should focus on.

In the end, we want to increase revenue, but we depend on the sales team for that. We could share the revenue target with sales, but it would be hard to know if our team made a difference.

- The 80/20 rule can help you identify where you should focus. What is the 80/20? What are the critical success factors for increasing your product's revenue?

- We know that customer satisfaction with the product is critical. The performance of the sales team is key as well, but we have little influence over it.

-Ok, so let's dive a bit deeper. What is the 80/20 for improving customer satisfaction? What are the critical success factors?

After some debate and back-and-forth, the team reached a conclusion.

- The critical success factors that drive customer satisfaction are ease of contracting the product, time to complete each transaction, and ease of managing the contract in post-sales.

- Great, let's write each of these factors on stickies to help us visualize them:

The team then worked to identify the best metrics to measure each one of those three outcomes that represented their “gold mines.”

The diagram above is an example of an outcome map (or outcome tree), a powerful tool to clarify strategy and make it tangible for everyone.

In a future article, we'll discuss how you can use the outcome map to help people understand how they contribute to your company's success.

But before we do that, we need to understand why so many people fail to apply the 80/20 rule—it's not because they are stupid or lazy.

If you liked this article, share it with your friends. If someone forwarded this post to you, subscribe to my newsletter to receive more content directly to your email.

Share

Subscribe now

Companies often get distracted and fail to focus on what's critical. They end up doing things that move them away from what they really want to achieve.

Netflix has a colorful expression to describe those pesky distractions that get in the way of achieving what truly matters: the lemonade stand in front of the gold mine.

As Netflix co-CEO Greg Peters explains:

We have this thing we call the lemonade stand in front of the gold mine, which is don’t get distracted building lemonade stands in front of the gold mine — you want to find the gold mines and that’s what you really want to work on.

PayPal also had to deal with its share of distractions, as former executive Matt Lerner points out:

At PayPal, all of the early growth came from referrals & eBay. Next wave was developers, shopping cart referrals, and direct sales to a few verticals. That was it—all of PayPal’s growth came from 5 things.

We did tons of other stuff. Tons! Most of it was a huge, expensive distraction.

Netflix’s analogy also applies to teams, as they can get distracted building lemonade stands in front of their own small pockets of gold.

One of the reasons executives and teams get so distracted is that the word priority lost all meaning.

Everything became a priority

I've noticed a common pattern: people agree they are working on too many things at once, but get stuck deciding where to focus.

To them, everything they are working on is a “priority.”

Over time, I realized the word priority had lost all meaning.

Priority lists became the junk drawers of the business world. It's where people lump together what's critical with what may be useful someday, in a jumbled mess of dozens of items.

Everything became a priority, so nothing is.

Without a shared language to separate what's critical from what's merely useful, people get distracted.

Some try to number priorities (P0, P1, P2…) but that's like saying LeBron James and I both "play basketball." While technically correct, it hides the massive difference in our impact on the game.

So, what's the alternative? How can you find the gold mines and avoid getting distracted?

You might be thinking, “Isn’t finding gold mines and avoiding distractions the job of strategy?” And you’d be right.

But strategy is hard. Many companies struggle with it or lack a real strategy.

And even when companies have a “strategy,” there’s another problem: people often fail to see gold mines right under their noses. Or worse, they find the gold mines but struggle to clearly communicate them to the teams.

There is a simple but powerful principle that can help you identify what truly matters and stay focused. You may have heard of this concept, but I'd bet you're not fully applying it.

The 80/20 rule

The Netflix and PayPal stories are great examples of a crucial concept that can help answer these questions: the Pareto principle, also known as the 80/20 rule.

The principle, named after Vilfredo Pareto, suggests that in many situations, 80% of the effects come from 20% of the causes.

In plain English, it means that often 80% of your outcomes come from 20% of your efforts.

In the early 2000s, Microsoft CEO Steve Ballmer wrote an email to customers highlighting a clear case of the Pareto principle in action:

About 20% of the bugs cause 80% of all errors, and—this is stunning to me—1% of bugs caused half of all errors.

To be clear, the 80/20 rule is just a simplified way to express the Pareto principle. The exact ratio doesn't have to be 80/20.

For example, the language learning app Duolingo gets 80% of its $530 million in annual revenue from 9% of its users.

Some may argue that everybody knows about the Pareto principle, or even that it’s “obvious.”

But if your company was actually applying the 80/20 rule, you wouldn't be dealing with dozens of priorities, would you?

We'll continue this discussion after a short break.

Move from projects to outcomes

Develop the muscles and mindsets you need to focus on outcomes and get better results with OKR by attending one of my workshops.

I designed them to help you unlearn the model where teams are always chasing multiple conflicting deadlines.

Instead, we'll shift to a model that gets everyone moving in the same direction, focused on the outcomes that really matter.

Contact me to organize an in-company workshop or keynote for your team. 

Separating what's critical from what's merely useful

The 80/20 rule can help you avoid the trap of burying your gold mines under a pile of so-called “priorities.”

But the truth is that the Pareto principle can sound dull or abstract, especially for those who don't think of themselves as "metrics people."

To make the 80/20 rule stick, we have to make it more memorable by pairing it with the lemonade stand analogy and adding other colorful terms.

That way, we can give people a simple model to separate what's critical from what's merely useful, by thinking about two categories1:

• “Gold mines” or critical success factors are the handful of elements which will drive most of the outcome and create real impact.

  These are the main characters of your strategy and need to be treated as such.

  They are also called “levers” or “drivers,” but these words are so overused that they are rarely useful.

• “Lemonade stands” or supporting cast are the large number of remaining elements that account for a small part of the outcome.

  These include all the good ideas that play secondary roles in your strategy. They may be useful but aren’t critical.

"What is the 80/20?"

When people are struggling to decide where to focus, I’ve found it’s useful to explain this model and then ask, “What is the 80/20?”

This question can prompt great conversations, helping create focus and alignment.

Different words resonate with different people, so this model allows you to use different versions of the question: “What are the critical success factors here?” or “What is the gold mine?”

With engineers, simply mentioning Pareto can be enough.

In the next article, we'll discuss how to use this question and put the 80/20 rule into practice by taking three critical steps:

1. Find the gold mines: Identify the critical success factors that will likely drive most of the outcome. Some of them may be hiding in plain sight, right in front of you.

2. Help teams avoid distractions: Help them focus by making the gold mines crystal clear instead of lumping them together with other “priorities.”

3. Relinquish the lemonade stands: Learn to let go of all the good ideas that aren't critical and say no to lemonade stands.

We'll dive deeper into how you can follow these steps to become more focused. We'll also discuss the reasons why people often fail to do so.

If you liked this article, share it with your friends. If someone forwarded this post to you, subscribe to my newsletter to receive more content directly to your email.

Share

You can find the first two articles about focus here and here. This post is also available in Portuguese.

Subscribe now

“What lessons did you take away from working with Steve Jobs?” the journalist asked Jony Ive, Apple’s former Chief Design Officer.

Ive gave a thought-provoking answer:

Steve was the most focused person I've ever met.

And the thing with focus is it’s not something you aspire to or that you just decide on Monday, “you know what, I’m going to be focused.”

Focus means asking every minute, “Why are we talking about that? This is what we’re working on.”

One of the things Steve would say—because I think he was concerned that I wasn't focused—was, "How many things have you said no to?"

And honestly, I would have these sacrificial things, and I’d say, “oh, I said no to this, and no to that.” But he knew I wasn’t vaguely interested in doing those things anyway. So there was no real sacrifice.

What focus means is saying no to something that with every bone in your body you think is a phenomenal idea.

You wake up thinking about it, but you say no to it because you are focusing on something else.

Move from projects to outcomes

Develop the muscles and mindsets you need to focus on outcomes and get better results with OKR by attending one of my workshops.

I designed them to help you unlearn the model where teams are always chasing multiple conflicting deadlines.

Instead, we'll shift to a model that gets everyone moving in the same direction, focused on the outcomes that really matter.

Contact me to organize an in-company workshop or keynote for your team.

Learning to relinquish

As I’ve explained, focus goes way beyond simply “prioritizing” or saying no to things you weren’t that interested in anyway. Real focus requires making painful tradeoffs, even turning down amazing ideas.

To truly focus, we have to learn to relinquish. We have to learn to let go of our attachment to even our most cherished ideas.

In fact, Apple's history provides a perfect example.

To focus on the iPhone, Apple's leaders had to relinquish updating products like the MacBook Pro and the MacBook Air for several years.

Imagine how hard that decision was. Apple was built on top of the Mac, and the product has a cult-like following among customers.

I'm sure Jobs, Ive, and many others thought launching new MacBooks was a phenomenal idea. But by saying no, the company was able to focus on the iPhone, the most successful product in history.

Relinquishing old assumptions

Sometimes saying no means making different choices and relinquishing old assumptions.

When Apple launched the first iPhone, market leaders Nokia and Blackberry were making phones based on a few core beliefs. Phones needed physical keyboards, had to bounce unharmed if dropped on concrete, and the battery had to last for a week.

As Benedict Evans points out, by rejecting those assumptions, Apple created a product so compelling that people gladly switched:

Here we are several years later and the iPhone battery lasts for a day and if you drop it, it breaks. But it's worth it for the experience.

Creating a relinquish list

Creating a real strategy involves clearly articulating what you'll focus on. But it also involves defining a relinquish list that clearly communicates all the amazing ideas you are saying no to.

But companies often sweep priorities under the rug, hiding them in multiple ways.

Sometimes people intentionally try to hide priorities by setting a small number of OKRs while keeping multiple projects running “on the side”. This allows them to create the illusion of focus without having to say no.

However, there are also priorities that are hidden so deep that people don't even realize they exist.

KPIs are a common source for those implicit priorities. Teams often set dozens of them and then try to move all at the same time, turning each KPI into another “priority.”

People who sweep priorities under the rug are just fooling themselves.

They may say they are focused, but they are still drinking from too many bottles in parallel and wondering why they can't move faster.

To create a real relinquish list, you have to cover the two buckets of investments: all your intended outcomes, metrics, and projects.

How can you know if you are truly focusing?

There’s a simple test to know if you are focusing or not. As my trainer used to say, “If it feels easy, you are doing it wrong.”

If you are talking about a truly phenomenal idea, it means there's a real need for it. Turning it down will be painful.

Customers and stakeholders will fight for the idea, as will the people who are working on that product or initiative.

Mac fans hated the delays in launching new models. Some even accused Apple of abandoning the product in favor of the iPhone. I'd bet that the Mac team didn't like that either.

If you are saying no to a phenomenal idea, someone will resist it. If saying no feels easy, you are not focusing enough.

“I can’t say no because I don’t control all my priorities”

Sometimes people argue that they can't say no because many of their priorities are defined by others: executives, stakeholders, customers, or the government.

But there are priorities that fall under your control, and you should start by trying to relinquish some of them. Even that can make a big impact.

You don't have to say no to it forever

Sometimes, saying no is a final decision. For example, when a company stops selling a given product.

But you can also say a temporary no, as Apple did when it decided to delay the updates to the Macbook line.

Quarterly planning makes it easier to say no. After all, you are not saying no forever, only for the next quarter.

And by working on your priorities sequentially instead of in parallel, you'll move faster.

OpenAI, the makers of ChatGPT, used a clear visual to illustrate its decision to work sequentially, focusing on reducing price before improving speed.

As CEO Sam Altman explained, they had to choose one or the other, so they focused on price first, with plans to work on speed next.

Working sequentially can be a powerful tool, and one that is not so hard to implement.

How many things have you said no to?

Now it's time to ask yourself the same question Steve Jobs asked Jony Ive: how many things have you said no to?

And remember: It's not enough to reject ideas that others love but you don't. To focus, you have to say no to ideas that you personally believe are phenomenal.

Coming next: how do you choose where to focus on?

If you liked this article, share it with your friends. If someone forwarded this post to you, subscribe to my newsletter to receive more content directly to your email.

Share

You can find the first part of this article here. This post is also available in Portuguese.

Subscribe now

The "more is better" mindset towards priorities is sabotaging your organization's ability to focus. And it's costing you way more than you realize.

This worldview suggests that companies can achieve more faster by working on dozens of priorities at the same time than by focusing.

People with the more is better mindset believe that “prioritizing“ means adding things to an already long list of priorities.

As Rich Mironov points out, they want to "prioritize in":

“These are really important (to my department or division), so we need to approve them all” (…)

Prioritizing in is about getting agreement to do more, especially what’s on my list.

How can we help people understand the importance of unlearning this way of thinking, especially senior leaders?

For years, I've been using a powerful exercise to challenge this mentality and illustrate the impact of focus—using nothing more than a few bottles of whisky.

Learning focus with whisky bottles

The 12 bottles of whisky exercise was created by my friend Paulo Caroli, a principal consultant at ThoughtWorks and a whisky lover.

One day, as he poured himself a dose of a 12-year Macallan, Caroli asked himself, “How long does it take for me to drink one bottle of whisky on average?”

I'd like your help with this question. Here are the details:

Caroli’s whisky cabinet has enough space for 12 bottles of whisky, and he always keeps it full.

Whenever he finishes a bottle, he removes it from the bar, opens a new one, and adds the new bottle to the bar. Every year, he drinks six whisky bottles.

Now, try this quick exercise:

If the cabinet holds 12 bottles of whisky and Caroli drinks 6 bottles per year, how long does it take for him to drink 1 bottle on average?

Please select an option before continuing:

A.    6 months

B.    3 months

C.    2 months

D.   1 year

E.    2 years

We'll discuss the answers after this short break.

Move from projects to outcomes

Develop the muscles and mindsets you need to focus on outcomes and get better results with OKR by attending one of my workshops.

I designed them to help you unlearn the model where teams are always chasing multiple conflicting deadlines.

Instead, we'll shift to a model that gets everyone moving in the same direction, focused on the outcomes that really matter.

Contact me to organize an in-company workshop or keynote for your team.

If you’re like most people, you chose option C, two months.

Since Caroli drinks 6 bottles per year, and there are 12 months in a year, it seems logical that it would take him 2 months to finish each bottle (12 months ÷ 6 bottles = 2 months per bottle).

That would be the correct answer, as long as he kept drinking from one bottle.

What if he drank from different bottles each time instead of focusing on a single one?

Drinking from all 12 bottles in parallel, it would take him two years to finish each bottle on average.

Working sequentially vs in parallel

Imagine Caroli had a brother who drank from all bottles in parallel while Caroli drank sequentially, finishing a bottle before moving on.

On average, Caroli would finish one bottle every two months while his brother dealt with several partially drunk ones. By the time the brother finished his first bottle, Caroli would have finished 12:

Have you ever been to one of those organizations where people are always complaining that “nothing ever gets done around here”?

Where a simple website update can take months, and product features can languish in development for several quarters?

The answer may be quite simple: they are drinking from 12 bottles at the same time.

Lack of focus has real costs

Organizations often don't realize how much lack of focus costs them, even as they work hard to cut expenses elsewhere.

The cost of working on multiple priorities simultaneously can be proven by more than just visual examples.

MIT professor John Little proved mathematically what is known as Little’s Law: in a stable system, there is a linear relationship between the number of items in the system and the average time each item spends in the system (the lead time).

Simply put, the more bottles you drink from in parallel, the longer it will take to finish each one.

This is an example of what economists call opportunity costs. For every hour you spend working on a "priority" that's useful but not critical, you surrender an hour of working on what will create real impact.

In real life, the burden of lack of focus is even greater. Executives and teams also have to deal with coordination costs (the effort needed to synchronize work across different teams) and context-switching costs (the productivity loss when shifting attention between different projects).

From "more is better" to "start less, finish more"

Little’s Law and the 12 bottles exercise show the impact of shifting our mindsets from “more is better” to “start less, finish more” (which is the title of a book by my friend Dan Montgomery).

Start less, finish more means that if you limit the amount of partially done work—also known as work in progress (WIP)—you'll improve your throughput.

Limiting WIP is like restricting the number of whisky bottles you drink from in parallel. By limiting the number of partially drunk bottles, your WIP, you'll finish each one faster.

The importance of limiting WIP has been common knowledge in lean manufacturing and technology circles for many years. In fact, strong product teams often limit the number of items or user stories1 they work on at the same time.

But few organizations manage WIP at the company level, handing out priorities like candy on Halloween.

However, senior leaders can unlearn this mindset, like the executive who had an aha moment during one of my workshops:

Maybe instead of having 20 projects that move slowly, we should have 3 that move fast.

“We have multiple teams, so we can work on multiple priorities”

Some people argue that their organization can pursue many priorities at the same time because they have multiple teams. "We'll dedicate a few teams to each priority," they'll say. "That way, nobody will be overwhelmed."

There are two big flaws in this argument. First, spreading resources too thinly means you'll never have enough to make significant progress on anything. The peanut butter approach is not a strategy.

Second, in real life, teams have dependencies. To make progress, they require effort by someone else—whether it’s building something new, providing input, or making a decision.

Dependencies plus multiple priorities mean someone will end up drinking from too many bottles in parallel.

It can be a platform team serving other product teams2. Or it can be an executive, stakeholder, or central function that has to review the work before it can continue.

In either case, many people will be left waiting until the overwhelmed teams and stakeholders slowly empty all these bottles.

Since most organizations have far too many dependencies, whisky bottles multiply like rabbits. Soon, everything slows to a crawl.

Focusing and limiting WIP is a journey, but you can make progress in gradual steps. You have to eliminate dependencies instead of managing them, as Amazon famously did.

And as we'll see in the next article, you also have to build the muscles to say no—even to ideas you think are phenomenal.

In the meantime, ask yourself: How many whisky bottles are you and your team drinking from in parallel?

Links:

• Rich Mironov: My Next Word to Retire is 'Prioritization’.

• Paulo Caroli's website.

• Dan Montgomery's website.

If you’re finding this newsletter valuable, share it with a friend and consider subscribing if you haven’t already.

Share

This post is also available in Portuguese.

Subscribe now

I've talked to hundreds of companies about why they're turning to OKR. Lack of focus is always high on the list.

Employees feel pulled in multiple directions by a never-ending list of goals, projects, and KPIs. Everything is a priority, so nothing is.

Why is focusing so hard?

Focusing and being outcome-driven have a lot in common. There are structural, deeper causes that make both incredibly challenging.

Just like being outcome-driven, real focus is never easy. And it becomes even harder due to weak muscles and misguided mindsets.

You can't focus without the right skills or organizational capabilities, the same way you can't be outcome-driven without them.

And focusing is almost impossible if your beliefs or processes make you set multiple priorities. It's similar to how the know-it-all mindset and practices like project-based funding make people focus on meeting due dates instead of achieving outcomes.

To truly focus, we have to develop new muscles and mindsets. Just like we need to do to become outcome-driven.

We have to build the muscles to identify the handful of goals that will create real impact and to say no to the multiple great ideas that may be useful, but are not critical.

We also have to unlearn old mindsets and abandon any practice that pulls us into distractions and the diffusion of our efforts.

We'll begin by discussing those misguided mindsets, right after a quick commercial break.

Move from projects to outcomes

Develop the muscles and mindsets you need to focus on outcomes and get better results with OKR by attending one of my workshops.

I designed them to help you unlearn the model where teams are always chasing multiple conflicting deadlines.

Instead, we'll shift to a model that gets everyone moving in the same direction, focused on the outcomes that really matter.

Contact me to organize an in-company workshop or keynote for your team.

Now, let's explore some of the mindsets that can hinder our ability to focus.

Prioritizing is not the same as focusing

Many people believe that all they need to do to focus is to “prioritize,” which usually means creating a laundry list of dozens of “priorities.”

But when every team takes this approach, the organization quickly ends up with hundreds of competing efforts, spreading investments across multiple areas.

In the early 2000s, tech executive Brad Garlinghouse warned about a similar situation inside Yahoo in his famous "Peanut Butter Manifesto":

We lack a focused, cohesive vision for our company. We want to do everything and be everything -- to everyone. (...)

I've heard our strategy described as spreading peanut butter across the myriad opportunities that continue to evolve in the online world. The result: a thin layer of investment spread across everything we do and thus we focus on nothing in particular.

I hate peanut butter. We all should.

The fact that many readers have to Google "Yahoo" to know what it is shows the consequences of spreading a company too thin.

Focusing is something completely different. Focusing means concentrating energy and resources on a small number of decisive things that will generate the majority of the results.

A strategy is not a list of priorities

Another belief that makes focusing harder is that formulating strategy is just making a list of goals or priorities.

But as Roger Martin explains, strategy involves making choices that fit together and reinforce each other:

[Strategy] is not a list of stuff that makes a company better. It is an integrated set of choices that in combination creates a way of winning — where the company has chosen to play.

Spreading resources across a list of disjointed goals isn’t a strategy, even if each of the goals is worthwhile.

We often dream of having one or two unifying goals that everyone in the company can rally around. But the reality is that organizations usually have conflicting aspirations that can't all be achieved at the same time.

As Richard Rumelt points out:

Most people and organizations have “a bundle of ambitions.” That is, they have multiple intentions, visions of the future, and things they would like to see or achieve. Some things in this “bundle” conflict with one another—not all can be achieved together.

I once worked with a company that set two seemingly reasonable goals: moving to the product model and making significant cost reductions in its corporate functions.

But these goals ended up undermining each other. The CTO was trying to hire hundreds of engineers to support the product transformation, while HR was attempting to drastically reduce investments in recruiting to hit the cost reduction targets.

A real strategy has to provide clear guidance on how to make these inevitable tradeoffs.

For example, a clear strategy might involve reducing recruiting costs for other roles while maintaining or even increasing the investment per hire for engineers. That's the difference between focusing on what's truly important and just setting priorities.

The one-size-fits-all approach to cost reduction—saying everyone has to cut costs by 20%—is a telltale sign of lack of strategy. It's peanut butter cost-cutting, spreading cuts evenly across the organization.

Focus is not “fair”

Another common misconception is believing organizations have to divide team capacity "fairly" among different stakeholders. They end up spreading a thin layer of investment across multiple priorities without focusing on anything in particular.

In EMPOWERED, Marty Cagan shared a vivid example of a company that was prioritizing without focusing:

A few years ago, one of the execs of the music service Pandora shared the “Pandora Prioritization Process”—the company’s process for deciding what to work on and build.

The process involved letting stakeholders “buy” the features they wanted from the feature teams until their budget ran out.

(...) I immediately recognized the complete and utter absence of product strategy and especially focus. Not bad product strategy—literally no product strategy.

After years of declining listeners and struggling to turn a profit, Pandora was eventually sold off for little more than half of its IPO price.

Focus and strategy aren’t fair. While you need to balance the needs of different stakeholders, they are not all equally important. You have to show empathy and candor, without avoiding the necessary trade-offs.

To focus, we have to unlearn

To truly focus, we have to abandon mindsets and practices that make us spread our resources like peanut butter on a slice of bread.

We need to abandon the belief that making long lists of “priorities” is the same as focusing. We have to let go of the notion of being “fair,” and distributing our investments across different stakeholders. And we have to unlearn the idea that a strategy is simply a collection of goals.

Coming next: the muscles and mindsets of focus

Next week I'll be back with part 2 of this article, covering the muscles and mindsets of focus.

Feel free to share your thoughts in the comments or email me.

Links:

• Brad Garlinghouse: The Peanut Butter Manifesto.

• Pandora's Prioritization Process.

If you’re finding this newsletter valuable, share it with a friend and consider subscribing if you haven’t already.

Subscribe now

If this is your first time reading my newsletter, please read this article and this one before continuing. Today's post builds on concepts discussed in them.

This post is also available in Portuguese.

As we’ve seen, we need to begin with the end in mind and start by clearly defining our desired outcome.

But you probably already have projects planned or under way. What should you do with them?

And what should you do if you or a coworker gets stuck thinking about a project?

Asking “Why?” repeatedly can help teams shift from projects to outcomes. It’s a great exercise to develop outcome muscles and unlearn old mindsets and behaviors, if properly used.

For a simplified example, imagine that a marketing analyst reached out to her manager asking for help:

-I created a Key Result that says, “Write 5 posts on LinkedIn,” but now I know that’s a project, not a real Key Result. Can you help me identify the outcome?

-Why do you want to write 5 posts on LinkedIn?

-To increase followers.

-Why do you want to increase followers?

-To increase engagement.

-Why do you want to increase engagement?

-To increase brand awareness.

-Why do you want to increase brand awareness?

-To attract potential customers.

-Why do you want to attract potential customers?

-To increase revenue.

Asking “why?” multiple times helps map a sequence of outcomes that “ladder up,” connecting the original project with a top-level outcome:

This technique is called the Five Whys. It comes from Lean Manufacturing, where it's used to identify the root cause of a problem.

We’ll use a slightly different version focused on helping teams identify their desired outcomes and connect their work to the company OKRs.

Outcomes are like a sequence of dominoes

Imagine a sequence of dominoes, where knocking over the first piece creates a chain reaction, sequentially toppling each domino until the last.

Instead of viewing outcomes in isolation, it's best to see them as a cascading sequence, like a series of falling dominoes.

When defining our desired outcomes, we want to intentionally select the ones that build on each other, creating a powerful domino effect.

Looking at our example again, we can see that we answered each “why?” question with a clear outcome. Each item in the sequence contains a measurable benefit we want to create:

This sequence of outcomes works like a series of dominoes, where achieving the first outcome contributes to achieving the second, and so on, until we reach the company's desired outcomes.

The Five Whys can be a great coaching tool

Teams need guidance, coaching, and support from their managers to perform at their best. And the Five Whys can be a great tool to coach and develop the teams.

People often understand why they’re working on a project but struggle to express the outcome. The Five Whys technique can help identify those outcomes.

But if a team is struggling to answer even the first “why,” it means they lack the basic understanding of the context they need to focus on outcomes. Leaders have to step up and fix this by coaching the teams.

Asking “Why?” is just the first step

Asking “Why?” is a great start, but to focus on outcomes we can’t stop there.

Going back to our first example, the marketing manager continues coaching the analyst after mapping the sequence of outcomes shown in the image above:

-Now we need to select the outcomes you will focus on. At which "level" of the sequence do you think you should focus?

-Increasing followers sounds nice, but that's irrelevant without building relationships with potential customers. I'll focus on attracting potential customers.

-How can you measure this outcome? Which metrics could you use?

-I can measure the number of people who contact us to book a demo of our software or the number of qualified leads.

-What other ideas could you test to achieve this outcome? We want to focus on the outcome instead of getting stuck on a single project.

- We can experiment with different things, for example: publishing interviews with reference customers, running small online events, and making a better product demo video.

Example two

For another example, imagine a product team having this conversation:

-We are building a new customer service tool, but we're struggling to define the intended outcomes. Let's use the Five Why's technique.

-Why are we building a new customer service tool?

-To make the tool easier to use.

-Why do we want to make the tool easier to use?

-To help customer service agents find the information they need faster.

-Why do we want to help agents find the information faster?

-To solve customer issues faster.

-Why do we want to solve issues faster?

-To improve customer satisfaction.

-Why do we want to improve customer satisfaction?

-To increase customer retention.

-Here's the sequence of outcomes we have mapped. Which of these outcomes should we focus on?

-In the end, we want to increase retention. However, many factors affect retention, so we may never know if our team made a difference.

We could create a shared OKR with the customer service team to solve issues faster, but measuring our contribution might be hard.

Let’s focus on the two outcomes at the beginning of the sequence: “make the tool easier to use” and “help agents find information faster.”

-And how can we measure these outcomes? Which metrics could we use?

-We could measure the completion rate of common tasks, the time to complete those tasks, and the time to retrieve the necessary information.

-What other ideas could we test to achieve this outcome?

-We can test different ways to train customer service agents on using the tool.

But the key point is that we can't treat the development of the tool as a project with predefined features. We have to experiment with different ideas or approaches to achieve the outcomes we've selected and test those ideas with real users.

If you are always starting with a project, there's something wrong

The Five Whys is a powerful tool for helping teams develop their outcome muscles and mindsets, but it's often used as a temporary technique during the transition to outcomes.

As teams become more fluent at beginning with the end in mind (i.e., defining desired outcomes from the start), they naturally tend to rely less on this technique.

Using the Five Whys technique occasionally is fine, but if you always start with a specific project, that's a red flag.

Some process or tool in your organization may be forcing you to define specific projects before identifying the desired outcomes. If this is a recurring pattern, it's time to review your current practices.

You may need to unlearn or rethink some of them.

Using the Five Whys in practice

Here are a few tips:

Answer each “why?” with a clear outcome

You have to answer each “why?” question with a clear outcome: the measurable benefit you want to create, as we did in the examples above.

Learning to communicate your desired outcomes using clear language is one of the muscles you have to develop, so take the opportunity to practice this.

The real challenge is mapping the middle of the sequence

Usually, the real challenge is identifying the outcomes in the middle of the sequence. Don't give up easily: working on defining those outcomes will be a great exercise.

If you jump straight to the top-level outcome without identifying the ones in the middle, you are doing it wrong.

You don’t have to ask “why?” five times

You don’t have to ask “why?” exactly five times. Many teams do it in four or six steps, for example.

But the whole point is to ask “why?” a few times and map a sequence of outcomes. If you only ask “why?” once and stop at the first outcome you can find, you are doing it wrong.

The sequence of outcomes doesn't have to be a single line

I've used a single line of outcomes in my examples to keep things simple. However, you may find cases where one "why?" question leads to multiple outcomes, creating a "fork in the road" in the sequence:

The Five Whys can help you unlearn old mindsets

Seeing people use the Five Whys technique reminds me of the corrective exercises my physical therapist taught me.

Corrective exercises are physical activities designed to not only strengthen muscles, but also retrain the body to move in a healthier way. They help address muscle imbalances, improve posture, and restore proper movement patterns.

Corrective exercises help unlearn bad habits and behavior patterns that can cause pain or injury.

And that's what the Five Whys can do for you.

If properly used, it can be a great corrective exercise to help develop your outcome muscles and unlearn old mindsets at the same time.

Now it's your turn to use the Five Whys

The only way to develop your outcome muscles is through a lot of practice, so now it's your turn to use the Five Whys.

In my experience, the best way to do this exercise is to form a group of three to six people who work together and have them use the Five Whys on a real example.

Take a real project that you are working on or have already planned, and then go through the steps below.

1. Ask “why?” five times (or as many times as needed). Answer each “why?” with a clear outcome.

   Then, use each answer as the basis for the next “why?” question, mapping a sequence of outcomes.

2. Looking at the sequence of outcomes, select the one(s) you will focus on.

3. How can you measure the selected outcome(s)?

   Which metrics could you use? Do you need to create new metrics or use different ones than you typically do?

4. What other ideas could you test to achieve the selected outcome(s)?

Feel free to share your experience and insights from the exercise in the comments or via email. I’ll be back soon with another post.

If you’re finding this newsletter valuable, share it with a friend and consider subscribing if you haven’t already.

Share

This post builds on concepts discussed here and here. To get the most out of it, I recommend starting there.

This post is also available in Portuguese.

Subscribe now

Stephen Covey captured one of the core principles behind the outcomes approach in his famous quote: "Begin with the end in mind."

Start by clearly defining your desired outcome, why it’s important, and the constraints and guardrails for achieving it.

Then, work backwards to discover how to achieve the outcome. Experiment with different ideas or approaches to identify which ones will help reach it.

Amazon is famous for using a similar technique called Working Backwards, which is short for starting with the customer needs and working backwards from them (see callout below).

To better understand how to begin with the end in mind, let's look at an example:

Example

Desired outcome: Help customers solve issues without having to contact us.

Possible metrics we could use include:

• Self-service success rate: the percentage of customer issues resolved via self-service channels.

• Contact rate: the number of times customers contact a company for help within a given period.

Why it's important: It helps improve the customer experience and reduces costs at the same time.

Constraints: All solutions must be implemented within the existing software architecture and tech stack.

Guardrails: Avoid dark patterns such as making it impossible for customers to contact us.

Changes must not negatively impact the customer experience as measured by metrics like customer satisfaction score or net promoter score.

You don't have to use this exact format. This is just an example of the type of conversation you should have when beginning with the end in mind.

Why is beginning with the end in mind important?

Our brains are wired to think about projects.

When we see a problem, we naturally start thinking about what we can do, who can do it, and what's the due date.

We often operate on autopilot, doing what we’ve always done. When we do that, we go through the motions without questioning what we want to achieve or how we work.

It’s also extremely easy to fall in love with our ideas and believe they’ll all make a difference.

We all tend to fall into the know-it-all mindset, assuming that we have everything figured out and that all our projects will generate results.

I like to say that we have a Wile E. Coyote from the Road Runner cartoons living inside our brains.

Wile E. Coyote falls in love with our projects, and we start thinking, “Of course it’s going to work. It’s a brilliant idea!”

I've lost count of how many times I've heard people say they didn't need to measure the outcomes of their project because it was obviously going to succeed.

We all tend to fall in love with our ideas and believe in them.

The problem isn't being passionate about your work; it's what you're passionate about.

This famous quote from Ash Maurya is a critical reminder:

Love the problem, not your solution. Life's too short to build something nobody wants.

So, be passionate about what you're trying to achieve and the problem you're trying to solve.

Be passionate about making a difference in your work and helping customers or your colleagues. But don't get too attached to your specific solution or the project you're working on.

Beginning with the end in mind helps fight our tendency to think about projects by forcing us to pause and define the desired outcome.

Adding outcomes later is not enough

Many people set their OKRs in the wrong order. They begin by selecting the projects they'll work on and then set OKRs based on that.

For example, companies often start by creating a budget listing the specific projects they will fund and then create OKRs based on them.

At the same time, product teams often start with what’s on their backlog and put that on their OKRs. This happens even when leaders are trying to empower the teams—individual contributors also tend to fall in love with their ideas.

Sometimes, people try to fix this by adding outcomes after the projects have already been defined. The problem is that they often end up sticking to that predefined project list regardless of the outcome.

Focusing on outcomes means experimenting with different ways to achieve them.

If you are not testing different ideas—or different ways to implement the same idea—you are not focusing on outcomes.

Beginning with the end in mind is a simple and powerful concept that can help us focus on outcomes. But to apply it in practice, companies have to unlearn old mindsets and abandon practices that reinforce old behaviors.

Questions to reflect on

Here are two questions to help you discuss this article with your colleagues:

• Think about your most recent OKRs. Did you begin with the end in mind, or did you start with a list of projects?

• Look at your budgeting and planning processes. Do they help teams begin with the end in mind? What changes could you make to enable you to begin by defining your desired outcomes?

I’ll be back soon with another post. In the meantime, feel free to share your thoughts in the comments or email me.

If you’re finding this newsletter valuable, share it with a friend and consider subscribing if you haven’t already.

Share

This post builds on concepts discussed here and here. To get the most out of it, I recommend starting there.

This post is also available in Portuguese.

Subscribe now

As we've seen, the outcome-driven mindset is a fundamentally different way to lead people and manage work.

It doesn’t fit most organizations’ existing operating models, capabilities, processes, or cultures. It also doesn’t match most individuals’ existing skills and mindsets.

Unfortunately, most people don't understand that and end up falling into a common trap that I call the Tinker Bell approach. It goes something like this:

Sprinkle some of this pixie dust over your old way of working without changing anything else.

Your organization will magically work like the best companies. Everyone will suddenly become more aligned, innovative, focused, and will set more challenging goals.

This sounds like a joke, but the sad truth is that many people fall for it. They say they want outcomes but continue to focus on meeting project due dates as they always have.

People apply the Tinker Bell approach not only with outcomes but also with OKR, the product model, Agile, and anything that becomes trendy in the business world.

A few years ago, the “Spotify model” became the most popular pixie dust. Several companies started to call their teams “squads” without making any meaningful changes.

The same pattern is beginning to repeat itself with the product model. Some organizations are telling employees they are now product managers without even asking if they want to be PMs.

Like that popular definition of insanity, these companies keep doing the same thing over and over while expecting different results.

But my favorite example is the bank that had been using a KPI dashboard in its technology department for several years. One day, a senior executive decided to swap the dashboard's label from "KPIs" to "OKRs"—without changing anything else. Then, he presented the dashboard to the teams saying, "Here are our OKRs."

As you can imagine, the bank got no results from OKR.

Overcoming legacy thinking

Several organizations have invested in abandoning legacy systems, but most haven’t abandoned legacy thinking.

As companies grow, they often have to deal with legacy systems, outdated software still in use.

For scale-ups, it can be a platform developed in a rush during a high-growth phase. For traditional companies, it can be an application developed in the 90s.

Legacy thinking is something very similar. It includes outdated mindsets, beliefs, practices, and processes still in use.

Just like legacy systems, legacy thinking may fulfill its initial purpose, but it’s incompatible with modern approaches and limits the organization’s ability to innovate and change.

Examples of legacy thinking include treating teams as order takers, believing there's no need for measurement or experimentation, and funding specific projects instead of outcomes.

To focus on outcomes, organizations have to address legacy thinking as seriously as they address legacy systems.

To focus on outcomes, you have to unlearn

If you simply want to say you are focusing on outcomes—or using OKR—the Tinker Bell approach is for you.

But if you want to benefit from outcomes and get results from OKR, you must change your organization’s operating model and culture at a fundamental level.

It starts by developing your outcome muscles, as we’ve been talking about—here, here, here, and here for example. But that’s not enough.

To focus on outcomes—and succeed with OKR—you have to unlearn.

The best definition of the unlearning process comes from my friend Barry O’Reilly, author of the book Unlearn:

Moving away from mindsets and behaviors that were effective in the past, but now limit our success.

We have a series of mindsets, behaviors, and management practices that were effective 10, 20, or 50 years ago, but are now limiting our success. We need to unlearn them.

Many of the techniques, approaches, and processes we’ve been taught are just like legacy computing systems. They may still meet the needs they were originally designed for, but now they are limiting our success.

I’m not saying that everything you are doing now is wrong or that you have to unlearn everything.

But unlearning is hard, and you have to commit to unlearning what is hurting your ability to succeed.

Leaders must commit to unlearning

The unwillingness of leaders to change their own behaviors is one of the main causes of failure for large change initiatives and transformations.

As Patrick Lencioni points out:

The single biggest factor determining whether an organization is going to get healthier—or not—is the genuine commitment and active involvement of the person in charge.

To focus on outcomes and get results from OKR, leaders have to commit to unlearning.

One of the things we have to unlearn is the idea that leaders have to know everything and have all the answers. Instead, leaders must be willing to learn everything.

As Microsoft's Satya Nadella likes to say:

Don't be a know-it-all. Be a learn-it-all.

Senior leaders and individual contributors have to unlearn the mindsets, behaviors, and methods that are limiting their success.

The organization must also abandon any practice that reinforces legacy thinking. If a process, method, framework, workflow, metric, or incentive reinforces old behaviors, you must scrap it.

The table below lists some of the things we have to unlearn if we want to focus on outcomes:

What else do you have to unlearn?

And how about you, what else do you have to unlearn to be able to focus on outcomes?

I’ll be back soon with another post. In the meantime, feel free to share your thoughts in the comments or email me.

If you’re finding this newsletter valuable, share it with a friend and consider subscribing if you haven’t already.

Share

Welcome! If this is your first time here, I recommend reading the articles linked below first, as today's post builds on concepts discussed in them:

• It’s time to be outcome driven.

• An OKR should measure the outcome, not the work.

• What if you can’t measure the outcome?

This post is also available in Portuguese for my friends in Brazil.

Subscribe now

After last week's article, I received several questions about how to use the two bucket technique in practice. I'll try to answer them in this post.

Barry (not his real name) shared a common situation:

I'm curious about how using the two buckets compares to a different method I learned where you explicitly connect projects to each Key Result, as shown in this example:

The method above sounds nice in theory, but in practice it creates two challenges:

1. Some people end up focusing on the projects. They ignore or don't really care about the Key Results.

2. We have some essential projects that don't tie to an OKR and it's not clear what we should do with them.

Your two-bucket approach helps address #2. But how can we achieve our OKRs if we don't have projects explicitly connected to them?

To answer Barry's questions, we need to understand that focusing on outcomes requires a fundamental mindset shift.

Admitting we can't know everything in advance

You've probably seen a lot of advice like the example shared by Barry in the image above.

You are told to map out a list of projects under each Key Result so you can plan exactly what you're going to do to achieve your OKR.

The problem is that people often end up sticking to that predefined project list regardless of the outcome. When they do that, they focus on projects, not on outcomes.

They are only using OKR on paper.

The company may have OKRs, but people don't take ownership over them, and focus on projects instead. OKR is seen as a formality that doesn't guide day-to-day work.

This is another situation that shows that we need to develop new muscles and mindsets, as most organizations are not ready for outcomes.

Truly focusing on outcomes requires a fundamental mindset shift.

Using the outcomes approach requires admitting that we can't know everything in advance and that some of our projects won't generate the expected outcomes.

In real life, even ideas that seem obvious and are executed flawlessly can fail to meet expectations.

That means we can't create a list of all projects we'll ship in the quarter and stick to it. Instead, we have to quickly test different ideas to discover which ones will help achieve the outcome.

To do that, we have to develop new muscles: the skills and organizational capabilities to enable people to run experiments and quickly test ideas.

The table below contrasts the implicit assumptions behind the outcomes approach and the due dates approach.

How to use the two buckets

I always try to keep things as simple as possible in my writing. However, I may have gone too far in simplifying my last article. I left too much information implicit and made it harder for people to fully grasp the concepts.

Let me fix that by providing a more detailed explanation about how to use the two buckets, with slightly different wording than I've used before.

The core idea is to imagine that we are going to put our investments and priorities into two “buckets”:

In the first bucket, we'll put the investments that are focused on achieving outcomes and will be managed using the outcomes approach.

In the second bucket, we'll put the investments that are focused on meeting project deadlines and will be managed using the due dates approach (also known as the “PMO approach").

Investments with outcomes we can measure go into the outcomes bucket, while investments with outcomes we can't measure—at least for now—go into the bucket focused on due dates.

Both buckets contain projects inside

To be clear, both approaches for managing work use projects, but they do it in completely different ways.

One way to visualize this is to imagine we have two "layers" inside both buckets. On top, you have your desired outcomes, and underneath them you have projects to help achieve those outcomes:

Inside the outcomes bucket, we have an OKR on top and projects at the bottom. These projects are just ideas for achieving the outcome, and we have to discover which ones will help us do that.

The list of ideas can change at any time. We can test different ones or test different ways to implement the same idea.

For example, let's say one of your ideas is to redesign the account registration flow of your app. There are multiple ways you could do that, and you may want to quickly test different options to discover which one will help reach the outcome.

Inside the bucket focused on due dates, we find something different: projects where the link to outcomes is missing or unclear. That's why I call them “projects without outcomes”.

The intended outcome may be undefined or challenging to measure with our existing muscles. In some cases, people overlook the outcome even if it was previously defined and measured.

Without an outcome associated with them, these projects become the goal. Teams focus on completing a predefined list of deliverables rather than doing discovery and testing different ideas.

Using the due dates approach is not a problem. The problem is overusing it.

Sometimes we have projects we simply have to deliver. And there are some types of work that are better managed using due dates.

But there are many investments that companies “should” manage using outcomes, but don't.

Besides our OKR, we have to complete our projects without outcomes

Here's an example of the two buckets:

In addition to achieving our OKR, we also have to complete these projects without outcomes, or just projects, for short.

To do that, we have to do two things.

First, we have to include these projects without outcomes alongside our OKRs when setting OKRs at the beginning of the quarter and when tracking progress during the weekly check-ins.

Second, we have to ensure we continue to test different ways to achieve the OKR. Our list of ideas has to remain flexible instead of turning into a fixed project roadmap.

This enables us to stay focused on the outcome rather than just completing predefined tasks.

To achieve those two things, we have to start thinking about OKR + Projects.

The OKR + Projects format allows us to communicate and track our desired outcome and our projects without outcomes side by side:

The OKR + Projects format does not include the list of ideas, and that's intentional.

We want to have separate conversations about our OKR+Projects (in blue) and our ideas or experiments to achieve the OKR (in green):

We have to focus on our OKR + Projects when discussing our priorities for the quarter and during the weekly check-ins.

Teams can share brief highlights of the ideas they are testing or planning to test, but they should avoid detailed updates that can take a lot of time and distract from the outcomes.

We must resist the urge to turn these discussions into detailed project reviews or brainstorming sessions for new ideas to test.

Our brains are wired to think about projects, and it's extremely easy to start prescribing specific solutions for the teams. We all fall into this trap from time to time, myself included.

Leaders may choose to “Dive Deep” and help the teams with the details of the ideas being tested, but that has to be a separate conversation from the OKR check-in.

This deep dive should focus on understanding what the teams have learned, the data they have, the experiments they have run, and their main hypotheses moving forward.

Let’s put this into practice

The best way to put this article into practice is by discussing its main takeaways with your colleagues or friends.

Here are a few questions to help:

• Are you only using OKR on paper? Are you focusing on projects instead of using OKR to guide your day-to-day decisions?

• Are you comfortable with the idea of not knowing everything in advance and adapting plans as you go? What steps could you take to adopt this mindset?

• How can you use the OKR + Projects format to better communicate priorities and track progress?

• What can you do to ensure you continue to test different ways to achieve the OKR? How can you avoid turning your list of ideas into a fixed project roadmap?

• How can you avoid prescribing specific solutions for the teams?

I’ll be back soon with another post. In the meantime, feel free to share your thoughts in the comments or email me.

If you’re finding this newsletter valuable, share it with a friend and consider subscribing if you haven’t already.

Share

This post builds on concepts discussed in the articles below. To get the most of it, I recommend reading them first:

• It’s time to be outcome driven.

• An OKR should measure the outcome, not the work.

This post is also available in Portuguese.

Subscribe now

There's a common journey when people start developing their outcome muscles1.

In the beginning, organizations usually act as if anything could be an OKR.

Their Key Results include projects, such as “Launch our new website,” and project metrics, like “Move 100% of the servers to the cloud.” Some OKRs are so confusing that it's hard to understand what they mean.

Unfortunately, most companies never move beyond this stage and wonder why they aren't getting results from OKR.

As people start to develop new muscles and mindsets, all their OKRs become outcomes.

But only tracking outcomes leads to a common challenge.

At this stage, people usually can't or don't know how to measure the outcomes of many of their investments.

Sometimes, the outcome is unclear, the organization doesn't have metrics for it, or doesn't collect the data to measure it.

As a consequence, a large part of the company's investments—and a large part of what the teams are working on—is not represented in the OKRs.

A large part of the organization's investments and priorities disappear from view when tracking OKRs.

This lack of visibility can cause confusion, misalignment, and frustration among the teams, making them feel like their work doesn't matter.

What should you do if you can't measure the outcomes of your investments?

Put investments in two buckets

A useful analogy is to imagine that we are going to put our investments and priorities into two “buckets,” representing the approaches for managing work.

If the term “investments” sounds a bit foreign to you, think about your team's priorities instead. Where are you investing your time?

In the first bucket, we'll put the investments that are focused on achieving outcomes and will be managed using the outcomes approach.

In this group, we can clearly define our desired outcomes and how to measure them. We'll test different ideas until we achieve each outcome.

In the second bucket, we'll put the investments that are focused on meeting project deadlines and will be managed using the due dates approach (also known as the “PMO approach").

Here we have projects that don't have an outcome directly associated with them, at least for now. These are the “projects without outcomes".

Investments with outcomes we can measure go into the outcomes bucket.

Investments with outcomes we can't measure—at least for now—go into the bucket focused on due dates.

Managing two buckets: OKR + Projects

To manage those two buckets, we need to start thinking about OKR + Projects.

The idea is that besides achieving our OKR, we also have to deliver these projects without outcomes, or just projects, for short.

Here's an example:

Using the two buckets can bring several benefits

Adopting the two buckets technique is a small change that can bring several benefits. It only takes a bit of discipline.

First, the two buckets give visibility to all your important investments and priorities, whether managed by outcomes or due dates.

Many teams choose to track both buckets during the OKR check-in to simplify things.

Thinking about OKR + Projects also helps you develop the muscles and mindsets needed to focus on outcomes. It forces you to separate outcomes from projects and project metrics.

Using this technique means there's absolutely no reason to put projects in your OKRs. Just put them in the due dates bucket—a project by another name is still a project.

Using the two buckets can also help you focus.

A common trap is limiting the number of your OKRs to show you are focused but keeping multiple projects running in parallel “on the side.” This way, you avoid having to say no.

Visualizing all the projects you have going on can be a powerful tool to help you focus by limiting your work in progress (WIP).

Finally, the two buckets help you understand where your investments are going. Are you investing to achieve outcomes or just meet due dates?

They also enable an important conversation about whether you are using the best approach to manage each investment.

"How should we manage this investment?"

Separating your investments into two buckets allows you to review each one and ask, how should we manage this investment?

Most companies realize they are using way more due dates than they should. There are many investments that they “should” manage using outcomes, but don't.

While there's no single right answer, many investments are naturally more suited to be managed using either outcomes or due dates.

For example, if you are investing in a new self-service app to help customers solve issues without having to contact support, you should probably focus on that outcome.

But there are cases where there is little benefit in trying to apply the outcomes approach.

Small dependencies should be managed using due dates

One common situation is when you need to do something small to help another team achieve their outcome. Those small dependencies are often better suited to be managed using due dates.

If helping the other team will take up a lot of your time, it often makes sense to create a shared OKR with them and work together for a common outcome.

But you can't use shared OKRs for every small dependency, or you'll end up with dozens of OKRs.

For example, let's say the company lawyer has to review several small contracts with vendors or partners that other teams need to achieve their outcomes. Managing those contracts using due dates is probably the best choice.

But if the lawyer is helping the sales team negotiate a multi-million dollar deal with its largest customer ever, a shared OKR would be a great option.

Some types of work are better managed using due dates

Another common example is when engineers have to apply security fixes to eliminate vulnerabilities in an application.

The team could try to track the number of completed security updates, but that's just a project metric. It measures the work done but not if it made a difference.

Much of the work related to compliance, risk, and regulatory demands is similar. Often, there's a long list of tasks that need to be done and the available metrics simply track their completion.

Instead of trying to shoehorn these examples into outcomes, it's often easier to manage them as projects without outcomes. That doesn't mean this type of work isn't important—it simply means that it's often better managed using the due dates approach.

But teams shouldn't blindly follow orders. Leaders must help product teams collaborate with stakeholders to understand how to reduce risk or comply with regulations while providing a good customer experience.

As you develop your outcome muscles and mindsets, you'll be able to move to the next stage in your journey.

More Outcomes, Fewer Dates

Separating your investments into two buckets makes it abundantly clear when you are overusing due dates.

As companies continue to develop new muscles and mindsets, they work towards More Outcomes, Fewer Dates. They intentionally increase the “share” of their investments managed with outcomes and data over time.

We are not talking about zero dates but fewer dates.

More Outcomes, Fewer Dates is about deliberately choosing the best approach for each context and developing the muscles and mindsets to make that happen.

That means building new skills and mental models in people, but also developing the capabilities and mechanisms in the organization to enable those skills.

In my experience, many companies can increase the use of outcomes in the first quarter after adopting the two buckets.

The initial changes needed are often simple. For example, creating a new metric based on existing data or tracking outcomes that the company was already measuring but had been ignored.

Other changes take time, as they require deeper shifts in the organization's operating model and culture. You won’t get there overnight, but it’s possible to make improvements every quarter.

We'll dive deeper into More Outcomes, Fewer Dates in an upcoming article. We'll also discuss how to measure outcomes that are hard to measure. For now, let's clarify a few things.

You may have to work on a project now so you can focus on an outcome later

Before you can measure an outcome for the first time, there's usually some preliminary work necessary.

People often have to collect the necessary data, create reports, or define a new metric—which are all examples of developing outcome muscles one step at a time.

Often there's no time to complete this setup for all your intended Key Results before the quarter begins. The solution is to add those preliminary tasks to your list of projects without outcomes to ensure they won’t be overlooked.

You have to work on that preparation project now so you can focus on your desired outcome later.

However, there's no need to wait until the next quarter to start working on that outcome. As soon as this initial setup is done, you can add a new Key Result to your OKR and start tracking it.

Adding a new Key Result mid-quarter is fine, as long as it's truly important and you don't end up with too many of them.

Meeting a due date can be as crucial as any outcome

Putting something in the due dates bucket doesn't make it less important. Meeting a deadline can be as crucial as any outcome.

Years ago, I worked with a payments company that had a few critical deadlines they couldn't afford to miss.

Visa and MasterCard issued mandatory updates every six months or so. If these updates weren't implemented on time, the company risked losing the ability to process card payments—which is kind of important for a payments company.

The company ensured these critical projects were visible to everyone by using the two buckets technique and tracking them alongside their OKRs.

Product teams need time for discovery before committing to due dates

The payments company is not alone. All businesses have to commit to due dates from time to time, and meeting these deadlines is crucial to moving to the product model.

That means empowered product teams need to be able to make what Marty Cagan calls high-integrity commitments.

A high-integrity commitment is a promise made by a product team to meet a crucial business deadline while having a high confidence in their ability to deliver.

To ensure leaders can rely on these deadlines, product teams need time to do product discovery before committing to due dates.

As Marty Cagan wrote in Empowered:

Once the product team believes they understand the solution sufficiently, they can estimate with high confidence how long it will take for them to deliver on this commitment (feasibility), and also whether that solution will work for the customer (value and usability) and work for your company (viability).

High-integrity commitments should be the exception, not the rule, and should be used only for critical deadlines.

Meeting a due date is often not enough—you must also achieve the desired outcome

More often than not, you can't simply commit to meeting a deadline. You also have to achieve the desired outcome.

For example, many companies have to ensure their websites are ready in time for Black Friday. That means all the special deals have to be up, but also that the website is able to handle all the additional traffic without problems.

Simply shipping a feature on the agreed due date is not enough. The feature also has to achieve the intended outcome: what is the measurable benefit you want to create for the customer and/or the business?

Without discipline, you'll end up with a long list of projects and due dates

Our brains are wired to think about projects and due dates. Without discipline, you’ll stick to your habits and end up with a long list of deliverables and deadlines.

Here are five tips that will help:

1) Never stop developing your muscles and mindsets

If you want to benefit from outcomes or OKR, you must never stop developing your outcome muscles and mindsets. Continuous improvement is key.

People often stop after an initial win, but the best companies continue to evolve quarter after quarter.

2) Never mix outcomes (or OKRs) with projects

Never include projects or project metrics in your OKRs. Always manage the two buckets separately.

Remember: there's no benefit in claiming your project is a Key Result.

3) Only give up after trying to define the outcome for 30 minutes

Before deciding to manage an investment as a project, I want you to pause and dedicate the time to try to define the desired outcome.

Most people give up in 30 seconds. I want you to spend at least 30 minutes.

At the very least, this will help develop your outcome muscles and mindsets.

You may also learn you need to do some preparation work now so you can focus on the outcome later.

If 30 minutes seems like too much, ask yourself if the investment is really important. Maybe it's not worth doing at all.

Some investments are better managed using due dates, but you can only make that decision after putting in the effort to define the outcome.

4) When in doubt, put it in the due dates bucket

It's natural to be unsure if something is an outcome, especially at the beginning. If you are not sure if something is an outcome, put it in the due dates bucket.

5) Perform quarterly project cleanups

Most companies have way more ongoing projects than they should.

These companies spread their investments across multiple priorities instead of focusing on the handful of goals that will move the needle.

That's why you should perform quarterly project cleanups: once a quarter, go through all the items in your due dates bucket—all your ongoing projects—and drastically reduce their number.

Which projects are not aligned with the strategy? Which ones are desirable but not critical?

Let’s put this into practice

We’ll be back soon with another post. In the meantime, the best way to put this article into practice is by discussing its main takeaways with your colleagues or friends.

Here are a few questions to help:

• Check your current OKRs. Are there any projects or project metrics that should be moved to the due dates bucket?

• Separate your investments or priorities in the two buckets. How much of your work is managed using outcomes vs. due dates?

• Review the items in your due dates bucket. Can you identify simple changes you could make to measure outcomes?

• Which projects can you eliminate?

Feel free to share your thoughts in the comments or email me.

What to read next

Learn how to use the two bucket technique in practice in our next article.

If you’re finding this newsletter valuable, share it with a friend and consider subscribing if you haven’t already.

Subscribe now

Welcome to another article in our series about building outcome-driven organizations and getting results from OKR. If you haven’t read the first article yet, I recommend starting there.

This post is also available in Portuguese for my friends in Brazil.

Subscribe now

Most companies are getting a due date overdose without realizing it.

As the VP of HR at a global consumer goods company told me:

70% of our employees’ individual goals involve a project due date. And we’re not even talking about major strategic projects, but smaller deliverables that alone don’t mean much.

Overusing due dates builds a culture that values shipping projects over making a difference.

It also hurts investment returns and kills innovation. Leaders can't see which investments are working or not, while employees are treated as order-takers with no empowerment.

This due date epidemic is so pervasive that even leaders who think they have mastered OKR often fall into it. I remember an email exchange with a CEO from a fast-growing "scale-up”:

CEO: We have an advanced level of maturity with OKR. Here are the OKRs for our company and our two product lines.

Felipe: People often think they "already know" OKR, but, unfortunately, it's an illusion.

The most common pitfall is using OKR to track projects and due dates instead of achieving outcomes. You are also falling into this trap—everyone does.

In a preliminary assessment:

• 8 of the 19 company "Key Results" are project-based. For example, “Implement the new process in Salesforce by June.”

• 5 of the 13 "Key Results" from product A are project-based. For example, “Implement the new mobile app MVP by March 30th.”

• 8 of the 15 "Key Results" from product B are project-based. For instance, “Develop and deploy the new churn prediction model in Q2.”

You also need to focus. There's a lot going on.

CEO: I didn't realize that. These seemed like good OKRs to me. I guess we need more help than I imagined.

Your company is likely in a similar situation, with many OKRs (or goals) focused on meeting project deadlines.

To solve this problem, we have to develop new muscles and mindsets.

Leaders and employees must develop the skills needed to focus on outcomes, while the organization must develop the capabilities and mechanisms to enable those skills.

Leaders and employees also have to unlearn the mindsets that contributed to this situation.

In this article, we'll begin to develop your outcome muscles and mindset.

First, let’s do a quick recap. Feel free to skip to the next section if you've just read the first article in this series.

Recap

All companies use two approaches to manage work. One approach focuses on achieving outcomes, while the other simply focuses on meeting due dates. In the due dates approach, it doesn’t matter if our projects made a difference or not.

The problem is that your “outcome muscles” are probably too weak, while your “due date muscles” are too strong.

This weakness makes your organization lean too heavily on due dates, especially when paired with the wrong mindsets.

Most organizations focus a large share of their investments on meeting due dates and implicitly assume all projects will generate results.

The first step to solving a problem is to recognize it exists

The first step in developing your outcome muscles is learning to separate outcomes from projects and project metrics. Why is that important?

You can't solve a problem you can't see.

Imagine your doctor told you to eat healthier, but you didn't know how to differentiate junk food from healthier options. Pizzas, burgers, meat, chicken, fruits, vegetables—to you, it's all food.

Improving your health in this situation would be very hard.

Now imagine that your doctor helped you learn the difference between proteins, carbs, and fats and to pay attention to where your calories come from.

As you begin to do that, you start to see how you're doing today and where you can improve.

This story may seem a bit far-fetched, but most organizations are in a similar situation with OKRs. They want results but don't know how to differentiate "junk food” OKRs from healthy ones. They act as if anything could be an OKR.

The consequence is that these companies have difficulty understanding where their investments are going. Are we investing to achieve outcomes or just meet due dates?

These companies' Key Results include outcomes, projects, unimportant metrics, non-measurable things, and anything else you could think of. Sometimes, it's hard to understand what they mean.

Even the #1 book on OKR, Measure What Matters, acts as if anything could be an OKR. Here's an example from the book:

OBJECTIVE

Institute a culture that attracts and retains A players.

KEY RESULTS

• Focus on hiring A player managers/leaders.

• Optimize recruitment function to attract A player talent.

• Scrub all job descriptions.

• Retrain everyone engaged in the interviewing process.

• Ensure ongoing mentoring/coaching opportunities.

• Create a culture of learning for development of new and existing employees.

There's not a single number in the whole OKR. There are no metrics to measure outcomes or track progress.

This is just a list of projects and vague, generic phrases that sound nice but don't clearly define the intended outcome.

For example, what's the use of saying that you'll “focus on hiring"?

I can imagine the conversation inside the company:

Manager: Hi John, have you hired any A players?

John: No, boss. But I'm really focused on it. And that's all I have to do according to my Key Result.

Something similar is likely happening in your company right now. It's not your fault, but you need to fix it if you want to get results from OKR.

The first step is learning to distinguish outcomes from projects and also distinguish outcomes from project metrics.

Projects are what you do, outcomes are the measurable benefits created by what you did

There's a lot of confusion around what outcomes are. Luckily, I've found a precise and actionable definition inspired by Robert M. Penna's work with nonprofits:

Outcomes are the measurable benefits we want to create.

These include the benefits you want to create for your customers, your organization, or other employees.

Outcomes change the conversation, framing it around two questions:

• What benefit do we want to create?

• How will we measure it?

Separating these two questions is important because it makes it easier to first think about the qualitative benefit you want to create and then figure out the metrics.

For example, let's say the benefit we wanted to create was to make our app easier to use.

Possible metrics we could use in this case include:

• Number of support requests.

• Percentage of users successfully completing account registration.

• Time spent to complete a purchase.

Separating outcomes from projects

We need to make the crucial distinction between projects and outcomes:

• Projects are what you do.

• Outcomes are the measurable benefits created by what you did.

I'm using “project” as an umbrella term for everything we do, big or small. This includes activities, tasks, programs, initiatives, deliverables, actions, epics, features, backlog items, etc.

For example, “Redesign the account registration flow" is a project. “Make our app easier to use” is an outcome (with different metrics associated with it).

The key distinction is between things that you do and the measurable benefits created by what you did.

If it can go in your backlog, it's not an outcome

There's a powerful litmus test to separate projects from outcomes:

If it can go in your backlog, it's not an outcome.

Outcomes are the consequences of what you did. An outcome is not something that you can do—or put in your backlog.

Projects are not the problem—the problem is focusing on projects

When people first learn about outcomes, they sometimes think projects are “bad.” But we need to work on projects to achieve our outcomes (of course).

Projects are not the problem. The problem is focusing on projects.

As Marty Cagan told me:

The outcomes approach is about focusing on the difference we want to make and never losing sight of it.

However, people often focus on projects even when the desired outcomes are clear and easy to measure.

A client's story illustrates that:

One day, a startup CEO found that the number of new sales leads was way below target and website traffic was down.

She decided to question the Head of Marketing:

CEO: The number of new leads is way below target. And the website traffic is falling.

Head of Marketing: But we’ve hit our OKR. We published 15 posts and three videos, did two webinars, and met all the due dates.

CEO: But the leads and traffic are terrible.

Head of Marketing: But these are not in our OKR!

The intended outcome was not only easy to measure, but the company was already tracking it. Not all cases are that simple, but this situation happens more often than you imagine.

When the project is just a means to achieve the outcome

When we focus on projects, we act as if the goal is delivering them.

But being outcome-driven is believing that we work to make a difference, not just complete projects.

That means that most of the time, delivering the project is not the goal—the project is just a means to achieve your desired outcome.

(We'll discuss how to handle the specific cases where the goal is delivering the project in our next article.)

Our brains are wired to think about projects, so focusing on outcomes requires conscious and deliberate effort.

One powerful trick is pausing and asking:

Is this project really our goal or just a means for achieving an outcome?

Is this project just an idea for achieving the outcome?

The table below contrasts seeing the project as the goal versus seeing it as a means to accomplish the outcome.

Focusing on outcomes means you need to test different ideas

The whole point of focusing on outcomes is that you have to adjust course based on the data. We have to test different options until we achieve the outcome.

If it's working, you do more of it. If not, you try something else.

But when people believe their goal is simply to meet project due dates, they often do the opposite. They define everything they'll ship in the quarter in advance and stick to the plan, even when things aren't working as expected.

They don't test new ideas or adjust the backlog based on the data.

I remember a conversation during an OKR Check-in with a client:

Team member: The infrastructure team had to deprioritize the server migration project, so we won’t be able to achieve our Key Result.

Manager: But we still have two months until the end of the quarter. What else can we do to achieve the outcome? We want to focus on the outcome, not on a single project.

There’s also the common case where a project doesn’t make a difference. They could have migrated the servers and still not have achieved the outcome.

That's why outcome-driven companies treat projects as experiments, rapidly testing ideas to discover which ones will help achieve their desired outcomes (in the product model, this is called product discovery).

Now that we've covered the difference between outcomes and projects, let's discuss project metrics.

Not all metrics measure outcomes

People often believe they just have to make their Key Results “measurable”. After all, we've been taught to focus on measurable goals.

But just because something is “measurable,” it doesn’t mean it’s an outcome. That's why we need to understand the difference between outcomes and project metrics:

• Outcomes (together with their associated metrics) measure the benefit we want to create. They measure if we are making a difference.

• Project metrics measure project progress. They measure how many things we did.

Here are a few examples of project metrics:

• Train 100% of managers in OKR by June.

• Publish 10 posts.

• Move 100% of servers to the cloud by the end of Q3.

• Increase the number of published APIs from X to Y.

The questions you need to ask are, are we measuring if we are making a difference? Or are we just counting how many projects or activities we did?

A real OKR communicates the outcome you want to achieve and how you will measure it

Intel created a fill-in-the-blanks formula to help people set good goals. It's the best way to explain the structure of an OKR:

I will ________ as measured by ____________

The idea is that a proper goal has to describe the outcome you want to achieve and how you are going to measure it. That's why the words "as measured by" are so important.

We could rewrite the formula as:

I will achieve this outcome as measured by these metrics.

The two OKR components, the Objective and the Key Results, fit perfectly in the “as measured by” formula:

I will Objective as measured by Key Results.

We can see that the Objective communicates the outcome we want to achieve while the Key Results show how you are going to measure it.

Or, to put it another way:

A real OKR communicates the outcome you want to achieve and how you will measure it.

For example, we could easily take the outcome we've seen before and rewrite it in OKR format:

Objective: (What is the outcome?)

Make our app easier to use.

Key Results: (How will we measure it?)

• Reduce user support requests from X to Y.

• Increase the % of users successfully completing account registration from X% to Y%.

• Reduce time spent to complete a purchase from X to Y.

And here's a hypothetical OKR example from Uber:

Objective: (What is the outcome?)

Provide faster and cheaper rides

Key Results: (How will we measure it?)

• Reduce average pick-up times during peak hours from X to Y.

• Reduce rides canceled by drivers from X% to Y%.

• Reduce average price/mile during peak hours from X to Y.

There is no benefit in saying your projects are “Key Results"

Let's contrast the two OKRs above with another bad example from Measure What Matters:

OBJECTIVE

Deliver awesome end-to-end workforce technology solutions and strategies.

KEY RESULTS

• Implement Box pilot for first 100 users by mid-quarter.

• Complete BlueJeans rollout to final users by end of the quarter.

• Transfer first 50 individual account Google users to enterprise account by end of the quarter.

• Finalize Slack contract by end of month 1 and complete rollout play by end of the quarter.

This is not a real OKR.

The Objective focuses on “delivering solutions” instead of communicating the outcome. The Key Results are just a bunch of projects, project metrics, and due dates.

There is no benefit in saying your projects are now “Key Results.” A project by another name is still a project.

OKR should measure the outcome, not the work

OKR is just a tool, and the results you get depend on how you use it.

How you use OKR matters: OKR can either cultivate an outcome-driven culture or reinforce a culture focused on due dates.

OKR should measure the outcome, not the work.

The best way to put this article into practice is by discussing its main takeaways with your colleagues or friends.

Here are a few questions to help:

• Take a look at the existing Key Results (or goals) within your organization. How many of them are projects instead of outcomes?

• Think of a recent project. Was the goal just to finish it, or to drive an outcome? What outcome were you aiming for?

• Do teams inside your organization adjust course based on the data or do they stick to the plan regardless of the results?

• Take a look at the metrics used inside your organization. How many track project progress instead of outcomes?

• Is the way your organization uses OKR reinforcing a culture focused on projects and due dates?

• Think about your company's internal processes. Are teams able to adjust plans based on results? What would need to change to enable a more outcome-driven approach?

Feel free to share your thoughts in the comments or email me.

What to read next

Our next article addresses a common challenge: What if you can’t measure the outcome?

If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already.

Subscribe now

This post is also available in Portuguese for my friends in Brazil.

Subscribe now

Outcome-driven leaders define success based on outcomes, but they don’t stop there. They also treat organizations like products—something they can design, test, and improve.

Steve Jobs was the ultimate example of a leader who managed the company as a product. When asked about which product he was most proud of, he replied:

You know, making a product is hard, but making a team that can continually make products is even harder. The product I’m most proud of is Apple and the team I built at Apple.

Outcome-driven leaders treat each element of the organization as a “product feature” that exists to help the organization succeed.

These “organizational features” include things like processes, metrics, rituals, reports, structure, data, tools, skills, and behaviors.

Paraphrasing Dharmesh Shah, co-founder & CTO of HubSpot:

Every company builds two products, one is the product they build for their customers, and the other is a product they build for their team

Your company’s culture and operating model together form the product you build for your team. They exist to help the great people you have do great things for your customers and your company.

In this article, we’ll discuss what it means to treat your organization as a product and the mindsets and behaviors that prevent people from doing that.

Outcome-driven leaders intentionally design how the organization operates

All companies have a culture and an operating model, whether they were intentionally designed or not.

The difference is that outcome-driven leaders intentionally design each element of their companies. They deliberately evolve their culture and ways of working to facilitate achieving outcomes.

As tech blogger John Gruber points out, Steve Jobs was very intentional about how Apple should work:

The same thought, care, and painstaking attention to detail that Steve Jobs brought to questions like “How should a computer work?”, “How should a phone work?”, “How should we buy music and apps in the digital age?” he also brought to the most important question: “How should a company that creates such things function?”

Outcome-driven leaders regularly ask questions such as:

• What behaviors do we want to reinforce and encourage in people? Which ones do we want to inhibit?

• What factors are hindering our performance? Which ones are helping?

• How can we create an environment where teams can perform at their best?

Let’s take a deep dive on an even more powerful question.

Will it help achieve our desired outcomes?

Ben Hunt-Davis is a leadership coach who won a gold medal as part of the British rowing team in the 2000 Olympics. His key principle is, “Will it make the boat go faster?” Meaning, will this help the organization succeed?

Outcome-driven leaders do something similar. They challenge everything their organizations do—or don’t do—with the question: “Will it help achieve our desired outcomes?”

If it helps accomplish their intended outcomes, they keep doing it. If it doesn’t, they try something different.

This philosophy applies to what they work on (product features and projects) and also to how they work (their operating model or ways of working).

Each element of your company’s operating model or culture exists for a reason—helping the organization achieve its mission and desired outcomes.

Outcome-driven leaders are willing to change or abandon anything that is not helping their organizations make a difference. They are also ready to unlearn old mindsets and behaviors.

This way of thinking is not new. One hundred years ago, Henry Ford preached something similar:

Be ready to revise any system, scrap any method, abandon any theory, if the success of the job requires it.

This flexibility enabled Ford to achieve a productivity miracle with his continuous-motion assembly line, decreasing the worker hours required to produce a Model T car by nearly 90%.

Outcome-driven leaders work on two fronts at the same time

Here’s another way to view this: outcome-driven leaders work on two fronts at the same time. They work on achieving their intended outcomes, but also on optimizing the organization to achieve outcomes (hat tip to Marty Cagan for the expression).

An old saying helps us understand what that means: “If I had five minutes to chop wood, I would spend the first two and a half minutes sharpening my axe.”

Following this analogy, outcome-driven leaders balance two dimensions:

• Achieving outcomes (“Chopping wood”): Work to accomplish their intended outcomes using current practices and workflows.

• Optimizing the organization to achieve outcomes (“Sharpening the axe”): Work to improve how the organization operates, evolving its culture and ways of working to facilitate the achievement of outcomes.

Steve Jobs hinted at those two fronts when talking about “making a product” (chopping wood) versus “making a team that can continually make products” (sharpening the axe).

Successful companies use OKR to sharpen the axe

You may be wondering how OKR fits into this discussion.

I’ve been helping companies around the world adopt OKR and outcomes since 2014. After training and mentoring thousands of people, I noticed a clear pattern separating the companies that succeed with OKR from the rest:

Successful companies use OKR to sharpen the axe, evolving their culture and ways of working.

But the vast majority of people make OKR fit their old way of working. Like that popular definition of insanity, they keep doing the same thing over and over while expecting different results.

OKR can be a powerful tool to help build an outcome-driven culture and optimize your organization. But it can also help keep things exactly the same. It all depends on how you use it.

Some people refer to the two fronts above as running the business vs. changing the business. But according to research, most companies make limited changes to how they work, and the result is that 70% of transformations fail.

I’ve repeatedly encountered an ironic example of this insufficient axe sharpening while working with clients.

Many companies have invested in “transformation,” all claiming to use OKR, of course. But instead of using these investments as a way to become more outcome-driven, most organizations focus on meeting due dates rather than outcomes.

Often the goal is simply to do something like “move to the cloud by the end of the year.” It doesn’t matter if this project made a difference or not, only that it was completed on time.

Many transformation initiatives implicitly assume all projects will be successful. Instead of doing discovery and quickly testing ideas, they rely on projects that don’t deliver value for 12–18 months and rarely measure their outcomes.

Look closer and you’ll see these companies are using “Agile” techniques to deliver waterfall projects—there’s nothing close to continuous delivery of value.

This whole situation is a classic case of the know-it-all mindset, where we believe we have all the answers. The hidden assumption is, “There’s no need for measuring or experimenting, we know what we’re doing.” There’s not much transformation there.

This issue isn’t limited to traditional corporations. Many younger tech-powered companies do similar things.

We have to remember that most organizations are not ready for outcomes. If you want to benefit from being outcome driven, you must change your organization at a fundamental level—superficial adjustments won’t do.

You can make progress in gradual steps, but you have to take those steps.

The hidden reasons why people fail to sharpen the axe

Transforming is hard. Sometimes leaders resist it or don’t know what to do.

But there are also four hidden reasons why people fail to sharpen the axe:

• Operating on autopilot: People often go through the motions instead of being intentional about what they want to achieve and how they work.

• Fixed work mindset: Many people see their organization as something fixed that can’t be changed instead of a product that can be designed and improved.

• Rework phobia: Sometimes people resist sharpening their axes because they hate rework (i.e. making changes to something they’ve already worked on), even when they know it’s good for them.

• Lack of perceived agency: Some people feel like they're just a cog in the machine and believe there’s nothing they can do.

Let’s discuss each of these in more detail.

People often operate on autopilot

Most people are not intentional about how they work. We all have a tendency to operate on autopilot, doing what we’ve always done.

When we do that, we go through the motions without questioning what we want to achieve or how we work.

People often overlook a basic question: What problem are we trying to solve?

This question is so cliché that it’s listed in books about how to “look smart” at work. And yet, we skip it when we operate on autopilot.

One consequence of not asking that question is that people often don't know why a process or metric exists.

As Amazon’s founder Jeff Bezos points out:

It’s very common, especially in large companies, that they’re managing to metrics that they don’t really understand. They don’t really know why they exist, and the world may have shifted a little and the metrics are no longer as relevant as they were when somebody invented the metric 10 years earlier.

Bezos again:

You have to be on alert for that. You have to know, “Okay, I don’t really care about this metric. I care about customer happiness and this metric is only worth putting energy into and following and improving if it actually affects customer happiness.”

It’s extremely easy to lose sight of the difference we want to make. We go through the motions without questioning why a metric or process exists.

The solution is to start by clearly defining our intended outcome, why it’s important, and the constraints for achieving it.

Metrics are a critical “product feature” of your organization, but people don’t discuss them enough when setting OKRs. They may discuss the numbers, but they don’t discuss the metrics.

There’s a lot of “last month this metric was 10, now it’s 12,” but not enough “is this the right metric?”

There's often little discussion about current processes or practices, even when they are clearly broken. 

Let’s look at an example that can feel very tactical but has a huge impact: meetings.

What if you managed meetings as a product?

Research shows that executives spend an average of nearly 23 hours a week in meetings, and yet everybody hates them.

As product development thinker John Cutler points out, if meetings were a product, no one would buy or renew. They have no product-market fit—people show up, get no value, and complain. I doubt you could find a product with worse customer satisfaction scores.

What if you intentionally designed and experimented with your meetings?

Companies like Dropbox and Asana found that each employee could save 3 to 11 hours a month by canceling or redesigning low-value meetings.

Companies like Amazon and Stripe are known for having reimagined meetings. All meetings start with attendees reading a document, which is both faster and allows for deeper debate than watching someone present slides.

What if you took this idea beyond meetings and intentionally designed other organizational features?

Most people see organizations and teams as something fixed

Outcome-driven leaders see organizations like products they can design, modify, and improve, but that is radically different than how most people think.

Psychologist Carol Dweck popularized the idea that some people have a fixed mindset and see their abilities as fixed traits they can’t change. Dweck’s research is about individuals, but I’ve noticed people often apply a similar mindset when thinking about work.

People with a “fixed work mindset” see the way their organization operates as something that is mostly carved in stone and can’t be changed. Many individual contributors see their teams in a similar way.

For example, when I talk to leaders from large or mid-sized companies, many complain that they can’t use OKR or focus on outcomes because they have too many dependencies between teams.

The traditional solution is to “manage” those dependencies—spend a ton of time coordinating work among multiple teams.

This approach not only slows everything to a crawl, but also makes it very hard for teams to take ownership over an outcome, as everything depends on everyone else.

And yet, executives with a fixed work mindset believe there’s nothing they can do.

The folks at Amazon had a different mindset. Faced with the same problem, they realized there was no law saying every project had to involve so many separate teams.

Around 2002, Jeff Bezos and the other executives grew tired of managing dependencies and decided to eliminate them instead.

Amazon famously invested in drastically reducing dependencies by making major changes in how it built software and adopting a new software architecture, embracing APIs1.

The company also reduced dependencies by changing the team topology—the way organizations split work among different teams, including their structure and scope.

The goal was to create what Amazon calls separable teams, teams that need minimal coordination with others and have a high degree of autonomy and ownership over their work.

The fixed work mindset affects executives and individual contributors alike

The fixed work mindset is an equal opportunity condition, and it doesn’t discriminate—it affects executives and individual contributors alike.

Of course, there’s a limit on what teams and individual contributors can change in an organization. But people with a fixed mindset see the way their teams operate as something carved in stone—even things they could actually change.

The table below shares a few common examples of things people say when they see the organization as something fixed.

Pause for a second and ask yourself: have you ever said or thought similar things?

Some people hate rework, even when it’s good for them

Sometimes people resist sharpening their axes because they hate making changes to something they’ve already worked on—even when they know it’ll be good for them.

People who have worked on projects for a long time tend to develop rework phobia.

Rework phobia (noun):

• Irrational fear or hatred of making changes to something you’ve already worked on.

• The mistaken belief that all rework is bad and must be avoided at all costs.

People with rework phobia often say things like, “We can’t change our OKRs now, we’ve spent so much time on them!”

They also say, “We’ve worked hard to define our strategy, it’s frustrating to learn it’s wrong. If we change it now, people will think we did a bad job.”

Another common one is, “We can’t set quarterly OKRs because we won’t ship anything in the next nine months. But we can’t change our projects now because we’ve spent so much time planning them.” (I’ve decided to mention this issue twice in this article because it is so widespread.)

In the project world, rework is always bad because it means someone made a mistake and you have to do the work again. You may even be blamed for something that wasn’t your fault.

The same happens in manufacturing, where rework is the process of correcting defective work items. Projects and manufactured goods are supposed to be one-time endeavors: do things once and you’re done.

But products are never “done,” they continue to evolve. Working on a new version of something is natural in the product world.

People at Netflix don’t say, “We’ve spent so much time on the recommendation feature, we can’t change it now!” They keep iterating the feature.

The outcome-driven mindset involves understanding that you can’t know everything in advance, but you can learn. Rework doesn’t always imply a mistake—it can happen because you’ve learned something new.

As software development guru Kent Beck points out:

The only way it’s all going to go according to plan is if you don’t learn anything.

There’s good rework and bad rework

Outcome-driven leaders understand the difference between good rework and bad rework.

Good rework is intentional and involves continuous learning and improvement. For example, good rework happens when we learn new things, enhance our products, adapt to changes, or use iterative development to improve and refine our product at each cycle.

Bad rework is unintentional and comes from poor practices. For example, bad rework happens when we don’t align on a clear outcome, change priorities often, have to fix the same issues repeatedly, or don’t do discovery and end up building things nobody wants.

I’m not saying you should spend all your time rewriting your OKRs or redefining your strategy. You need to balance optimizing your organization with achieving outcomes.

If you spend all your time “sharpening your axe” without “chopping any wood,” you’re doing it wrong.

You have more agency than you think

Sometimes people feel they are just a cog in the machine, and there’s nothing they can do. I’ve felt that way, too.

But I want to close this article with a reminder that you have more agency than you think—even as an individual contributor in a massive company.

I remember an excellent story told by Teresa Torres. It goes something like this:

A team complained to Teresa that they couldn’t do proper product discovery because their company didn't allow teams to talk directly to customers. They were prohibited from interviewing end customers and believed there was nothing they could do.

Teresa asked the team, is there any rule against interviewing your competitor’s customers?

You can learn a lot by talking to people who aren’t your customers. You can learn about their needs, desires, and pain points with the product they are currently using.

Ideally, you should interview your own customers, too, but don’t let that stop you from learning.

You have more agency than you think.

Let’s put this into practice

We’ll be back soon with another post. In the meantime, the best way to put this article into practice is by discussing its main takeaways with your colleagues or friends.

Here are a few questions to help:

• What would your work look like if you treated your organization or team as a product?

• Challenge some things you do—or don’t do—by asking, “Will it help achieve our desired outcomes?” After asking the question, what would you change?

• Are you spending enough time sharpening your axe?

• Are you using OKR to evolve how you work or to keep things the same?

• What organizational "features" are past their expiration date?

• In what ways might you be unintentionally operating with a fixed work mindset?

• Where are you resisting good rework? Are you falling prey to rework phobia?

Feel free to share your thoughts in the comments or email me.

Below, you'll find a reading list with the links mentioned in this article.

Special thanks to Marty Cagan for reviewing drafts of this article, and to Carlos Accioly and Melissa Suzuno for helping me edit and develop it.

Cheers,

Felipe

Reading list and links:

• Big Think: Walter Isaacson on Steve Jobs’ Favorite Product: The Apple Team.

• Lenny’s Podcast: Zigging vs. zagging: How HubSpot built a $30B company | Dharmesh Shah (co-founder/CTO).

• Dharmesh Shah: Culture is a product you build for your people.

• John Gruber: Resigned.

• Ben Hunt-Davis: Will it make the boat go faster?

• Benedict Evans: Office, messaging and verbs.

• McKinsey: 70% of transformations fail.

• Lex Fridman Podcast: Jeff Bezos: Amazon and Blue Origin

• Harvard Business Review: Meeting Overload Is a Fixable Problem.

• Carol Dweck: A Summary of Growth and Fixed Mindsets.

• Teresa Torres’ website.

If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already.

Subscribe now

Welcome to the second article in the series about building outcome-driven organizations and getting results from OKR.

If you haven’t read the first article yet, please go back and read that first.

This post is also available in Portuguese for my friends in Brazil.

Subscribe now

Imagine you could learn leadership from the man who coached the founders of Apple (Steve Jobs), Amazon (Jeff Bezos), and Google (Larry Page and Sergey Brin). It turns out you can—at least indirectly.

Bill Campbell, “the Coach of Silicon Valley,” passed away in 2016 but left an amazing story that illustrates the essence of outcome-driven leadership. From the book Trillion Dollar Coach (emphasis mine):

[Bill Campbell] liked to tell a story about when he was [CEO] at Intuit and they started getting into banking products. They hired some product managers with banking experience. One day, Bill was at a meeting with one of those product managers, who presented the engineers with a list of features he wanted them to build.

Bill told the poor product manager, if you ever tell an engineer at Intuit which features you want, I’m going to throw you out on the street.

You tell them what problem the consumer has. You give them context on who the consumer is. Then let them figure out the features. They will provide you with a far better solution than you’ll ever get by telling them what to build.

This does not mean you let engineers run off, unfettered, doing whatever they please. To the contrary, product teams need to partner with [teams like sales, marketing, and finance] from the outset, integrated into a cross-functional group that pushes forward with new ideas that solve problems and hatch opportunities.

Tell people what to achieve, not what to do

At its core, building an outcome-driven organization is about leadership. Team attitudes typically reflect their leadership, so nothing will change unless leaders commit to unlearning and adopting a different way to lead.

I love Bill Campbell's story because it’s a crisp summary of that different way to lead: outcome-driven leadership.

The story is about product teams in a tech-powered company, but its lessons apply to other roles as well. If you replace “features” with “projects” and “what to build” with “what to do,” you’ll see that any leader can learn from this story.

Outcome-driven leaders tell people what to achieve instead of telling them what to do.

The product manager in the story wanted to give teams a list of features to build, but Bill Campbell told him to explain what he wanted to achieve instead:

You tell them what problem the consumer has. You give them context on who the consumer is. Then let them figure out the features.

Campbell also highlighted why that's important:

Teams will provide you with a far better solution than you’ll ever get by telling them what to build.

Throughout history, different groups dealing with uncertainty reached the same conclusion, albeit with different names. Author Stephen Bungay calls it “leading through intent." The modern military calls it “mission command,” while the 19th-century Prussian army referred to it as auftragstaktik, or mission-type tactics, where the emphasis is on the outcome of a mission rather than the specific means of achieving it.

In outcome-driven leadership, we begin by clearly defining the outcome we want to achieve, why it's important, and the constraints and guardrails we have for achieving it.

In real life, there are always constraints on what we can do. For example, you may have to achieve the outcome by the end of the quarter or within a certain budget.

Leaders must work together with teams and stakeholders from different areas to clearly define these constraints and set the necessary guardrails.

Bill Campbell believed the path to success is “forming high-performing teams and giving them the resources and freedom to do great things.” But he made it clear leaders had to set boundaries:

This does not mean you let engineers run off, unfettered, doing whatever they please. To the contrary, product teams need to partner with [teams like sales, marketing, and finance] from the outset […]

Telling people what to achieve is a crucial starting point, but leaders must also strike the right balance in managing teams to achieve those outcomes.

The Goldilocks principle

One of my recurring themes is that people tend to view things in black and white, seeing them as either entirely good or entirely bad. But the solution is not to go to the extremes. The solution is to find the right balance.

This idea is called the Goldilocks principle, named after the story in which a young girl—Goldilocks—tastes three different bowls of porridge and finds she prefers the one that is "just right," neither too hot nor too cold.

Like Goldilocks, high-performance teams require that management interventions be “just right." As Bill Campbell explained, leaders shouldn't tell teams which features to build, but they shouldn't let the teams do whatever they please, either.

But many people believe that adopting OKR or the product model means leaders should be completely hands-off. Providing any direction or guidance would be seen as committing an unforgivable offense: micromanagement.

However, micromanagement isn't the right word. It implies that focusing on details—the micro stuff—is always wrong. But if leaders want to build a culture that values quality and the customer experience, they have to pay attention to details.

This concept is embedded in one of Amazon’s leadership principles, Dive Deep (emphasis mine):

Dive Deep

Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdotes differ. No task is beneath them.

No one was more obsessed with details than Steve Jobs. Tony Fadell, who led the development of the iPod and the iPhone, describes it in his book Build:

Examining the product in great detail and caring deeply about the quality of what your team is producing is not micromanagement. That’s exactly what you should be doing. I remember Steve Jobs bringing out a jeweler’s loupe and looking at individual pixels on a screen to make sure the user interface graphics were properly drawn. He showed the same level of attention to every piece of hardware, every word on the packaging. That’s how we learned the level of detail that was expected at Apple. And that’s what we started to expect of ourselves.

I’m not saying every leader should do what Jobs did, but managing the micro stuff and paying extreme attention to detail isn’t always wrong.

Instead of micromanagement, it's useful to think in terms of overmanagement and undermanagement. In overmanagement, there's too much management intervention or managers intervene in the wrong places. In undermanagement, managers don't intervene enough.

The table below summarizes some of the symptoms of undermanagement and overmanagement.

The Goldilocks of management

Leaders are responsible for creating the conditions in which teams can perform at their best.

That means they need to strive for the Goldilocks of management—finding the right balance of management for each context, not too much, not too little.

Tony Fadell emphasized the importance of finding that balance:

One of the hardest parts of management is letting go. Not doing the work yourself. You have to temper your fear that becoming more hands-off will cause the product to suffer or the project to fail. You have to trust your team—give them breathing room to be creative and opportunities to shine.

But you can’t overdo it—you can’t create so much space that you lose track of what’s going on or are surprised by what the product becomes. You can’t let it slide into mediocrity because you’re worried about seeming overbearing. Even if your hands aren’t on the product, they should still be on the wheel.

Fadell again:

As a manager, you should be focused on making sure the team is producing the best possible product. The outcome is your business. How the team reaches that outcome is the team’s business.

This doesn’t mean the manager always chooses the outcome with no input from the team. It means that the manager is ultimately responsible for the team’s performance and for the achievement of the outcome.

The pitfalls of overmanagement and undermanagement

Another principle of outcome-driven leadership is don’t leave talent on the table. Don’t waste the talent of all the smart, hard-working people in your organization.

When we go to the extremes of overmanagement or undermanagement, we leave talent on the table.

Talking to different teams can make this discussion more concrete. Let’s use an excellent example by Henrik Kniberg, which I adapted.

Imagine asking the same question to three teams: What are you working on and why?

We ask the first team, and they tell us they're implementing the self-service app requirements because stakeholders requested it. They say, “Our goal is to deliver this project by June 15th.”

Leaders treated the team as order takers, telling them which features they wanted. This attitude is typical of know-it-all executives and is precisely what made Bill Campbell want to throw the product manager out on the street.

When leaders treat teams as order takers, they block employees' talent and kill innovation. As Kent Beck points out:

If you treat people like chess pieces, don’t be surprised if they show the initiative and creativity of chess pieces.

Undermanagement also leaves talent on the table

Most people don't realize it, but companies also leave talent on the table when they undermanage teams. Let's talk to the second team to understand why.

The second team says they're working on a Bitcoin app because they think it's a good idea. “We want to launch it by the end of the year,” they say.

The problem here is that the team made a decision without considering their customers’ or business’s needs, and without strong evidence to back it up. The leaders took a completely hands-off approach, ignoring Bill Campbell's warning and letting the team do whatever they pleased.

However, when leaders undermanage, they leave the team’s talent on the table. Teams need guidance, coaching, and support to perform at their best. You don’t get high-performance teams for free—you have to put in the effort.

High-performance athletes and entertainers always have coaches and managers guiding and supporting them. High-performance teams are no different. Let’s talk to the third team to see an example.

The third team says they are testing ideas for the self-service app to reduce the contact rate (the number of times customers contact a company for help within a given period). They explain this is important to improve the customer experience and reduce costs.

This team:

• Is focused on making a difference, not simply meeting due dates.

• Clearly explained the outcome they wanted to achieve and why it’s important. 

• Understands customer and business needs.

• Understands the core metrics associated with their work.

• Understands how their work contributes to the organization's success.

This was possible because leaders guided and coached the team, helping them develop the muscles and mindsets necessary to perform at their best.

Don’t take alignment for granted

Another issue with letting teams go unfettered is that alignment doesn’t happen magically. Without guidance, each team will move in different directions, and their talents will go to waste. Without top-down guidance there’s no alignment.

Amazon’s senior leaders took special care years ago when transitioning to autonomous teams—teams designed to operate with little or no coordination with others. As former executives Colin Bryar and Bill Carr wrote in Working Backwards:

Autonomous teams are built for speed. When they are aligned toward a common destination, they can go a long way in a short time. But when they are poorly aligned, the team can veer far off course just as quickly. So they need to be pointed in the right direction and have the tools to quickly course-correct when warranted.

To ensure alignment, each new autonomous team had to meet with CEO Jeff Bezos and the senior executive leading the team. They discussed the team’s composition, purpose, and the metrics used to measure progress.

It's impossible for each new team to have meetings with the CEO nowadays, given Amazon’s scale. But executives and middle managers can adopt a similar approach for alignment.

Most companies already suffer from lack of alignment. Do you think that letting people do whatever they want will improve the situation?

Finding the right balance of management for each context

Overmanagement and undermanagement are relative concepts. What's "just right" for one situation may be too much or too little for another.

Management isn't one-size-fits-all, and we need to find the right balance for each context. In some cases, teams may need more specific guidance and closer monitoring.

For example, Bill Campbell's Intuit1 makes a product for American income tax returns (TurboTax), so they must comply with regulations, which may include mandatory features.

Not telling the teams about the required features would be a severe case of undermanagement. But giving them a fixed specification for how to build the features could be overmanagement.

Strong leaders aim for the right balance. They help product teams collaborate with legal to understand how to comply with regulations while providing a good customer experience. But if the IRS requires the user's mother's maiden name, they ensure teams collect it.

The product also has a clear due date: everything needs to be ready well before Tax Day (April 15th, when Americans submit their income tax returns). This is a great reminder that all organizations use both the outcomes approach and the due dates approach to manage work. There are always cases where we need to commit to dates due to regulations, contracts, or events like Tax Day.

The difference is that those due dates and mandatory features aren't arbitrary. They're not just something a know-it-all executive believes is important based on very little evidence.

We also can’t leave the leaders’ talent on the table

Companies that adopt a completely bottom-up approach are also leaving their leaders’ talent on the table. When direct reports fail to work together with their managers or request help, they do the same.

There are many bad managers out there, but that doesn’t mean everyone works for Dilbert’s pointy-haired boss. There are many talented, experienced leaders, and we can’t waste their talent.

Teams are closer to the problem and know local, specific details, while leaders understand the big picture and have more seniority. The real power comes from collaboration between them.

As Marty Cagan points out in Empowered, high-performance teams don’t need less management. They need better management. They need managers who can help teams perform at their best.

That means leaders also have to develop the necessary muscles and mindsets so they can properly coach, support, and align the teams.

Middle managers are key

We've been talking a lot about leaders, but everything we've discussed applies to anyone who is a people manager, anyone who oversees a team of employees.

Middle managers are crucial to keep organizations working, as the Google founders learned in 2001.

That year, Larry Page and Sergey Brin decided that 130 engineers would report directly to VP Wayne Rosing. Managers were no longer necessary, as engineers would “self-organize.”

Bill Campbell, who was coaching the founders, wasn’t happy with the idea, so he and Page decided to ask the engineers. One after another, the engineers said they wanted to have a manager. They wanted somebody to learn from and needed someone to help when discussions with colleagues reached an impasse.

Page continued with the plan anyway, but the "self-organizing” idea didn’t go as expected. Some engineers liked not being overmanaged by bad bosses, but many hated the consequences of being severely undermanaged.

As Douglas Edwards, Google employee number 59, wrote in I’m Feeling Lucky (emphasis mine):

It was an engineer’s dream come true or a bit of a nightmare, depending on whom you asked. No clueless pointy-haired boss could get in the way and screw things up, but there were no clear signals from above about what was important and what was urgent and what was both. Groups struggled for resources and fought redundancy. Some engineers wanted more feedback on what they were doing and how well they were doing it, and others wondered about opportunities for advancement.

In the end, it was a short-lived experiment. Google quickly realized the problems caused by undermanagement and reinstated the managers within six weeks2.

We'll be back soon

We'll be back soon with another article in our series on building outcome-driven organizations and getting results from OKR.

In the meantime, I’d love to hear from you. Feel free to leave your comments below or email me.

Special thanks to Itamar Gilad for reviewing drafts of this article, and to Carlos Accioly and Melissa Suzuno for helping me edit and develop it.

If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already.

This post is also available in Portuguese.

Subscribe now

You’ve probably already noticed—OKR is not a silver bullet. 

It feels like everyone is using OKR. Unfortunately, most companies that tried to use OKR are disappointed with the results. 

However, while OKR usually doesn’t live up to (often unrealistic) expectations, the underlying issues that create the demand for it are real. 

Over the past ten years, I’ve talked to hundreds of companies about which problems they wanted to solve with OKR. The same 12 challenges appeared over and over, regardless of whether the organization used OKR or not.

I’d bet that you can relate to some of them:

1. Competitors are innovating faster than you are. 

2. Employees don’t understand how their work contributes to the strategy.

3. People are not moving in the same direction. Teams often set conflicting priorities.

4. The organization has too many priorities and is spreading itself too thin.

5. The CFO is frustrated with the meager returns from technology investments.

6. A large portion of the budget is allocated to projects, but the organization can’t measure the outcomes of these projects.

7. Many OKRs (or goals) within the organization are project-based, such as “Launch the new website,” “Deploy the MVP,” or “Migrate 100% of the servers to the cloud.”

8. The organization often evaluates employees based on their ability to meet due dates. It doesn’t matter if they’ve helped the company or not.

9. The company has many dashboards, but people often don’t use data to guide day-to-day decisions or provide insights.

10. Employees are asking for more autonomy and a clear purpose.

11. Employees resist setting ambitious OKRs (or goals), admitting mistakes, or asking questions. 

12. People don’t take ownership of their OKRs (or goals). People see them as a formality that doesn’t guide their day-to-day work.

If these challenges hit too close to home, don’t feel bad about it. It’s not your fault. 

But you must do something about it. 

OKR is a tool, not a silver bullet

Given all the disappointment with OKR, some people are looking for better alternatives. 

But whether you choose to use OKR or any other technique, you have to understand that they are not silver bullets. They are just tools, and the results you get from any tool depend on how you use it. 

As Benedict Evans points out, humans have a clear tendency when they get new tools:

There’s an old saying that when we get a new tool, we begin by making it fit the old way of working, and then we change the way we work to fit the new tool. 

99% of people make OKR fit their old way of working. Like that popular definition of insanity, they keep doing the same thing over and over while expecting different results.

It’s no wonder so many are disappointed. And they will probably be disappointed by the next tool, too.

Trying to address those 12 challenges with OKR alone is like trying to heal a broken leg with an ice pack. 

While OKR may help ease some symptoms if properly used—talk about a huge “if”—it is not enough to address the structural, deeper causes.

If you’ve completely lost faith in OKR, you may choose to use something else instead. But you must understand that replacing OKR with another tool is like buying a different ice pack. Alone, it won’t change much.

You have to address the deeper causes

This situation is similar to an experience I had with a physical therapist recently. She told me I had to unlearn the way I walked. 

I had been dealing with severe back pain for years. Sometimes, the right side of my back would seize up, and I would be unable to move. That was not fun at all.

The leading cause was that the muscles on my left side were too weak, while the ones on the right side were too strong. This made me lean to the right while walking, standing, or sitting, creating a lot of pain.

You are also dealing with weak muscles

You and your organization are also dealing with weak muscles, starting with your “outcome muscles.” But what does that mean?

All organizations use two approaches to manage work, often without realizing it. 

First, there’s the due dates approach, where the goal is to meet deadlines. If you work in a traditional company, you may know it by a different name: the PMO (project management office) approach.

Some people call this the output approach, but that can be a confusing term (see callout at the end of the article).

When we use the due dates approach, it doesn’t matter if our project made a difference or not. Our objective is simply to complete projects on time, on budget, and on scope. 

Here, dates tell us if we’re successful. 

The second approach is the outcomes approach, where the goal is to make a difference. As Marty Cagan once told me:

We all know that we do things and that some of those things make a difference while others do not. The outcomes approach is about focusing on the difference we are trying to make and not losing sight of it.

When we use the outcomes approach, our job doesn’t end when we complete projects. We have to test different options until we achieve the outcome. Delivering projects is important, but simply meeting deadlines is not the goal. 

Here, data tells us if we’re successful. 

All companies use both approaches to manage work, but your “outcome muscles” are probably too weak, while your “due date muscles” are too strong.

This weakness is making your organization lean heavily on the due dates approach. You are getting a due date overdose.

Companies have many dashboards, but most still manage work based on due dates. We often have something like the image below, where the organization unintentionally manages a large share of its investments using due dates.

More Outcomes, Fewer Dates™ 

There’s a “slogan” that represents the shift to outcomes, facilitating the dialogue about the new culture: More Outcomes, Fewer Dates™.

The core idea behind More Outcomes, Fewer Dates™ is to intentionally increase the “share” of our investments managed with outcomes and data over time.

We are not talking about zero dates but fewer dates.

It’s human nature to want to make everything binary: something is either completely good or completely bad. This desire to oversimplify things creates several misconceptions that we have to address.

Let’s start with the first one: the idea that you should have zero due dates. 

Let me be clear: all organizations use both approaches to manage work. Unless you are a government agency in North Korea, you can’t survive by managing 100% of the work using due dates.

No organization manages 100% of its investments based on outcomes alone, either. There are always cases where we need to commit to dates, whether due to regulations, contracts, or events like Black Friday. 

The solution is not to go to the extremes. The solution is to find the right balance. That doesn’t mean a precise 50/50 split, it means you have to choose the right approach for each context.

More Outcomes, Fewer Dates™ is about deliberately selecting the best approach for each situation. And to make it happen, we have to develop new muscles but also new mindsets.

Your weak muscles are not the only thing causing the due date overdose

There is an even another structural, deeper cause to your challenges: the know-it-all mindset, where we believe we have all the answers and have everything figured out.

The hallmarks of the know-it-all mindset are the phrases “This will obviously work, there’s no need for measuring,” “We know what we are doing,” and “We’ve always done it this way.”

When you catch yourself using phrases like those, it’s a sign that you’ve drifted into know-it-all territory. We all act as know-it-alls from time to time—more often than we realize. 

When we fall into the know-it-all mindset, we implicitly assume our projects will be successful, as long as they’re on time and on budget. Delivering projects becomes synonymous with generating results, and we rely even more on due dates. 

The know-it-all mindset is not only in people’s heads. It’s also deeply embedded in most organizations’ cultures and processes. You could say that we are dealing with structural know-it-all-ism, but I’m not even sure how to spell that.

Think about it: how many of your organization’s incentives reinforce the know-it-all mindset? How many processes assume that delivering projects means generating results? How often do you measure whether each project actually achieved the desired outcomes? 

The due date overdose is creating a lot of pain 

The overuse of due dates contributes to many of the 12 challenges we’ve seen in the beginning of the article. 

Companies with weak outcome muscles struggle to measure the outcomes of their investments. That means they don’t know what’s working or not, leading to meager returns. 

Paraphrasing John Wanamaker, half the money I spend on projects is wasted. The trouble is, I don’t know which half. And that may be an understatement, as some analysts say the waste is much higher.

Know-it-all executives often treat employees as order-takers who simply deliver projects assigned to them. This mindset drastically reduces their empowerment and kills innovation—critical factors for achieving outcomes. 

The due dates approach often makes employees feel like hamsters, running nonstop on their wheels but never getting anywhere. This robs them of their sense of purpose, hurting their engagement and retention.

And when people can only see projects and due dates, they struggle to understand the strategy or how they contribute to it.

Finally, the overuse of dates also builds the wrong culture: a culture that values shipping projects, not making a difference. Hitting dates is easier than achieving outcomes. 

The best companies understand all the problems caused by the due date overdose and the know-it-all mindset. That’s why they adopt a completely different mindset for leading people, managing work, and developing products.

Today’s most successful companies are outcome driven 

Today’s winning organizations like Amazon and Apple are outcome driven1. 

Being outcome driven means being motivated by the desire to make a difference, not just complete projects. It means intentionally focusing on the outcomes you want to achieve instead of going through the motions.

Outcome-driven companies define success based on outcomes, but they don’t stop there. They also align the whole organization toward achieving these outcomes: all decisions, actions, processes, and practices.

The outcome-driven mindset requires deliberate effort and an environment that supports it

Humans are not naturally wired to be outcome driven. Left to their own devices, our brains tend to fall into the know-it-all mindset, the same way we tend to fall into doom-scrolling on Twitter or Instagram. 

We didn’t evolve to be outcome driven, the same way we didn’t evolve to cope with the world of smartphones and social media. 

Anyone can adopt the outcome-driven mindset, but it requires conscious and deliberate effort.

It’s not just about individual commitment, though. The organization also has to have mechanisms and a culture that supports the outcome-driven mindset. But most companies don’t have that.

Most organizations are not ready for outcomes

The outcome-driven mindset is a fundamentally different way to lead people and manage work. It doesn’t fit most organizations’ existing capabilities, processes, or cultures. It also doesn’t match most individuals’ existing skills and mindsets. 

This leaves us with two options: if you want to say you are outcome driven, you can simply water the concept down to fit your old way of working. 

But if you want to benefit from being outcome driven, you must change your organization’s culture and ways of working at a fundamental level.

It starts by developing those weak muscles we’ve been talking about. 

Leaders and employees need to develop the necessary skills. Training is only part of the solution. You also have to change how people work so they can apply those new skills. As they say, if you don’t use it, you lose it.

The organization also has to develop the necessary capabilities. For example, does the company collect all the data needed to know if its investments are making a difference? 

Developing your weak muscles is not enough, as it wasn’t enough for me. 

Just like I had to unlearn how I walked, you have to unlearn how you work. 

Senior leaders and individual contributors have to unlearn the mindsets, behaviors, and methods that contributed to this situation. 

The organization must also abandon any practice that reinforces old behaviors. If a process, workflow, metric, or incentive reinforces old behaviors, you must scrap it. 

You can make progress in gradual steps

After reading this article, some may feel that building an outcome-driven culture is impossible, while others may think that it’s easy. This is another one of those cases where the answer is not in the extremes, but somewhere in between.  

Building an outcome-driven culture is a journey, but you can make progress in gradual steps. You won’t get there overnight, but it’s possible to make improvements every quarter. 

What to read next

I'm writing more articles about how to build outcome-driven organizations and get results from OKR.

I want this post to act as a “hub” pointing you to what to read next.

Here are the articles I've published so far, grouped in different topics.

Understanding outcomes

There’s a lot of confusion about what outcomes really are. The articles below can help clarify that.

• An OKR should measure the outcome, not the work.

Develop your outcome muscles by learning to separate outcomes from projects and also from project metrics.

• Not everything needs to be an outcome—or an OKR

Put investments in two buckets: OKR + Projects.

• How to use the two bucket technique in practice.

Is your company using OKR only on paper?

• To focus on outcomes, we have to unlearn.

It's time to abandon old mindsets and behaviors.

• Begin with the end in mind.

Define outcomes before projects.

• Build your outcome muscles by asking "why?"

Using the Five Whys technique to shift from projects to outcomes.

Outcome-driven leadership

At its core, being outcome driven is about leadership. Nothing will change unless leaders commit to adopting a different way to lead. The two articles below talk about what that means.

• Are you leaving talent on the table with OKR?

High-performance teams require management that is just right, not too much, not too little.

• Why you should treat your company as a product.

Outcome-driven leaders view organizations as something they can design, test, and improve. Like a product.

I’d love to hear from you 

Do you have any questions or thoughts about this article? Any suggestions for future topics? 

Feel free to leave your comments below or email me. And if you find this article helpful, please share it with others.

Acknowledgment

Special thanks to Marty Cagan, Itamar Gilad, Ian Harvey, and André Carregal for reviewing drafts of this article, and to Carlos Accioly and Melissa Suzuno for helping me edit and develop it.

If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already.

Subscribe now

What exactly does OKR look like in practice at the company that popularized it? I know many readers are curious about OKR at Google, so I’m happy to introduce you to Itamar Gilad,  who, as former Lead Product Manager and Head of Growth at Gmail, helped, among other things,  launch the Tabbed Inbox feature and grow Gmail from 400 million to 1 billion users. As a product management and strategy coach, trainer, and speaker, Itamar has developed a number of tools to help teams make better product decisions. My blog editor Melissa Suzuno recently sat down with Itamar to discuss his experiences with OKR at Google.

Tell us a little about yourself.

Itamar: I was trained as a software engineer and worked as a software developer and engineering lead/manager for five years. Then I realized that managing developers wasn't my thing and switched to product management, which was probably a better fit, because I kept doing it for the next 15 years in various companies including Google and Microsoft. At Google I was a product lead and Head of Growth for Gmail. Since I left Google three years ago I’ve been working as product management and strategy coach, writer, and speaker.

What was the OKR process like for Gmail when you were there?

Itamar: Google uses multi-level OKRs: Company, Product Area (which is similar to division—Android, Chrome, and Geo are examples of Product Areas), and Product (such as Gmail, Maps, and Chrome). Then inside the products there may be other sub-levels, but at a minimum each product team (typically 3–15 people) should have its own OKRs. At the time I was at Google some people used personal OKRs and some didn't.

You would expect that with this many levels the process would be complicated and time-consuming with long rounds of reviews, but actually it isn’t. Different product areas and products may use different approaches. Google generally trusts employees and teams to do the right thing and rarely enforces one process across the board. 

Google generally trusts employees and teams to do the right thing and rarely enforces one process across the board. 

At Gmail typically during the OKR season, you would get a draft of the overall Gmail OKR for the next quarter from your managers. Some of the things in it would be derived from higher levels and some were Gmail specific. You would then discuss with your peers what OKRs were applicable to your area of responsibility and copy those parts (Objectives, Key Results, or both) into your OKR doc, but you could and should also create your own OKRs. Some of your key results might propagate up to the product OKR, product area OKR, or even the company OKRs.

For example, as Head of Growth, I would project the Monthly and Weekly active users of Gmail by the end of quarter, and those numbers often appeared in Google’s OKRs. A lot of the discussion and negotiation was done over email. In a typical OKR cycle we would spend a few hours (all together) at team level and a few days higher up the hierarchy.

We also used shared OKRs to coordinate teams, groups, and products around a shared goal. It’s a very powerful tool when used right.

Can you give us an example of what that looked like in practice?

Itamar: When I joined Gmail, we were talking about driving up engagement of casual users, people that use email for personal purposes, with the product. At the time, Facebook was getting a lot of engagement and I guess that focused our attention on this key metric. They’re very different products and in hindsight, it probably wasn’t the right basis of comparison.

The Objective was easy—we wanted to raise the level of engagement of casual users. But when it came to the Key Results, it wasn’t that simple. Should it be about reading more messages? That wasn’t necessarily a good Key Result because reading more messages might be a result of getting more promotional email and social notifications. The users may be engaged, but for the wrong reasons.

Another metric we considered was messages sent. However, people don’t necessarily need to send that many personal emails these days. They have chat and social media, so the number of emails sent doesn’t necessarily mean that email isn’t engaging.

So we realized that maybe we were asking the wrong question. We conducted research— interviewed people and did quantitative analysis and realized that people had a lot of promotional and notification emails that cluttered up their inboxes, and made it hard for them to find the messages they really cared to read.  

We realized the main goal we should set was not driving engagement, but driving engagement with the right type of email — enabling people to read just the emails that they really cared about and interact with the other ones in a different way. 

We realized the main goal we should set was not driving engagement, but driving engagement with the right type of email.

So we set up an OKR around that. Something along these lines: Casual users have their most important mail front-and-center

• Achieve a % of “Primary” messages read > X%

• Achieve a false positive rate < Y%

• Achieve a false negative rate < Z%

False positives are messages we thought would be important, but turned out not to be so. False negatives are messages that we thought were not important, but it turned out they were.

That led to a big project that ended up launching the Tabbed Inbox, which puts your email into Primary, Social, Promotions, and other tabs. Initially it was a feature we planned to launch just on desktop. As we started testing, we realized the problem was even bigger in mobile. We concluded this needed to be a shared OKR with the Android and iOS Gmail teams.

At the time, Gmail Android was part of the Android product area, a completely different division in Google that had its own set of objectives, so I reached out to them. I presented the problem and asked if we could share the OKR of relieving the pain of those casual email users, and luckily they agreed.

When I teach OKRs, I say the good thing about shared OKRs is that sometimes you get a “no” and then you know that’s something you shouldn’t focus on, at least this quarter. But in this particular case, they said yes, and we got to co-launch the new inbox across Gmail clients. We touched hundreds of millions of people with this very big and visual change that was very well received, thanks to the power of shared OKRs.

How would you describe alignment at Google, including cross-team alignment?

Itamar: Of all the companies I’ve worked with or at, Google is the one where the people are the most “in the know.” People understand what the company is trying to achieve and that helps with cross-team communication, up and down communication, and that’s partly because Google management spends a lot of effort sharing both the goals and the motivation. That doesn’t mean that we always agree—there’s often discussion, which is very important as well—but you can talk to anyone and they will probably know why their product has certain goals set.

I’d also say the process creates a lot of cross-alignment. For example if your product is busy with improving performance in emerging markets, there’s a good chance that peer products have inherited the same goal, and that makes it easier to collaborate (which is important because there are a lot of integrations between Google products and systems). If you’re all pulling in completely different directions, the discussion becomes more difficult.

How does all this information about OKRs get communicated?

Itamar: There were quarterly all hands meetings. The company-level OKR reviews were streamed live and recorded. The CEO and senior vice presidents go through the previous quarter’s OKRs and how we did and then outline the OKRs for the next quarter. There’s extreme transparency.

On a product level, such as for Gmail, we’d have a product-specific all hands to discuss our OKRs. On a team level, we’d also have meetings to review OKRs, so there’s a lot of communication. Once you create your OKRs, they’re all transparent, so anyone can open anyone else’s OKRs and there’s never any secrecy about them. It’s very easy to understand what people are working on.

In your view, how could Google improve the way it uses OKR?

Itamar: Google started using OKR at a time where output OKRs (OKRs that specify activities rather than outcomes) were still the norm. For this reason you could encounter output OKRs at Google during my time there, though I know things have improved since.

Output OKRs are something I encounter a lot in nearly all companies. Most people are conscious that specifying “Launch X” is not a good key result and try to avoid it, but there are many ways to disguise output OKRs as outcome OKRs—I should know, I did it, too.

The classic scenario is you fall in love with an idea, you build a project around it, and the OKR is a bit of an afterthought. We already convinced ourselves that this is the right idea, but now we need an OKR. If it’s very hard for you to write OKRs, it could be because you went one step too far and you already decided on the activities. 

If it’s very hard for you to write OKRs, it could be because you went one step too far and you already decided on the activities.

There are subtle ways people work around this issue. For example a key result like “In the next quarter we expect 45% of our users to use the new onboarding flow.” It sounds great—it’s an outcome, it’s measurable—but who actually said that this new onboarding flow is a good thing?

This OKR is actually disguising the fact that our mission is to launch the new onboarding flow. So that’s not a good outcome. A good outcome would be based on what the new onboarding flow would provide to users—would it shorten the onboarding time? Would it increase the success rate of onboarding? Any other benefit? This kind of OKR is okay only if you’ve already tested it very thoroughly and have very strong evidence that the new onboarding flow is actually helping these other key metrics.

Google also relies a lot on big themes to drive the company strategy. For example, in the past, Mobile-first/Mobile-only was about building features and capabilities for people that were mostly or only using the product on mobile. Today that seems like a no-brainer, but in the early 2010s, this was a good theme to focus on.

The themes are often reflected in the OKRs as goals. The risk there is that sometimes people build things just because they align with the theme, even if they don’t really help the users or business.

An example would be a predominantly desktop product that freezes desktop product development in order to focus on mobile-first/mobile-only users, even though there’s no evidence that this market segment is about to become important enough to justify such a big investment.

There’s an assumption that alignment with the theme is sufficient evidence, but in my view that’s rarely the case. There are many products that are built based on themes (think blockchain, chatbots, VR…) and have no merit. The right approach (and I assume the one Google believes in) is that you should let the theme direct you, but you should only set goals that make sense to your product and market.

Even when people create good, outcome-based OKRs, they often struggle with deciding what to do next, which activities to work on. And they tend to make decisions without data, based only on someone's opinion—usually the boss’s. What should teams do after creating OKRs?

Itamar: The key problem is that, in tech, as well as in many other industries, reality is increasingly uncertain, complex, and fast changing. Markets are evolving quickly, competitors are coming in and out, technologies are changing. We never really know whether our software can do what we want it to do, how many bugs there will be—there’s a lot of uncertainty.

I see a lot of companies not dealing with this reality very well. They rely a lot on top-down planning, decision-by-committee, opinions, weak heuristics, and cognitive biases. This is why I developed the GIST framework to help companies systematically drive their products towards business and market impact. The system has four layers: Goals, Ideas, Steps, and Tasks. Goals include OKRs and metrics. Ideas are about collecting and evaluating many ideas fast using evidence. Steps are mini-projects developing the idea and testing it at the same time (implementing the principles of Lean Startup and Design Thinking), and tasks are the day-to-day activities that implement the steps. You can read more about GIST here. My book on the topic is coming out this autumn.  

The Confidence Meter is a tool that I developed to allow people to evaluate the strength of the evidence in support of their ideas. For example opinions and thematic support (the blue area on the upper right) give us weak evidence and therefore very little confidence. Tests and experiments (dark-red on the upper left) give us strong evidence and much more confidence. The GIST framework guides you to test ideas iteratively in build-measure-learn loops and then re-evaluate them using this tool.  

You can download the tool free (with instructions) here: confidence calculator.

To learn more about Itamar Gilad, visit his website: itamargilad.com and sign up for his newsletter where he shares articles and tools.

Can a 140-year-old organization adopt OKR and become more outcome driven? And can they do it not within their internal “startup incubator,” but on their main product, a billion-dollar business? How do OKR and outcomes thinking fit into a broader transformation journey?

In Silicon Valley, Google and others adopted OKR when they were still early stage startups—OKR was already part of their culture as they scaled. But what happens when a mature, multinational organization adopts OKR?

I had the pleasure of teaming up with Ian Harvey, Senior Portfolio Director at Elsevier, to tell the story of their journey with OKR at the Business Agility Conference in NYC. The talk, which you can watch below, shares the inside view of Elsevier’s journey, including some of the key lessons learned and the difficulties and challenges faced.

Now let me share a bit about the background of our presentation.

Founded in 1880, Elsevier is a $3 billion multinational organization that evolved from a content provider to supporting researchers, governments, and healthcare professionals with digital products.

During that transition, the organization began to adopt modern product management practices, run experiments, and focus on world-class technology delivery, but maintained the commitment to continuous improvement. 

In 2017, a meeting of the organization’s top managers identified engagement and alignment as areas for improvement. The existing approach to connecting strategy to execution and setting goals was hindering this.

A small core team was formed and they identified OKR as the approach to drive alignment and engagement. They reached out to me, and we worked together with the rest of Elsevier to help the company adopt outcome-based planning and OKR.

Two years later, Elsevier has benefited from greater employee engagement and improved NPS and customer retention on critical platforms.

I want to say a very special thanks to Rose L’Huillier, VP of Product Management at Elsevier, who was crucial to making this story happen and was extremely helpful when we were preparing our talk. 

If you ever read any of my content, you know that OKR is about delivering value, and that good OKRs measure outcomes and pass the “So What?” Test. The whole point of using OKR is to agree on the outcomes we want to achieve and then let the teams test different ideas quickly to find which ones will work.

When a team says that they can't measure outcomes in a single quarter, it's usually because they don't know how to run experiments. 

They don't have an OKR problem. They have an experiment problem.

So if you are using OKR correctly, teams won't have a fixed list of deliverables to implement. That is why OKR fails without experiments.  Unless employees learn  how to set up and structure experiments, they will waste a lot of time and money going in the wrong direction.

Thankfully,  David J. Bland teamed up with Alex Osterwalder, the creator of the Business Model Canvas, to tackle this topic in his new book, Testing Business Ideas. My blog editor Melissa Suzuno sat down with David to learn more about the book and David’s advice on experimenting in a business setting.

Tell us a little bit about yourself and how you got started on your journey with experiments.

David: I went to school for design and then I ended up joining a startup right out of college, where I did a little bit of everything—design, front-end development, web development, leading teams, closing deals. This experience was really influential in my career. When you're at a startup, you're trying to search for the business model, the right customers, fit. Now, as a consultant, I try to use everything I learned at startups to handle uncertainty and how you test your way through things. No matter what type of company I'm working with, we focus on identifying the riskiest thing they have and how to test that so they don't find out they're wrong much later and fail slowly.

Can you tell us a little bit about your book and give us a quick overview of what it's about?

David: I was approached by Alex Osterwalder who created the Business Model Canvas and the Value Prop Canvas. He said, “There's this need in the market where people aren't sure what experiments to run and when they should run them.” Our goal was not to build a giant encyclopedia of them, but to help people understand how to choose an experiment and what it should look like. We started there and we essentially ended up with this list of experiments. We have 44 in the book and we applied a taxonomy to them, to help people understand whether an experiment will help them determine the type of risk—if something is desirable, viable, or feasible.

The idea is that someone could say, “I have this kind of risk. What kind of experiments are available to me?” And the book will help them see which experiments they can use and how to run them.

The core of the book is the list of experiments, but then the wrapper around that content addresses questions like: What kind of team do I need? How do I set that up? What kind of ceremonies does this involve? How do I make this a repeatable process?

Why are experiments so crucial to achieving high performance?

David:  Usually when you're starting anything new—if you frame this as discovery versus validation—you’re doing probably a lot of discovery just to understand if there’s a problem there. And then as you learn more, you want to be able to put things in front of people and get feedback on them and then get higher and higher strength of evidence. 

It's not just whether they want it, but it's also will they pay for it? And can you do it? And so over time that never really stops. Even when you have your business and it's running, it's not just running on autopilot. There's always this element of, okay, well if we wanted to add a feature to that, what would that look like? How would we test our way through that before we just throw in more features? 

Once you get going and you find some customers and you have some traction, you don't just stop experimenting. It's not a phase. It's something that you need to continue to do. You’ll want to think about what are the things in your roadmap or strategy that you feel really nervous about. What can you do to learn about those quicker?

In a modern view of OKR, managers should not tell teams what features to build or projects to work on, but instead they should agree on the outcomes that they want to achieve. In your opinion, what role do experiments play in that type of scenario?

David: With outcomes, it's essentially where you are focused in your business model. For example, are you focused on the fit between your value prop and the customer segment? Are you focused on the channels and how you can grow those channels? Are you focused on building the relationships? Are you focused on price testing and what your revenue looks like? Are you focused on backstage where you need resources and activities and how much that's going to cost? All of those are outcome-based in the sense of, if we're trying to hit this price point by delivering our value at this low cost, what's the smallest test we can run to see if that's true.

If this is what we predict will happen, we can run some experiments and see how far off we are. Are we close to hitting that number or hitting the outcome? With regards to business modeling, you're always trying to focus on what are the outcomes and what's the evidence you can use to inform your strategy. You don't want to just give a team a list of experiments to go run. Instead you want to say, we're trying to test this outcome to see if this is possible for us. What are some ways we might go about doing that?

It's nice because it puts some guardrails on it, but it doesn't necessarily dictate to them, here's the 20 experiments you're going to run. It's more of use your creativity and your skill and your team to figure out, okay, well if we were trying to achieve this outcome, what are some different experiments we'd run? And then how would we report out the progress toward the outcome. Then you go back to your stakeholders with your hypotheses. You can explain the experiments you ran, the outcomes you observed, and what you recommend next. It becomes more of a conversation where you're giving an account of how you made progress and not necessarily just being held accountable to running a bunch of experiments.

Felipe Castro: One quick comment. The Business Model Canvas is optional and not all teams use it. It is a very powerful and widely used tool, but you can, of course, use OKR and experiments without it.

What are some of the most common mistakes that people make when testing business ideas?

David: It usually comes back to biases—there are three big biases that come up time and time again. One is confirmation bias. It’s this idea that you're just confirming your beliefs in theories. And so the problem, the risk there is prematurely validating your hypothesis by setting the bar really low.

Overconfidence bias comes up time and time again. Your perception of your judgment is actually much greater than it really is, so you have excessive confidence in your own answers and might question whether you even need to experiment. 

Finally, there’s experimenter’s bias. When you're performing the research, you may have unconsciously influenced the results. This is when we usually discard anything that doesn't agree with our hypothesis. One of the ways you can kind of address that is to be more diverse and invite different perspectives into the process when you're synthesizing the data. Don’t just do it by yourself. Running multiple experiments helps there, too.

How can companies get better about embracing a culture of experimentation?

David: I feel like there's this gap where the companies that are embracing experimentation are getting further and further ahead of the companies that aren't willing to do it at all. The gap is only getting bigger and that's going to be a problem because some of these companies aren't going to be able to catch up or they're late adopters to experimentation and they're going to have a really hard time. 

To change this, it's very much about the culture of your company and your mindset. If you have something that you feel like you’ve tried to solve a few different ways and it just hasn’t worked, that’s usually because you don't understand the problem very well. So I recommend thinking deeply about the problem, trying to run experiments, and generating some more evidence about what the solution could be. A lot of times, we don't understand the problem enough and we've jumped to the solution too early.

For leaders, the best thing they can do is try to design an environment in their organization where this can occur. That's things like giving people time to work on this, not micromanaging, leading with questions instead of leading with answers all the time. And that really challenges the core leadership because if you feel like you always have to know the answer, you're probably going to have a hard time saying, we'll just go experiment and learn because you're going to have this inherent desire to always say what the answer could be. 

If there's one thing that you'd like people to take away from your book, what is it?

David: To be open to the idea of being wrong. I think the way we were taught in schools, at least the last couple of decades, has been very much rewarded for being right. There's usually one single right answer. But in your organization and your business—and your life for that matter—there's rarely one right answer. They're just choices. 

I would love for people to feel like they can actually apply their creativity and it's okay if they’re wrong. It's not at the end of the world. It's really a small test that you're running. How do you learn from that and try again? 

We actually created a job story for the book (using the Jobs to Be Done framework). For the reader, the job to be done for the book was: “When I have a business idea, I want to be able to rapidly test it so that I don't build something nobody wants.”

You can find Testing Business Ideas here.

One widespread piece of advice on OKR—and goals in general—is that you should “focus on goals that you can control alone.” Companies don’t want, for example, the marketing team to say that they didn’t achieve their OKRs because engineering didn’t do theirs, so they tell each team to focus on what they can control. The problem is that, by definition, this approach creates silos. If each team—or individual—focuses only on what they can control, every issue that requires cross-team coordination is stranded.

Whatever the organizational structure, there is always “white space” between different teams and departments. Companies need to learn to manage that white space, since we all depend on one another somehow, especially as companies scale. We need to enable teams to solve dependencies and work together on common priorities.

Shared OKRs align us around outcomes

That is why one of the underlying principles of OKR is that we align around outcomes, not silos. We start by thinking about what we want to achieve and then align our OKRs with other individuals or teams—even if they work in other functions, departments, or business units.

One of the underlying principles of OKR is that we align around outcomes, not silos.

Traditional approaches often focus on vertical alignment: ensuring that your goals align with your boss’s goals and with her boss’s goals, which can create silos. OKR focuses on 360º alignment - top, down, and sideways - eliminating silos and addressing interdependencies.

Shared OKRs are the most effective tool to create alignment between different teams or functions. In a shared OKR, two or more teams share the same OKR, but each one has different activities. You can either share the whole OKR (meaning the Objective and a set of Key Results), or you can share just a single KR.

When you decide on a shared OKR, you are creating an ad hoc team that will last as long as you have that shared OKR. Think of it as activating a "virtual squad" with all the teams/individuals required to achieve the shared OKR.

Defining shared OKRs

Keep in mind that OKR is not about everything that you do, so the small stuff does not need to be included on your shared OKRs. For example, if your marketing team wants to improve conversion rates on your website and needs engineers to complete certain activities, this means they’ve identified a dependency and need to solve it. If we are dealing with something small like changing a form, it usually means that the engineering team can track it as part of their day-to-day work and we don't need a shared OKR for it.

What would constitute a dependency that’s big enough to be considered a shared OKR between these two teams? Imagine if the marketing team was trying to increase usage of a feature, which would probably require not only promoting the feature but also improving it. Expanding the usage of that feature would be an excellent example of a shared OKR between marketing and a cross-functional product team (which usually also includes engineering and UX).

As another example, imagine that you worked as the recruiting manager of a large company. If everyone that had an open position decided to share that OKR with you, you could end up with dozens of Key Results, which misses the whole point of setting clear priorities. So hiring a single person would usually not be a shared OKR, while hiring 100 probably does need to be part of an OKR.

While we’re talking terminology, I’d like to mention that the terms “cross-functional” or “multi-disciplinary” OKRs can be misleading. Many dependencies exist inside the same function or department, which means we often need shared OKR inside the same function or discipline. The most common example is large product organizations where one product team depends on another, but that also happens inside other functions such as marketing, finance, or legal.

Deciding if shared OKRs are right for your organization

Creating alignment is one of the main reasons companies adopt OKR in the first place, but without shared OKRs they are merely playing alignment theater—giving off the illusion of striving for alignment—while continuing to work in silos as they always have.

Shared OKRs exist to solve dependencies. The more dependencies you have, the more you need shared OKRs. For example, companies organized around functional structures usually need a lot of shared OKRs, while companies using cross-functional teams or “squads" tend to have fewer dependencies and thus fewer shared OKRs. Dependencies always exist, so you always have some need for sharing OKRs.

Sharing is one of the hidden gems of the OKR world. It is a crucial concept, but few organizations use it well. People are so stuck in the silo mentality that once someone argued with me on Twitter that shared OKRs didn't exist and only gave up when I pointed him to the articles on my blog (check out Tips from an ex-Googler: Aligning Teams with Shared OKRs to read more on this topic).  

The nuts & bolts of shared OKRs

Remember that a shared OKR creates an ad hoc team. Just like any other team, people who share an OKR should have regular check-ins to track results and adjust the corresponding activities "for the duration of the shared OKR,” which is often a quarter, but may vary depending on the complexity of the goal.

A shared OKR means that a group of people share ownership and accountability for it. People are obsessed with individual accountability over OKRs, but you can't use a one-size-fits-all approach. Some people play individual sports, and some people play team sports. If you play tennis, you have an individual scoreboard, but if you play basketball, you have a team scoreboard.

What matters is helping the team win. People who argue that you always need to have a single responsible individual seem to forget that people have played in teams since childhood and understand very well the dynamics of team accountability. 

If you play tennis, you have an individual scoreboard, but if you play basketball, you have a team scoreboard. What matters is helping the team win.

A few pitfalls to avoid

The most common mistake is not using shared OKRs at all and not teaching employees how to use them. For the companies that are already using shared OKRs, I see a few common pitfalls.

The first one is failing to map all dependencies. Sometimes people assume that another team will be able to help without checking with the other team first. This usually does not end well. I have a great story about a team from Google Maps that failed to achieve their OKRs because they worked in silos and didn't share their OKRs.

The opposite mistake is also common: people want to share their OKR with everyone else in the company, which also misses the point.

Finally, sometimes companies create shared OKRs that are so big that diffusion of responsibility kicks in and individuals assume that others are responsible for taking action. That is why we always try to break down the shared OKRs into smaller chunks. If that is not possible, we may need a strong program manager to lead that shared OKR.

People are always asking for sales OKRs examples, so when I heard that Googler Sameer Rane gave a presentation about how his team uses OKR in sales, I decided to reach out to him.

I am thrilled to announce that Sameer, Sales Strategy & Operations Manager for Nordics and Benelux markets at Google, agreed to write a guest post together with his colleague Noelia Fernandez Arroyo, Director, Large Customer Sales for Northern Europe.

The right way to use OKR in sales is to think beyond the sales quotas - which are usually kept apart from OKRs - and focus on the changes in behavior and processes that will drive revenue. In this post, Sameer and Noelia share real-life stories of how OKRs succeed - and failed - in doing that.

Please note that different teams use OKR in different ways inside Google and many other leading companies, so this post represents the author's' personal views and experiences with OKR.

Enter Sameer and Noelia.

This post aims to provide a few practical examples of how sales organizations can use OKRs to drive sustainable business impact based on our experience working at Google in Northern Europe.

In this post, we cover two examples that have worked well and one that didn't work for us. For each case, we describe the business context that led the team to select that OKR and the results that were driven by it.

Sales OKRs Example #1

Business context: Google has been leveraging machine learning to generate automated opportunities for Sales teams. However, a strong degree of behavior change was needed to drive confidence in the Sales teams to “trust” machine-generated opportunities.

End Goal: Make machine-recommended opportunities a key component of the Sales pipeline for the business.

OKR Used and How it Evolved:

Objective: Get the sales teams to adopt machine-recommended opportunities as part of their core operating model.

Key Result

• Increase the review rate of the machine-recommended opportunities from X to Y.

We wanted to track the adoption of the machine-recommended opportunities by front-line sellers. This OKR was monitored in stages initially by measuring the review rate of these opportunities where the teams marked these as "Accepted" or "Not Accepted."

Eventually, as teams grew more comfortable with the "review rate" being the Key Result, we moved to "Pitched rate," where we started tracking the number and dollar-value of reviewed opportunities that were pitched. Subsequently, this was updated to "Implemented rate" as the Key Result, where we tracked the final implementation or winning these opportunities.

Results: By setting and tracking this OKR over a 24m+ period, the sales leadership was able to drive a sustainable behavior change among the sales teams to the extent that the machine-recommended opportunities now form an integral component of the sales pipeline. The strongest proof point for this change is the fact that this operating model has become an integral component of the behavior of the sales teams and we don't need to set a specific OKR for it.

The largest business benefit from this change has been that the sales teams can focus now on driving higher-value deals by relying on machine learning to identify scalable opportunities.

Sales OKRs Example #2

Business context: As part of setting up a team of product sales specialists in the region, the ambition was to drive higher product adoption at an overall market-level that spans multiple channels, i.e., large, medium and small-scale portfolio of customers. However, the compensation scope for the sales teams was tied to a single channel, and hence we needed an alternate mechanism to achieve the goal.

End Goal: Make the Specialist team operate in a cross-channel manner to drive product adoption at market-level while maintaining the compensation design.

Key Result used: Increase cross-channel product adoption for priority product metrics from X to Y

Results: By setting cross-channel OKRs while maintaining channel-level compensation, the team was incentivized to identify scalable and innovative ways of driving product adoption across channels. This led to a higher degree of collaboration with advertising agencies that operate irrespective of channels. Teams included clients from another channel for product training sessions. This has resulted in global leadership for our region across some of high-priority product metrics.

Sales OKRs Example #3

Unfortunately, not all OKRs work as expected. This last example is about an OKR that did not deliver the business impact as initially anticipated. And knowing the “why of failing” is as important as we aim to get better at driving behavior all the time.

Business context: As part of driving a stronger sales mentality, sales teams were encouraged to upsell on top of the budgets already agreed with the customers.

End Goal: Make upselling a core component of the sales team’s operating model

Key Result used: Drive incremental $ of upselling in the quarter of X.

[Note from Felipe: I would rewrite the Key Result above to Increase upselling from X to Y.]

Results: After tracking this Key Result for a couple of quarters, we could not establish a clear business impact on the upsell revenue being booked by the Sales teams. In hindsight, there were two key challenges that influenced the execution of this OKR. The first challenge was around reliable reporting of upsell opportunities. The measurement relied on the sales teams tagging an upsell opportunity e.g. [Qx UPSELL]. However, the sales teams either did not always put the tags or misspelled them, leading to the incorrect representation of actual upsell activity. The second and the bigger challenge, however, was that of moral hazard, where the teams could under-report a sales deal and add the remaining component as an upsell to “show” success on the OKR front.

Lessons Learned

In summary, an OKR should be a mechanism to create a sustainable business impact that drives value for the organization and provides a clear line of sight for the teams to prioritize their work. And more importantly, that everyone in the organization understands the why behind the OKRs.

Ultimately, success is proven when behaviors have changed, and you don't need to include that topic on your OKRs anymore. You will definitely need to track that behavior as part of very strong business rigor in your routines (business review meetings, quarterly reviews, etc.) and great questioning, to make sure nothing is dropping in the business performance. But definitely, we embrace OKRs as a very smart way to motivate and guide our business and teams.

[Note from Felipe: What Sameer and Noelia are saying here is that if you succeed, you will have created sustainable change and you will be able to turn you Key Result into a health metric/monitoring KPI.]

Sameer can be reached out through LinkedIn here; Noelia can be reached out here.