How to OKR: Why objective should be qualitative?

Posted by Ivan Osmak
on December 22, 2017

I’ve just had a conversation with a fellow agile enthusiast and a question popped up. Namely, is “Increase new sales by 50%” a good objective?

The theory or best practices say that objective should be qualitative (no numbers), and key results should be quantitative (numbers). I also happen to think that in practice this works best, and here is 5 reasons why.

1. Objective should communicate intent

The purpose of an objective in the OKRs methodology is to communicate intent or strategy. For example, “Increase new sales” communicates that upsell and cross-sell are not priorities in the coming period, but that we as a company should focus on the new sales.

Putting a number in the objective waters down this message by making it tactical. The target of 50%, steals attention from our intent.

2. Quantitative objectives are vague

Going back to our example – “Increase new sales by 50%” – is actually pretty vague. Should we increase the number of new customers by 50%? Is it revenue? Is it MRR? Is adding one big customer equally good as adding 30 smaller ones?

3. Objectives are one-dimensional, there are no constraints built-in

Let us imagine that we increase new sales by 50%, but we do that at the expense of giving 80% discount on average. The objective would technically be considered accomplished, but we would leave a ton of money on the table – or even worse, be selling at the loss. Sometimes, that’s a good strategy – but in this case, it was not a conscious decision.

4. It’s hard to come up with key results for a quantitative objective

Now, this is more of a technicality – but, if you are going to use OKRs, why make your life harder. When you have “increase new sales by 50%” as your objective, what exactly will be your key results? Will you repeat your objective with the key results?

5. You are setting a bad example

You may think it’s not a big deal if you have “by 50%” in your “Increase new sales” objective – as everyone gets it. But, sooner – rather than later – you will come across an objective saying “Reduce cyclomatic complexity by 15%”.

No one outside of the engineering team will know why in the world is this an objective – and rightly so. For non-tech people, let me translate, the lower the cyclomatic complexity, the easier it is to maintain codebase. So, wouldn’t that be a better objective “Improve maintainability of our codebase”?

Wrap up

Let’s now see how to make this objective better.

Bad:

  • Objective: Increase new sales by 50%

Good:

  • Objective: Increase new sales
    • Key Result #1: Increase new MRR from $40k to $80k
    • Key Result #2: Sign up 20 new customers
    • Key Result #3: Decrease the average deal discount from 30% to 20%