Alignment through OKR’s and Hypotheses

When you start to scale and have multiple products and/or teams, alignment becomes paramount. The general trap is to try and control things to stop misalignment from ever happening by adding many layers of bureaucracy — or as I like to call “forced-alignment”. This stifles creativity, does very little to keep your people motivated and usually degrades team velocity.

But there is another way, a way to keep teams and product aligned whilst still allowing for the speed of autonomy.

Two tools that are often my go-to for helping Product Leaders and organisations I work with achieve this, are OKRs and Hypothesis Driven Development — both are relatively simple and complement each other, but most importantly they scale easily!

I’ll walk through how to get this going in your organisation but first, a quick 101 on OKRs and Hypothesis Driven Development for those who aren’t familiar.

“OKR” 101

OKR is an acronym for Objectives, Key Results. Its origins can be traced back to Peter Drucker in 1954 when he invented MBO (Management by Objectives). MBO was then largely used by Intel and later became widespread and now commonly known as OKRs through Google by John Doerr — an ex-Intel employee and early advisor to the Google founders, Larry Page and Sergey Brin.

As the name suggests an OKR is broken down into:

Objective — the goal we wish to achieve, and;
The key results we expect the objective to give us. General rule of thumb is to have no more than five key results per objective.

OKRs are designed to describe an outcome — the impact you wish to achieve but not the how. A common mistake is describing an output rather than an outcome as your OKR — something like “Launch app x” is not an OKR, it’s not the objective — it’s an output, rather launching app x to achieve blah, that’s your outcome.

🔥Pro tip #1: If you ever find yourself in this trap, simply ask “why?” — why are we launching app x? What benefit are we expecting to see? The answers to these questions are likely be the outcome you’re trying to achieve.

The second crucial part of an OKR is the key result you expect to see — in other words, how are you going to measure the outcome? Fluffy statements like “drive customer engagement” are neither useful nor measurable. Key results need to be measurable like “increase retention by 5%” — think SMART goals.

OKRs can be used at all levels — they can be high level larger long-running, lagging indicators or low level tactical, leading indicators. Often in Product-led organisations, OKRs are leverage across all levels, from high level company OKRs to low level Product development OKRs.

Hypothesis Driven Development 101

In response to the increasingly turbulent environment that product development has become today saw the rise of approaches such as Lean Startup and rapid experimentation. A natural extension of this is the idea of replacing the items in your product backlog with experiments rather than user stories — this has become known as Hypothesis Driven Development.

Unlike OKRs, I don’t know it’s origins (although I would love to find out so please share if you do know!), Hypothesis Driven Development has become a popular practice in product development today.

The Hypothesis framework which is commonly used is relatively simple. At a core level it consists of two statements, one which is the experiment that you wish to try (or “bet” as I like to call it) and second is the outcome you expect it to make and more importantly how you are going to measure its impact.

We believe that ____________________
We’ll know we have succeeded when we see ____________________

A more detailed version commonly used separates the outcome from the measurement and includes a targeted customer (this is my preferred version).

We believe that ____________________
For ____________________
Will result in ____________________
We’ll know we have succeeded when we see ____________________

I’m personally a big fan of Hypothesis Driven Development — the idea that everything is an experiment, diving into the unknown, trying something and hoping it will achieve an intended and measurable outcome, resonates well with me. Another reason for my love of Hypotheses is the way they help combat the classic feature factory mindset — I’m actually a big fan of ditching user stories altogether and to have the majority of my backlog written as Hypotheses — again this forces the experimentation and outcome mindset rather than just blindly building stuff.

Just like OKRs, the Hypotheses framework is agnostic to the size of work and for that reason, it too scales very well — you can have large experiments or extremely small ones, I may even have a larger higher-level Hypothesis which gets broken down into smaller experiments (hypotheses).

Bringing them together

As mentioned before, OKRs and Hypotheses work quite nicely together this is because they are both focused on outcomes and cold hard metrics around said outcomes. The only key differentiator between them really is that OKR’s are deliberately solution agnostic whereas Hypotheses aren’t.

OKR’s are deliberately solution agnostic to allow the freedom for the “how” part — OKR’s don’t care how you achieve the objective, they just want the objective met. This is where Hypotheses come in.

Similarly to OKRs, Hypotheses also illustrate the intended outcome and how we are going to measure it but it also has a leading statement — the experiment — or in layman’s terms, the “what” we are going to do in hope that it gives us a particular outcome. This bridges the gap nicely between the outcome (we want to achieve) and what we are going to try in order to achieve it (the “how”).

So where do you start?

A Product point of view

Like with anything I often start with the vision — the end goal, where are we heading and why.

The next question to ask yourself as a Product Manager is “how am I going to measure progress towards the vision? how will I know I am swimming in the right direction or not?” — these are your top level OKRs for your product. They will change but for now, they are your product-compass.

🔥Pro tip #2: The fewer OKRs the better (I like no more than 3 but am still flexible on that, 4 sure, that’s ok, 5 starting to push it but if it makes sense ok). Key here is to provide focus, more than 5 and you start to lose focus.
🔥Pro tip #3: Consider diversity in your metrics on your OKRs — i.e. you don’t want to increase sign-up conversion at the detriment of retention — beware of tunnel vision!

From there I will start to do experiments, or “bets” as I like to call them. This is usually informed by product discovery but are essentially the first lot of experiments you wish to perform in order to help bring the product closer to your vision.

`Vision > OKRs > Hypothesis > User Stories/Smaller Hypotheses`

An important thing to note is that this doesn’t supersede discovery, rather the contrary, discovery should be informing your bets.

Typically I will still have an opportunity backlog for discovery which will still contain potentially vague opportunities or things that are further down the roadmap. This means I may not yet have the information needed to turn them into a hypothesis just yet. This means your roadmap will likely have planned bets in the near-term and “fuzzy” opportunities still in the far-term — all still aligned to an OKR.

`Roadmap, hypotheses in the near term but further out are opportunities/problem spaces to explore`

Over time through discovery, you will gain more information and likely turn those opportunities into hypotheses but be cautious of doing this too preemptively — don’t forget to validate and understand what problems you are solving before trying to solve them!

`Often we can’t jump straight to a Hypothesis (nor should we) we need to explore opportunities, validate them before we can truely understand what kind of experiment we want to do.`

Scale to Product Group point of view

`Product Group will also have a vision and OKRs — each Product will align and have autonomy in how they decide to contribute and help realise the groups OKR/Vision`

As a Group Product Manager, you will usually have a vision of your own for the Product Group. Typically the products within a group are somewhat aligned hence why it makes sense to group them and have someone leading that group. Often when I work with Group Product Managers I like to remind them that their product craft doesn’t stop just because they no longer have a specific product to manage, rather they now have a portfolio of products which is more complex but the same skills still apply —sometimes you’ve just got to get creative with how.

Having a shared vision and measurable outcomes (whether they are expressed in OKRs or not) is a powerful way for creating alignment across the multiple teams and products — and I would argue is fundamental at this level. Without it and there is the potential for the multiple products and teams to diverge.

The devil is often in the details with how you maintain alignment. The key is to provide direction and boundaries, not to cascade solutions or micro-manage (I often say to leaders I coach, “facilitate don’t dictate”).

This means focusing on outcomes and providing alignment rather than giving orders to the product teams. It’s pertinent that each Product Manager and product team still have the autonomy to decide how they are going to contribute towards their group’s OKR and vision.

🔥Pro tip #4: You can still have “bets” at this level (and higher). Typically at this level you are thinking slightly bigger picture, across the product group this means your “bets” are usually linked to investment mix and things like exploring new opportunities, new markets, new product ideas, etc — often such bets result in changes in team shape — “do I spin up a new team to explore this opportunity? or refocus an existing team? Do I sunset a product or build a new one?” — again these are not orders cascading down and should ideally be created collaboratively with your team.

Scale again, Chief Product Officer point of view

If you’re big enough it may warrant having multiple product groups. My general advice around scaling is always, “less is more” — in other words, only scale when absolutely necessary.

A general rule of thumb for me is Dunbar’s number — Dunbar’s number is a cognitive limitation of where an individual can maintain relationships and continue to feel a sense of purpose and belonging. Although the exact number varies depending on the context, a widely used number is ~150 people.

Applying this to scaling when the total number of people across your product teams approaches or exceeded ~150 people in size it may be better for numerous reasons to split them into two or more Product Groups — as a general rule of thumb, this is the limit I work within and by no means a hard and fast rule. Depending on your context, your products, and company size it may make sense to have multiple Product Groups of ~30 people, again nothing wrong with this but its often important, especially as you scale the be mindful of Dunbar’s number.

`Company vision and direction <> Product Group <> Individual Products — think in terms of supporting networks and things being nested. Each “layer” supports both upwards and down.`

Again no different than at the Product Group level — OKRs are outcomes and “the why” and similarly, each Product Group has the autonomy to decide how they are going to contribute to the organisations visions and objectives and so forth.

🔥Pro tip #5: OKRs and Hypotheses should correlate, not cascade down. They are common goal posts to keep teams loosely aligned — not for telling the teams what to do. Rather each team, group, department, tribe (whatever you have) are free to decide how they are going to help attribute towards the higher goal, or not if they have a great reason why.
🔥Pro tip #6: Equally things don’t cascading up either — a common anti-pattern I see is the need for things to go up the chain for someone’s “blessing” — like the Head of Product needs to “prioritise it” or give the thumbs up. There should be no need to getting “someone’s blessing” this only creates a dependency and bottleneck, rather teams should be empowered and trusted to make their own decisions.
🔥Pro tip #7: Split your work into past, present and future buckets.

✨Bonus Tips for using OKRs and Hypotheses for the first time✨

The number one area I see people struggle with is the measurement part. Either a) they haven’t been measuring impact or outcomes before so they have no idea of current value, where to start or whether how to even obtain such metric, or b) they get way too caught up with coming up with the worlds perfect metric.

So here’s some quick advice to help avoid the common traps for those OKR and Hypothesis virgins out there:

Just start somewhere — if you don’t know where to start just pick a metric and start figuring out a way to measure it, one by one you’ll start to build out your metric base. And the best part is if that metric “wasn’t the right metric”, that’s ok, you’ve now learned something and you can try something else — chances are that metric, which by the way you are now measuring, will be useful in the future.
Don’t have too many OKRs — less is more — ideally, I look to have no more than 3 OKRs at the vision/top level. If I was to use them in a roadmap, I would then look to have only one per month/quarter or whatever cycle I am working too.
Don’t pick too many metrics either — again, less is more! I generally work off the same rule-of-thumb as for OKRs and go for no more than 3 metrics/key results for both OKRs and Hypotheses — ideally I would want to have only one but I know that one doesn’t always make sense.
Focus on making your metrics SMART goals — which stand for specific, measurable (obviously), attainable, realistic and time-bound.
Don’t get too caught up on getting it perfect or right to begin with — in a similar vein to the first tip, once you’ve done your experiment if your measurement part is off you will know really quickly when you start to get feedback. No need to worry, simply pivot your metric and measure something else. The more practice and experience you get, the better your metrics will get over time.
Think about leading vs lagging indicators — it can be useful to think about OKRs as more lagging indicators or ones which will see the needle move over a much longer time period whereas, since your Hypothesis are your experiments to meet the OKR, their metrics are often leading indicators, as they require a much shorter feedback loop.
OKRs and Hypotheses should flow both top-down and bottom-up. It is important that neither of these cascades down — they’re not there to tell teams what to do! Rather they’re a tool for creating the conditions for aligned autonomy. What do I mean by that? Teams should have the autonomy to decide how they are going to contribute to a higher OKR/Hypothesis. Think of them as a guiding light in the distance, designed to keep everyone rowing in the same direction whilst allowing the autonomy and freedom to forge their own paths there.
Be collaborative and create both together — don’t be a dictator and prescribe what OKRs or Hypothesis people should do rather involved them in the journey and co-create them together — many minds are better than one.

Need help with scaling your product or business? I can help in 4 ways::

Level up your craft with self-paced deep dive courses, FREE events and videos on YouTube, templates, and guides on Product Pathways.
1:1 Coaching/Mentoring: I help product people and founders overcome challenges through 1-hour virtual sessions.
Consulting and Advisory: I help companies drive impact though better product practices.
Private Workshops and Training: I run practical workshops and training courses for product teams globally. Get in touch to talk about your unique training needs.