Hey there, product development enthusiast!

Welcome to the first edition of the Tech Impact Uplift newsletter! Just in time for some pleasurable read over the holidays. I am super thankful that you subscribed and are here with me. 😊 

The first topic we discuss will be how to prioritise.

Let’s dive right in!

Why is Prioritisation Important?

Ideas are cheap and there is always an abundance of them. But the most important bottleneck in product development is our capacity to work on these ideas.

Therefore, we need to be very mindful about what we spend this capacity on.

There are several prioritisation methodologies out there, but one is by far the most (over-) hyped: Objectives and Key Results (OKRs).

The OKR Methodology

OKRs consist of two main concepts:

• Objectives: These should be aspirational goals like “We expand into a new customer segment”.

• Key Results: Belong to an Objective and should be measurable steps to reach these goals, like “We acquire X new customers from that segment, who use our product A at least 3 times.”

These Objectives and Key Results should exist on every organisational level of the company and cascade down. I. e. company OKRs should be supported by department OKRs, which in turn should be paid into by unit OKRs.

The creation of OKRs should ideally be a mixture of a top-down approach, where overarching business direction is provided, and bottom-up input, which should provide ideas that support this direction.

Process

OKRs are defined and worked on for a pre-defined timeframe, typically 3 months. The progress is ideally reviewed during the cycle, but latest at the end. Based on that, the next cycle is planned with renewed OKRs.

Through that, goals should be clear, results measurable, and teams aligned on common goals. What could go wrong?

Shortcomings of OKRs

There are a few things that I have seen over and over going wrong with OKRs.

Too Costly

Planning OKRs can be a logistical nightmare.

As organisational units plan towards overarching goals, e.g. "We expand into a new customer segment", each unit can have very different ideas on how to support that. In any non-trivial organisation, they will most likely need support from others.

So before each cycle, all units spend tons of time preparing, pitching, and aligning their ideas with others. (This mostly happens when you plan for projects rather than for goals, which you shouldn’t.) I have seen cases where the whole company was busy for two weeks just preparing the next OKRs.

No Focus

What I have also seen a lot is focus getting lost during the OKR cycle.

Let’s imagine a unit has defined own OKRs and works on those. But other orgs might need their support for their OKRs. So they approach them for help, very often with the argument “But it’s in the OKRs - you need to help!”.

The bigger the company, the more such dependencies, the more requests on each organisational unit and: the less focus!

Likewise, planning for 6 Objectives with 3-5 Key Results each is just too much.

One example I’ve seen was a company, where all walls of one room were completely covered by OKRs of all teams. Do you think this provides focus?

Not Agile

Theoretically, OKRs look very agile:

But if you think about it, they are not.

First, which initiative takes 3 months? Rarely any do.

What I have seen happen a lot, is that after the 3 months, the initiatives got dropped. Often, because another stakeholder did not get their request added to the OKRs in the previous cycle, so for the next “we really need to do something for them”.

The result: Products are not optimised, accordingly, product-market fit is not reached. Long-term innovation is hampered in favor of short-term thinking (or project thinking vs. product thinking).

This might look agile, but is de-facto a series of mini-waterfalls of fixed duration.

How to Do Better

Of course, you can do better even with OKRs. Here are my tips on that. 🚀 

1. Strictly limit the amount of objectives and key results that each unit should define from the beginning (3 sounds reasonable but depends on many factors).

2. Have somebody own each of them from the beginning to coordinate dependencies early on.

3. Plan for max. 60% of an org’s capacity to leave room for operational business, unplanned support, unplanned complexity, maintenance etc.

4. Don’t plan projects, plan goals!

5. Objectives should be long-lasting and stable over several cycles until they are reached (or consciously deprioritised).

What OKRs Cannot Do

Now we talked about how to do OKRs in a better way.

Yet, I often experience severe misconceptions about what OKRs can do. So let me clarify this as well.

OKRs do not replace:

• a strategy

• a product development process

• a design and planning process

• a conflict resolution process

Also, by their nature, they cannot provide the refinement of a topic or the solution design. OKRs are about the “What”, not the “How”. The solution design can only follow later.

Because of this, OKRs also cannot provide alignment between teams upfront. Why not? As the solution design only comes later, the dependencies of that solution will also only become known by then.

Wrap-Up

I hope you got a good feeling about what all can go wrong with using OKRs. This does not mean you should not use them at all.

You need to prioritise as otherwise your organisation will go into all different directions and you will not spend your delivery capacity efficiently. The tips provided should help with that.

But there is alternatives to OKRs, which I will cover in the next newsletter. So stay tuned!

I am keen to hear your experience with OKRs or your thoughts on this newsletter.

And now - I wish you Happy Holidays and a good start into the New Year. 🎄I hope you’ll have a relaxing time with your loved ones, as I am sure 2025 will come soon enough with its challenges.

Jan’s Knowledge Nuggets 💡 

In this section I share knowledge nuggets that will further help you to increase the impact of your tech organisation.

• Free Webinar “The Strategy Habit”: Markus Andrezak is a master when it comes to strategy. On January 9th he will share his pragmatic approach to do strategy in a practical and impactful way. I already registered and look forward to the session.

• 9 key take-aways on User Research: The wonderful Nikki Anderson is a legend in the field of User Research. She condensed her 10,000 hours of practical experience into 9 key lessons everyone in product development should be aware of.

• Free courses to learn AI: Paul Storm shared a valuable overview of free AI learning courses by Harvard, Google, OpenAI and many more. From prompt engineering to programming to ethics of AI.