When I started teaching Product Management at the Adelson School of Entrepreneurship at Reichman University I wanted to demonstrate the thought process behind writing and communicating requirements.

I showed the students this hilarious video to explain why things need to be well-defined, but when it came to communication I used another technique. 

I asked the class for two volunteers and gave one a simple line drawing I prepared in advance. They needed to guide the other student in drawing the same thing on the board (without the latter seeing it of course).

I had two flavors of this exercise, meant to demonstrate not only the skill of communicating requirements clearly but also the benefits of agile development. In the first flavor, the student who got the drawing needed to get out of the classroom and record the instructions on her phone. The other volunteer would then get the recording and draw on the board what they understood that needed to be done. They could listen to the recording as many times as needed but there was no other communication between the two students.

In the second flavor, the student who got the drawing could guide the other one from within the classroom, with full communication between the two until they were done.

Of course, the second flavor yielded much better results than the first one. It’s much easier to get to the desired outcome when you see what you’ve got (how the other people interpreted what you said) and correct them when they got it wrong.

There were, though, additional flavors that the students created themselves despite getting the same instructions every time. 

In some cases, the student who got the drawing started her instructions with a general description of what was it that they were trying to draw: “We are drawing a boat on the waves”. Other students described the technicalities of the drawing: “Draw two triangles and a line between them.” These flavors existed regardless of whether the instructions were pre-recorded or delivered live in class. 

Of course, the students who started by explaining that we were drawing a boat got better results than the ones who dived right into the technicalities. They also didn’t stop there but guided them throughout the drawing with additional context: “We are going to start with the sails. We have two triangle-shaped sails, the left one smaller than the right one, with a mast in between them. The mast is slightly taller than the right sail.”

These students created a language that they later used to describe the end solution in a hierarchical manner. It was like a ladder connecting the bigger picture and the details, and they climbed and descended it as needed to keep the context intact and the communication clear.

This hierarchical context is an extremely powerful tool. You might already be using it when you write requirements (if you don’t, I highly recommend starting to do so). But most product leaders I work with – even the ones who use it with requirements – are rather confused when it comes to OKRs.

OKRs are a form of requirements – business, outcome-oriented requirements – and a hierarchy is extremely important there as well.

Here is why, and what you can do to define your OKRs the right way.

You Can’t Afford Too Many OKRs

When I start working with a company on their OKRs, the first question that I ask is how many OKRs they have. I often get a double-digit number, sometimes close to 20 or even above.

That’s the first signal that they were not doing OKRs the right way.

The purpose of using OKRs is to help with focus and clear definitions of the challenges we want to address. A double-digit number of goals is as far from focus as you can imagine. It usually means you can’t decide, and that’s not a good strategy to pursue.

The magic number with OKRs is between 3 and 5.

It usually means you have to understand what’s really important for you.

But the reason you often end up with 20 OKRs is that they are not defined at the right level. They are the details of the picture, but you haven’t drawn the picture itself. You are telling us to draw a triangle, while we have no clue that we are drawing the sails of a boat.

Try grouping your OKRs into larger objectives, or start from scratch at the top, by asking what is the one goal you are trying to achieve.

Eventually, you need to have a hierarchy of OKRs, with 3-5 main ones, each broken down to 3-5 OKRs, and then again and even a fourth time if needed.

Now you have created the ladder that people can climb and descend on.

People Need to Remember Them

Your OKRs are meaningless if people can’t remember them. It would be like this printed list of company values that appears in every meeting room but is meaningless if people don’t actually behave that way. 

People need to remember the OKRs without going to check their lists. The primary reason for that is that real progress is made not when people do the work (which is when they can go and check boxes off the list) but rather when they think.

In order to get to the goals you want to achieve, you need them to be what keeps people up at night. If you have too many such things, the thing that will keep your people up at night would be the fact that the list is too big, and that management can’t make hard decisions and give them proper direction.

I once heard someone say that there are only so many things you can think about in the shower, and that’s what we are aiming for here: to create clarity for people to know what they should be thinking about.

The best way to remember something is when it tells you a story. People remember stories. If you need to memorize a random list of objects, the best way to do so is to tell yourself an imaginary story where these objects appear along the plot. 

A hierarchy in OKRs is your way of telling the strategic story in a way that people can remember. It could look something like this: We are aiming for an IPO this year. To do that we must win on the following fronts: We need to be profitable, we need to demonstrate world-class processes and governance, and we must keep our leading position in the market. To be profitable, we are working hard on increasing our ARR, and we will revisit our costs to see where we can cut unnecessary ones. Our approach to increasing ARR is to sell to larger accounts, monetize on an existing product we already have, and open a new product line in a new area.

Note that these are company-level OKRs. This hierarchy continues as one until it makes sense to break it down by department.

Strategic Resource Allocation

When your OKRs are clear, you can use them to allocate your resources strategically. You can decide how many people should work on each OKR, adding perspective on top of the bottom-up resource allocation (these features would take X man-months to develop so we need that many people).

It also helps when things get rough (and they will). For example, if one project in a certain OKR is taking longer than expected, you can decide if you want to reallocate the resources within the team working on this specific OKR or compromise other OKRs in favor of this one.

A hierarchy that provides a better context could also lead to better solutions.

Not only in the sense that the better you understand the problem the better the solution would be, but also in terms of creative solutions when resources are limited.

For example, when you climb the ladder from a certain feature back into the goals, you might be reminded that the most important thing here is to be ready with a demo for a certain conference. It doesn’t matter as much if the system would be scalable by that date (you can add it later on), so perhaps you can take resources from this effort and shift them into other places that need a helping hand.

The example I gave here might be trivial if you define your requirements properly. But given that you can’t define everything explicitly before you start, you won’t always get to all the details in advance. When you put things in context it helps everyone understand what’s most important and allows them to chime in and suggest solutions. Stories bring people together, and your OKRs need to tell a story. A well-defined hierarchy is the way to get there.