More and more organizations are adopting OKRs to set goals for their teams. Failure is one common theme that surfaces in the first-time adoption of OKRs, especially in the adoption of top-down OKRs. And there are some good reasons why this happens. 

First off, what are OKRs?

Before we jump into the details, I want to take a step back to explain what OKRs are. OKRs (short for Objectives & Key Results) are a goal setting technique that drive alignment and foster autonomy in product teams. 

OKRs are made up of two parts: 

1. An objective that a company would like to achieve.
2. Measurable Key Results that determine how much of the objective was achieved.

Objectives

OKR Objectives should never be tasks. Instead they should always point towards outcomes. By avoiding tasks we are leaving it up to the teams – the experts of the product – to find and determine which levers need to be pulled to achieve the objectives.

Here are some examples of good and bad OKR Objectives.

❌ – “Implementing a new CMS system” – not a good OKR Objective as this defines an output, not an outcome.
❌ – “Roll out feature x to all users” – again, here we are prescribing what the output will be.

✅ – “15% decrease in dormant accounts” – a good example of a good OKR Objective that defines an outcome, but does not define how to get to that outcome.
✅ – “Increase new account creations by 50%” – another good example of an OKR Objective that focuses on what the end result should look like. There are a number ways of how teams/squads can get such a result.

Key Results

This leaves us with Key Results. Key Results are the levers that product teams can pull to achieve the defined objectives. Key Results should be measurable and determine whether an Objective was achieved.

Let’s take the “Increase new account creations by 50%” objective above. Examples of good key results for this objective might be:

✅ Double the amount of referrals from the refer-a-friend programme.
✅ Increase sharing of user-generated content with non-customers by 10%.
✅ Increase the website > account created conversion rate by 5%.
✅ Attract 20% more customers through paid marketing channels.

When setting OKRs it is mostly the responsibility of the teams to identify the best Key Results for the Objectives (of course with radically candid feedback and healthy discussions with leadership).

OKR Failure Reason #1 – Autonomy (the lack of)

One of the main reasons why OKRs have been so successful is the autonomy and space they give teams to solve real problems in ways they deem best. Empowered teams are higher performing teams that focus a lot of their efforts on finding the best levers to pull to improve their product in a way that aligns with the set Objectives.

Good leadership teams focus on finding the next best areas of opportunity for the company to invest in and that the right resources are available for teams to achieve objectives.

It is impossible to have a leadership team that has a strong grip on the company direction, and also being experts on the tactical level. When leadership teams start worrying about the solutions that should be delivered to achieve objectives, it becomes much more likely that higher-value solutions are missed in favour of solutions that are prioritised due to bias and other inaccurate prioritisation techniques.

Of course autonomy requires a high level of trust (which is why I feel so strongly about Trust in a product environment). And this is why hiring the best talent is so important for organisations.

OKR Failure Reason #2 – Projects

The term “project” has become a bit of a taboo in the world of product. It’s come to be associated with an inefficient, antiquated way of working. But the reality is that companies will always have projects that need to get done (e.g. implementing a CRM system, implementing a reliable event tracking system, etc.).

A lot of people try to hide projects behind objectives. I strongly believe that this is a mistake. Projects should be referred to as projects, and should be lead by a strong project manager to ensure the right scope is delivered at the right time, and proper communication is maintained throughout. This also helps with team morale, as the team enters the initiative with the right mindset and expectations.

Most importantly – OKRs should not be used for projects.

OKR Failure Reason #3 – Focusing on the letter of the law, not the spirit

As explained earlier, OKRs are used to 1) maintain alignment, and 2) give teams the autonomy they need to solve problems in the best possible way.

If a KR has been set at increasing a metric by 50%, but at the end of the period, the metric was only increased by 10%, then it is clear that something has gone wrong in the process.

On the other hand if the metric was increased by 45%, then even though the KR was not hit, the reality is that the performance was actually still pretty good and probably the focus during the period was on the right thing. 

Treating these two examples as equal failures (i.e. focusing on the letter of the law) is detrimental to team morale. And so spending time perfecting OKRs for the period to get perfectly accurate numbers is not the best use of anyone’s time.

OKR Failure Reason #4 – Not using stretch goals

The intended use of OKRs is to have inspirational, stretch objectives and KRs, rather than “targets” (albeit they still need to be somewhat achievable, not impossible). At the end of a period, the measure of success is a more analogue one, which focuses more on how much of the objective the team has managed to achieve, rather than on whether the objective was achieved or not.

This might be a bit of a controversial subject, however the rationale behind stretch goals is that it will allow teams to think of bigger, bolder and more innovative changes that could potentially take the product to another level. 

The danger of opting for more conservative targets is that it can easily trap teams into optimising for local maximas, rather than looking at taking the product to a higher maxima.

CXL – How to get over local maximum?

Of course the flipside is that not fully hitting stretch goals might have a negative impact on team morale. Which leads me to failure reason #5.

OKR Failure Reason #5 – Not aligning the teams on how OKRs work

Not everyone might be familiar with how OKRs work. Since OKRs require a shift in mentality it is extremely important that everyone understands what is expected of the role they are in, what they are accountable for and how this will feed into the success of the organisation.

Product teams need to understand that they are empowered to take decisions on which initiatives to opt for. Leadership teams need to stay away from prescribing solutions and focus on finding the right objectives (albeit healthy discussions on potential solutions are still encouraged), etc.

OKR Failure Reason #6 – Trying to get it all right on the first try

Even though the concept of OKRs is a fairly straightforward one, in practice it is not as intuitive as one might think and it might also not align with what people are used to. And so, some form of failure is to be expected, especially in the first round of OKR adoption.

Perfect is the enemy of good though, so the trick to getting OKRs right is to just get started. Make it abundantly clear to your teams that failures are to be expected, but also to make sure that you should be learning in the process and improving.

As long as treating OKRs as being an empowerment technique for your teams, you will iteratively arrive at an implementation of OKRs that work for you and your organization.

For anyone who’s looking to start using OKRs for the first time, I had found this session by Whitney O’Banner, who talks about a very practical approach to first-time OKRs, to be very useful. I strongly recommend watching.

Other very useful resources on setting up companies to be successful in the adoption of OKRs can be found on Marty Cagan’s insights blog, such as this post.

The short answer is, very little, especially in the tactical product development process.

As we look for the next highest-value improvement to make to our products, it is very tempting to compare our products’ offerings with those of our competitors. Lo and behold, there’s always something that our competitors are doing better than us. 

“Their product is much faster than ours“, “They have more features than us“, “They’re using AI and we’re not“, “The product is cheaper than ours“.

We can go on and on and on.

It’s therefore, extremely easy for us product managers, to think that by fixing these “shortcomings”, our product will be more successful. It has to be the case, right? Our competitors have researched these features and have beat us in releasing the next best thing that our product should have.

Except that, actually, the latter is just our assumption of what’s going on on the other side of the fence. 

Sure, it might be the correct assumption in some cases, but in some cases it may also be wrong. Like everyone else (us included), our competitors make their own mistakes. By relying on the assumption that our competitors are correct, we risk making the same mistakes ourselves, thus losing valuable time to work on and learning more about other changes in the product that our customers truly want. 

Moreover, and more importantly, our competition’s target customers might not be exactly the same as ours. And so, in copying other products, there is a risk that we are making changes to our offering, that does not actually give additional value to our own customers.

As product managers we should not be using too much of our time trying to understand what our competitors are doing, but instead we should keep in mind that our focus needs to always remain on our customers and our target audience. By focusing on getting to know our customers inside out, and truly empathising with them, the next best thing that our product is missing, automatically becomes extremely evident. More importantly, this highly increases the chance of success of the new features that we ship.

UXPin recently held a webinar about how great products are not just about features, during which I have shared my view on the importance of understanding your customers in the process of building great products. You can listen to the recording of my presentation in the link below.

It’s Thursday afternoon. John, a Product Manager at an e-commerce platform, is preparing for tomorrow’s grooming session with the design & engineering team. One of the features that he wants the team to deliver is to allow users to compare different models of the products they’re looking for.

As the customer expert, John has spoken to his online buyers and he’s done the necessary research before he came to the conclusion that users want this feature. The evidence is there. Users want to compare products. The team’s going to deliver and the users are going to love them for it. Innovation is John’s middle name.

And so John starts writing the user story:

As an online e-commerce portal user,
I want to have a Compare Features button in the product details view, to compare the specifications of the product with another product that I select,
Such that I can choose the best product for my needs.

And so, on the following day, the designers and the engineers are discussing how to best implement a:

1. “Compare Features” button
2. In the product details view
3. To Compare the specifications of the product
4. Comparing the product with another product that the user wants to compare with

Killing Innovation

The problem with the example above, is that John has prescribed the near-exact implementation of the feature to the designers and engineers, without going through the thought process that designers and engineers would have gone through themselves. And since the thought processes of designers and engineers are very specialised and focused on their areas of expertise, it is highly likely that the product manager will have missed out on asking crucial questions that would have led to a much better and more innovative product to be built. 

John has inadvertently turned the designer into a design secretary and the engineers into programmers. Innovation is no longer his middle name.

Instead, if John had focused on providing the crucial context about the customers and their objectives, the engineers and designers would not have been immediately biased towards the prescribed solution, but instead would have explored other possible solutions to the problem that John might not have thought of.

Let’s look at an example of how this user story could have been positioned a bit better:

As an online e-commerce portal user who is overwhelmed with the choice of products,
I want to understand which products best fit my needs,
Such that I can decide which one to purchase.

Already, this is a much broader story that reflects the users’ actual objectives, which will start triggering questions from the design & engineering team around the implementation possibilities to ship a product that makes it easier for portal users to decide on which product to purchase. 

Instead of a “Compare Feature” button the team could end up discussing adding a “Similar Products” view, or alternatively highlighting the key differentiators of each product in the search results screen. You get the gist.

Focus on what you should be focusing on

I believe that as Product Managers, we should focus our efforts on understanding our users and customers inside out. When we are handing over the work to our designers and engineers, we need to make sure that we’re providing complete, accurate and up-to-date information on our users and their success measures, so that together we can explore innovative solutions that deliver the highest amount of value to our customers.

Engineers & Designers are hired to engineer and design solutions. As Product Managers we should leverage this to unite the team and together reach our ultimate objective – building products that people love.

We all know that biases exist and we are all very much aware of them. We are all extremely logical and rational product managers and we never let our biases affect our prioritisation efforts.

Or maybe not.

I really like how Ellen Chisa describes product managers as “continuously going back and forth between the 10,000-feet view and the 2-inch view” in the book Product Leadership. Product management requires conscious efforts to maintain innovative, efficient and successful discovery and delivery processes, to build and ship products that people love.

This is hard work. More than one might think at the outset. And because of all the things we have to think about, it is extremely easy for us product managers to miss out on certain biases that crop up on a daily basis. 

We can be blind to the obvious and we can be blind to our blindness

If you’ve never seen this clip, I suggest that you take a minute to watch it and follow the instructions.

The video shown above is based on a book written by Christopher Chabris and Daniel Simons, called The Invisible Gorilla. In their experiment, Chabris and Simons noted that more than half of the viewers were convinced that there was no gorilla in the clip. This highlights how difficult it is notice things other than what you’re focusing your efforts on. As Daniel Kahnemann highlights in his book, Thinking Fast and Slow, we can be blind to the obvious, and we are also blind to our blindness.

The effects of biases

As product managers, we need to make sure that we are building products that our users love, and we can only do that by shipping products that our market finds valuable. The presence of personal biases is not desirable as these can skew our view of what the market desires, which leads to decision-making based on inaccurate information.

Here are a few examples of biases and how each of them may affect us in our role of Product Managers.

Confirmation Bias – Searching for and interpreting information in a way which confirms previous beliefs. 

We all have our opinions on what we should be building/improving in our product, and sometimes it is extremely easy to validate our ideas by looking at data that will favour these ideas, and ignoring additional data points. 

Availability Bias – Information that is readily available in our mind is given more weighting than other information.

When we’re looking at our options for what to build next, it is easy to give more importance to the options that we’ve been thinking about recently, even though there might be other areas that will give us greater benefit, but for which we don’t have enough information on.

Overconfidence Bias – Being overly confident in our or other people’s ability to make good decisions.

Experience always helps, however it’s easy to think that some decisions will work simply because the person taking the decision “has done this before”. When we follow this train of thought we are likely not giving enough thought to the differences between the current scenario and what’s happened in the past.

Sunk Cost Fallacy – Pouring more and more effort in a feature/endeavour as a result of previously invested resources.

The more effort we put into a given endeavour, the more we become emotionally tied to that effort. It’s easy to keep on putting more and more effort into a feature that we’ve taken a long time to build, because we “might as well get some return on all that investment”. In these cases we would probably be turning our backs to other opportunities which will benefit the product to a greater degree.

Ostrich Effect – Avoiding negative information.

We will always find some data which could suggest that our hypotheses are wrong. As product managers we should be investigating this data and not shrugging off, to make sure that we are really delivering on sound hypotheses that will ultimately improve the value of our product.

3 Steps to Overcome Bias

The first thing that we need to be aware of is that biases will always be present – it’s human nature. Everyone is susceptible to biases and nobody is able to completely overcome them. At the same time we also need to be aware that it is also impractical to constantly question our thoughts as this can easily lead to brain fatigue.

There are ways, however, how we can overcome cognitive biases. I suggest following these 3 steps to becoming better at overcoming bias:

1. Bias Awareness – Awareness is always the first step. By being aware of the different biases that exist, we are more inclined to self-challenge our thoughts, thus reducing the amount of bias in our hypotheses and decisions.
2. Bias Salons – The more you think about a particular scenario/hypothesis/idea, the more difficult it becomes to identify any biases that are present. It is therefore important to walk through your hypotheses with peers and key stakeholders, have some discussions around the data backing up the hypothesis, and to reflect on any biases that may be affecting the decisions.
3. Decision Transparency – We should always be transparent with our peers when we take decisions, by clearly communicating the rationale behind each decision that we take. Being open and transparent allows for constructive criticism which could highlight aspects that were not considered in the product discovery process.

This post was inspired heavily by Janice Fraser‘s session on Uncovering the Truth at Mind the Product, London, 2018.

Today, I would like to talk a bit about self-improvement, and how I’ve dealt with the various ups and downs of this process.

Most people have heard about Mozart and his prodigious musical abilities. Mozart spent the early years of his life putting most of his focus on learning music. Day in, day out, he practiced, and even though I can’t personally vouch for him, I am pretty sure that he’s made a lot of mistakes and put a lot of effort in learning from those mistakes. Yet, he is still referred to as a musical prodigy, rather than the kid who spent all of his time practicing music.

My point is, it’s easy for us to focus on the results or the ideal outcomes, and ignore all of the effort that’s required to achieve results. 

We all read about what’s expected from product managers and product leaders in our industry. Know your customers inside out, constantly communicate your product vision, foster innovation in your design and engineering teams, and many many others… Yet sometimes we find ourselves saying….

Oops, I did it again.

Even though we know what we need to do to become successful product managers (or anything else really), and even though we’ve put conscious effort in improving, we still realise from time to time that we’ve fallen short of achieving what we want to achieve.

And I bet Mozart also had his fair share of frustrating iterations, which did not seem to result in any self-improvement, even though he took honest actions to improve his output. 

This happens to all of us.

It’s Fine

It’s fine to make mistakes (sometimes even more than once) – but at the same time it is extremely important that we are disciplined with ourselves enough to keep in mind that it is only fine if:

1. We’re humble enough to accept that we’ve made mistakes,
2. We’re honest with ourselves to understand why we’ve made the mistakes,
3. And, finally, we find the energy required to get back up on our feet and try again with more determination to succeed in the areas that we’ve failed.

Learn. Measure. Build. Just like Mozart and the other prodigies of the world.

Impostor Syndrome

Although a necessity for our own personal success, this frequent iteration of self-improvement cycles, can take its toll on our own well-being and can sometimes also make us feel like impostors.

The ever-so-reliable Wikipedia defines Impostor Syndrome as “a psychological pattern in which an individual doubts their accomplishments and has a persistent internalized fear of being exposed as a fraud”.

What’s important to realise here is that we all make mistakes, and it’s fine to not be getting things right the first time round. Being humble enough to accept mistakes and making active improvement efforts should be our aim. Success will come as a result of our actions. And finally, we should definitely not feel any shame whilst going through this process.

Impostor Syndrome is much more common than one might think, and I was extremely appreciative of Martin Erikkson’s opening speech at Mind The Product 2018 in London, who spoke about how prone Product Managers are to feel like impostors. 

To close today’s thoughts – self-improvement is an iterative process, which takes time and can be quite frustrating. But it’s always good to keep in mind that everyone’s doing it and nobody’s expected to get things right from the first time round. As long as we remain humble in the process and honest with ourselves and those around us, we should only be a few iterations away from success.

As Product Managers we are always looking to build better products and better experiences for our users. Most thought leaders in the product space profess that the single best way to do this is by getting to know your customers inside out. Of course, there are varying degrees of knowing your customers. Your job as a product manager should be to understand your customers in as much detail as you can, so that you can make the best decisions for your product.

If you can’t get much deeper than “Our customers are Saas businesses that generate more than $50 million revenue every year”, then you probably need to dig a bit deeper.

• What does a typical work-day look like for your users? 
• What do they achieve by using your product? 
• What other complementary tools do they use? 
• What are their own customers trying to achieve? 
• Why do all our customers have pet Mongooses at their offices?

You get it…

When you think about it, we are a handful of product managers, trying to build great products that will be used by hundreds, thousands or millions of people. Each person will have a different view of our product and how to use it. Ours will also differ. 

Whilst we all have great ideas of what our product roadmap should look like, we are not the end users of the product that we are building. Our opinions of the product, how it should be used and of the value that it delivers, are rather useless if they do not align with the opinion of the market – our customers and users.

By understanding our market’s needs at a more intimate level, we can empathise more with our users, which in turn allows us to ship better products that our users love.

I like to summarise the above with a couple of sentences:

Your opinion does not matter. The market is the only valid opinion.

I have found these blunt words to be extremely helpful in my role as a product manager. They serve as a constant reminder of what we need to keep on top of mind when discovering opportunities and taking decisions on what to build next. I have found them so helpful in fact, that I’ve set this as a permanent background of my to-do list – a trello board that I look at on a daily basis.

So how do we build for the market?

We build for the market by building products that solve problems and blockers that prevent our users from getting things done. To do this, we should be speaking to our customers to understand what is it exactly that they want to solve, and, more specifically how they measure success.

By understanding the problem at hand and the success metrics, we can provide the necessary context for our team to design and engineer solutions that solve these problems for our users. If we focus on providing accurate context and clear outcomes, it becomes easier to build more innovative products which have a much higher chance of being adopted by our users.

A lot of people think that a Product Manager’s role is to be creative and come up with features for engineers to build. I disagree with this. As Product Managers we should not be primarily thinking about features or defining the solutions for our engineers – we should be focusing on providing detailed context around our users and their expectations. Engineering and designing features should be left to engineers and designers. It’s their role after all.

To close off, always keep the market, your users and customers, at the top of your mind. They are the ones who will use your product and they will determine the success of your product. Their opinions matter greatly. Yours – definitely not as much.

My name is Luke. I’m a Product Manager, I’m short and I have curly hair. You guessed it, that’s where the name of this blog came from.

I have never given blogging much thought before these days, however, I’ve really come to appreciate how helpful sharing learnings and listening to others’ experiences can be in growing one’s professional career. This will be the main objective of my blog. I would like to share my experiences and learnings in my role as a product manager, which I hope will be helpful to some of you folks who are going through similar experiences.

It will not be the most perfectly penned blog. I will not guarantee flawless opinions. But I will definitely do my best to keep this blog updated with interesting new things that I learn in the great world of product.

On the flip side, I also love hearing about other people’s learnings. So please do feel free to leave comments with your opinions on my posts, or get in touch. I’ll be happy to discuss product management in more detail with anyone who reaches out.

Where I come from

I was born and bred in tiny Malta. I studied IT at the University of Malta and later, Economics & Finance on a remote programme with the London School of Economics. My first role was in software development. I then moved on to do data migrations, large-scale enterprise system implementations, project management and I’ve now recently moved into the world of product management.

I’m currently a Product Manager at an awesome company called Hotjar.

Get in touch

Here’s my LinkedIn profile – feel free to connect and/or message me.

Twitter handle: shortcurlyprod