Begin with the end in mind

Define outcomes before projects.

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.

---

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.