Decomposing Big Ideas in OKRs

Hey folks, 

Happy Thanksgiving to all readers in the States! May you be stuffed with enough turkey and pumpkin pie for the rest of us elsewhere. 

I want to say thanks to all of you for reading this newsletter month after month and sticking with me. Genuinely—it means a lot, and I really appreciate getting to share ideas with you and hear your insights.

I’m also going to give a little thanks to everyone’s favorite goal-setting framework, OKRs. Still genuine. :-) OKRs can bring big rewards to teams and organizations all over. To reap those big rewards, though, you have to keep your goals, hypotheses, and experiments smaller and more manageable—which a lot of teams struggle with at first. Sound counterintuitive? I explain in the article below.

- Jeff

Article: Decomposing Big Ideas in OKRs

We love big ideas, don’t we? It’s exhilarating when we come up with a grand plan we haven’t thought of before. It’s fun to think about how to start building something new and ambitious. Because it’s so exhilarating and fun, people tend to start big with modern product management work too. 

They come up with big hypotheses: We should create a new social network.

Big OKRs: We should drive acquisition, revenue, and retention and double our numbers.

And big experiments: We should build a fully working proof of concept and ship it to 10,000 people.

The problem is, those big ideas take a long time to build and execute, and they carry a lot of assumptions—and, therefore, a lot of risk. That doesn’t mean we need to throw away those big ideas entirely. But it does mean we need to break them down into smaller assumptions that we can test and learn from quicker. Ultimately, if done correctly, what we learn and build based on our smaller assumptions and tests will lead to the execution of our big ideas (or better, more informed ones) over time.

You can always break down a big idea

Several years ago, the team of a new startup wanted to facilitate a way for people to find out about cool events and the people going to them. They decided they needed to build a new social network. In the network people would share events and meetups they were planning to go to. Others who liked that person, or found that they consistently went to cool events, could then follow them and learn about and go to the same events they were going to. 

Sounds like an interesting idea, but again: “Build a new social network” is a big undertaking. The startup team, however, thought it was their only option. In their mind there simply wasn’t a different way to test their idea other than build the whole dang thing. 

They were wrong. There is definitely a way to test their idea—they just didn’t know how to make their assumptions smaller. They didn’t know the right question to ask.

What would have to be true…?

When you have a big idea, think of it as one big assumption. In the case of the startup team, their big assumption was: 

People want to share events they’re going to, see the events other people are going to, and follow people that are going to the events they like, and if we build a social network for that, they will do all of those things.

To break down that assumption, ask: What would have to be true for all this to be true? In other words, what would the circumstances have to be for people to want to share the events they’re going to, see events that others are going to, and follow people based on the events they share?

Well, at minimum people would have to…

1. Attend interesting events on a regular basis

2. Be willing and able to share those events and tell people where they’re going

3. Want to follow other people to find out what events they’re attending

4. Go to the events others are sharing about

That’s four levels of assumptions to start. Time to break them down even further. Take the riskiest one, and start there. Let’s say it’s Option B: People would have to be willing to share the events and tell people where they’re going. 

What would have to be true for that to be true? 

Well, people would have to…

1. Not worry about their safety when sharing where they’re going to be

2. Not worry that people they don’t like would show up

3. Go to enough events that are worth sharing with others

That’s another three levels of assumptions. And guess what? You can keep going from there. 

Eventually, as you decompose your larger assumptions into smaller, more manageable ones, you will find something that is actually easy and quick to test so you can learn whether or not your idea has enough interest and merit to warrant continuing up the assumption chain onto riskier and bigger assumptions.

Ultimately, after spending months building out an entire social network, the startup team discovered that people didn’t want to share about the events they were going to, and in fact, they didn’t really care enough about what events other people were going to either. It was a total bust. Had they broken down their assumptions, however, they could have found an easier experiment to run over two weeks and learned that their idea was dead in the water much earlier.

Decomposing big key results

This decomposition question and process works for big assumptions and hypotheses particularly well, but it works for OKRs too. 

Say you set the following initial key result: Customer retention increases by 80%.

That’s a big goal—a very high-level key result. To find out smaller key results, say for different departments, or to find the leading indicators that will tell you you’re on the right track for that key result, ask the same question. What would have to be true for retention to increase by 80%? 

We’d have to see…

1. More people signing up for the service

2. Average order value increase by 20%

3. Every new customer make at least 1 purchase in the first week after signing up

And again: What would have to be true for those things to be true? (Or, for those things to happen.) On and on and on.

Customer journey mapping done simply

With OKRs, we talk about customer journey mapping to help you figure out the customer behaviors you should target in your key results and even spark ideas for what solutions and experiments you may want to test. In a basic sense, this activity is a less codified version of customer journey and user story mapping. It allows you to back into, or reverse engineer, a customer journey—which is especially helpful if you’re trying to build something that doesn’t exist yet and you don’t have a customer journey to begin with.

The benefits of decomposition

Figuring out your customer journey is just one benefit of using this question to decompose your biggest assumptions. Doing so also greatly reduces the amount of risk you take on in your work. If the startup had run a test on just one of their smaller assumptions—whether or not people would feel safe sharing their whereabouts, for instance—they might have learned valuable information that either could have changed their approach or told them early on to pursue a different idea. 

Another big benefit is that it gives teams a bias for action and keeps things in motion. Instead of building in stealth mode for a year and putting out a wholly new, untested product in the world with a tentative “ta-da”, you’re running frequent tests to refine your idea, figure out what’s necessary for your end product to ensure it provides real value to people, and building it one piece at a time. It makes the work smarter and more manageable for everyone. And in the end, you’ll have a better product and much more satisfied customers. 

What’s new on the blog

OKRs Are Hard. They’re Supposed to Be. – OKRs are simple in concept but difficult in practice. Writing good OKRs is the easy first step—like popping the tab on a soda can. The rest of it is shifting your organization’s whole way of working—like shaking up the can and dealing with everything that bubbles out. That should be hard. In last week’s blog, I talk more about why, as well as how to think about working with OKRs so you can be prepared for change.

The Scariest Question in Product Development – “You know what would be cool?” How many times have you heard someone say that in your product dev meetings? Next time you do, stop the conversation right there. Check out the blog article to learn why.