Had a few chats and thought quite a bit about the definitions of product and service, mostly on the assumption that they are different things. In the past, products and services definitely had different definitions, but nowadays the differences are often hairsplitting. So, until anyone can provide a robust definition for how products and services are different things, I’m saying they are the same thing seen from different perspectives.
Product or service
Who defines things in organisations matters. In my experience, if service designers do the defining, they tend to create a hierarchy where ‘the service’ is the big thing that spans the entire user experience and ‘products’ are the pieces of tech a user interacts with at each step as they go through the service. This implicit organisational power dynamic (kind of Conway’s Law) and misunderstanding that product doesn’t equate to tech, doesn’t lead to good, equitable, or useful definitions.
I’ve written before about how I think product managers and service designers can work together, so in a world where a service and a product are mostly the same thing, it doesn’t make sense for these roles to have mutually exclusive responsibilities, but instead to have complimentary perspectives that define and create better products/services.
Product or project
A product is a product if an organisation chooses to treat it as a product, and the best way to decide is to look at the problems it’s tackling. If the problems are well-defined, stable, and have predictable solutions, you don’t need product thinking or the skills a product team brings in tackle uncertain problems, and so don’t treat it as a product, treat it as a project. If the problems are new, unknown and the potential solutions are uncertain, then a product team with the skills to apply product thinking are a good way to tackle those problems, and so the organisation should treat those problems as a product.
Product or tech implementation
Differentiating between a product and technology implementation is much easier. If you’re working with hypotheses, discovering user problems, and delivering solutions iteratively, then you’re probably treating the work as a product. If you’re working with an accepted business case, stakeholder requirements and delivering features, then you’re probably implementing some tech.
Either way is fine, the important thing is to pick the right approach.
The future of product management
There have been so many boringly mediocre social posts about the future of product management being all about AI this year. I mean, look around. If that’s the best future you can envision, you clearly aren’t paying attention and probably shouldn’t be working in a role that involves having a wide perspective.
If product management is about navigating uncertainty and ambiguity, then the future of product management should consider the largest and most pressing cause of uncertainty; the state of the global economy (how it’s affecting organisations and what it means for the value product managers provide), climate crisis (how product management can help organisations stay within planetary and societal boundaries), the aging population, wars, energy and food insecurity, etc., etc. All of these create a permacrisis that should inform the future of product management.
And if anyone thinks that such big things are outside the scope of product managers, consider that how we think about disruptive innovation and growth now is a result of Schumpeter, Keynes, etc., and economic policies from the 1930’s that attempted to tackle the great depression and effects of World War I.
Cross-functional teams
I’ve explored a few different thoughts about cross-functional teams.
Truly cross-functional teams need wider remit
Truly cross-functional teams need the influence, authority and remit to affect goals, people, process, structure, technology and products/services. This idea comes from reading more about socio-technical theory, which introduced the idea of cross-functional teams and basically says you can’t treat the people side of an organisation differently than the technology side, they have to be designed to work together.
Unfortunately, most cross-functional teams usually only have the remit to make changes to tech, not as aspects of a socio-technical organisation. Maybe it’s a problem of focusing more on the ‘team’ part of ‘cross-functional teams’ and less on the ‘cross-functional’ part that makes us think it only needs to be within the boundaries of the team. Or maybe it’s another case of an idea that was designed to disrupt the status quo being co-opted into reinforcing existing power structures. Who knows.
Cross-functional teams should have regular contact with users
Internet-era cross-functional product teams work in an open system that is constantly changing and they have to respond to those changes. Industrial-era teams work in a closed system, meaning they aren’t affected by things changing out there in the world. One of the best ways for cross-functional product teams to know about changes is to have regular contact people who’s behaviour shows the change. Things like insight reports on customer behaviour, whilst useful, distance the team from the changes users are going through. They make an open system behave like a closed system, which reduces a team’s ability to respond to change and achieve outcomes for users.
The problem with professions
But cross-functional teams aren’t perfect. Professions exist to tackle a gap created by the move to cross-functional teams, but they in turn create a coherence problem for people facing different approaches that result. There must be a better way to provide a complete employee experience within cross-functional teams.
Decision stack
Spent some time understanding and critiquing the decision stack. The stack has Vision at the top and Strategy the second step down. Strategy breaks out into a number of Objectives, each of which in turn break down into Opportunities to explore to find ways to achieve the Objectives. At the bottom of the stack is Principles.
The different layers interact in two ways; the how and the why. How flows downwards, so Strategy says how to achieve the Vision and Objectives show how to achieve the Strategy. Why goes upwards, so Opportunities are selected because of the Objectives, which were chosen because of the Strategy.
The decision stack is a useful way to bring more coherence to the often vague and amorphous product work, but like every other framework, it says nothing about the environment necessary to make it a success.
Onto some thoughts from this year…
Logic model
A product logic model explains inputs, activities, outputs, outcomes and impact with if/then reasoning to show how changing one thing affects another. It depicts the hypotheses product manager’s use in their work, for example, how adding a different output (feature) is expected to affect an outcomes (user behaviour). Should the logic model be in the decision stack, and if so where?
I think it should, and goes either between vision and strategy, if we want to order things by longevity, or between opportunities and principles, if we think it’s more important to show that it’s foundational and supporting of how all the things above will work.
Whether we show the logic model using north star metrics or impact mapping (a favourite of mine) or theory of change, the point is to help understand and show others which aspects of the product that are within our ability to change and how the change will lead to what outcomes and impact. It shows whether our Objectives are the right ones to be working on, it validates our Strategy, it’s the feedback that tells us if we’re achieving our vision.
Principles
Principles are funny things. They can be really useful in solid decision-making or be useless talk about nothing much.
If you think of your principles as foundational, then you’ll be deontological about them. That means you consider them universally applicable rules or guiding boundaries that you don’t cross. Whereas if your principles are nice ideas that you might talk about occasionally, then you’re more utilitarian about them. You think that the ends justify the means, so you apply a principle when it suits and not when it doesn’t.
Given that centuries of moral philosophy hasn’t been able to decide between the two, I think we can accept that neither of these approaches is wrong, and the placing principles at the bottom of the stack doesn’t give us an answer about how to choose. It visually suggests either approach; a foundation to build upon (deontological) or less important than the opportunities above them (utilitarian).
I guess the interplay between applying universally applicable rules or using principles when they suit is another of those things product managers juggle.
Product ontology
I tried to think about the ontology and epistemology of product thinking to give it some robust theoretical foundations. I didn’t get very far other than the idea that product work might be better approached as constructivist rather than positivist.
User research is constructivist
I think user research uses a constructivist ontology. So, rather than trying to reveal an objective reality, it seeks to show how people create and interpret their own reality. I’ve never heard user researchers talk about this (except this guy) or even cover an ontological position in a research report. That seems a bit of a shame as it sets out a position that counters the criticism of user research not being robust enough because of population size.
Product attribution
Product attribution models usually take a positivist ontological stance, assuming there is a single objective truth to be revealed and show how this feature lead to that increase in metrics. But, given that product work is about affecting user behaviour, and an outcome is a change in user behaviour, wouldn’t a constructivist ontology make more sense? It also fits better with user research. I need to think about what a constructivist log model and metrics would look like, but that’s for next year.
Things I changed my mind about
Talking to people
I’m a big believer in asynchronous communications, and talking to people never comes easy for me, but I pushed myself to talk more to team members and to meet people outside the org. Now I think conversation is the unit of culture change. The more people talk to each other, the more knowledge is shared. And in modern knowledge work, sharing knowledge is a competitive advantage.
AI
I used to think GenAI was going to lead to big changes in people’s lives and new business models for organisations. Now I think it’ll have a similar scale of impact on content creation as email did on communication, and that in most cases it probably isn’t worth the environmental impact. Machine learning analysis, on the other hand, has much more potential (if you have the data).
OKRs
I used to think OKRs were a rubbish. Now I think they’re a good technique for teams to align with strategy and a tool for organisational change. I even did a short intro training session for some colleagues.
I have three longstanding goals that I’ve used for many years to focus my roadmap. Here are some of the things I did this year to contribute to my goals.
Contributing to digital transformation for social good
Work
Joined the Open University as a lead product manager.
Went to UKEduCamp.
Joined the Product Leader’s group.
Continually developing my knowledge, skills and practice
Reading
Books I read:
Wiring the winning organisation
The service organisation
The agile manager
Design for how people think
Learning
I didn’t do much formal learning this year but learned and practiced a lot about working with people. I’m really grateful to those who helped me learn.
Writing
764 posts (including 52 weeknotes and 25 blog posts, the rest were notes and links).
How to decide if you’re building a product or building a technology system:
Are you creating something that will validate hypotheses about how to enable the organisation to move in an agreed direction?
Are you deciding what to build based on dedicated discovery work to understand what problems users are facing?
Are you delivering small, frequent, reliable releases to users and getting feedback on whether you’re solving their problems?
If the answers are No, then you aren’t building a product, you’re implementing technology. There’s nothing wrong with that. Implementing technology is necessary, but it’s better to be clear about what you’re doing and why, and treat it accordingly.
I’ve been thinking about how mental models relate to definitions (like ‘product’) which relate to artefacts (like roadmaps). It’s confusing and dissonance-creating to define a product one way and then create a roadmap in a different way. So, if an organisation defines it’s products as pieces of tech, then an outcomes-based roadmap is going to make no sense. Lining up artefacts, to definitions, to mental models might help create more coherence and understanding. So, I thought I’d start with mental model based definitions of products.
By tech
This is the usual thinking in lots of organisations: a piece of tech equals a product. ¯\(ツ)/¯
Pros – Intuitive mental model because it’s fairly easy to see the boundaries of the tech and what that means for user experience, etc. Aligns the capability of the tech with the expertise of those working on it. Features roadmap makes sense because it expresses changes to the tech.
Cons – It makes it almost impossible for a product team to be outcome-focused as a user hardly achieves their outcomes by interacting with a single piece of tech. It falls into Conway’s law, which means users across multiple products often don’t get the consistent experience they’d expect when going from one tech to another.
By outcome
A product is all the things necessary for a user to achieve an outcome, including tech, team capabilities, policies, processes, etc.
Pros – Most user focused way to think about a product. Offers greater flexibility in how to achieve an outcome as a change could be in policy, user interface, etc.
Cons – Limits how to structure teams to work on a product as there aren’t going to be that many outcomes. Measuring outcomes is hard, so teams have to rely on proxy measures.
By activity
I’m not sure activity is the right word but it fits well enough. I mean product managers being responsible for things users do like Payment, Notifications, Search or Onboarding.
Pros – Allows for a great deal of flexibility in how the activities are defined which makes it easier to add, merge and disband teams aligned with activities.
Cons – It can be a bit feature-led, which means teams need to communicate and coordinate to create a coherent product experience.
By goal
The goals would usually be metrics based, e.g., Increasing Daily Active Users or improving retention.
Pros – Product teams can experiment and implement across any tech or user experience to achieve their goal.
Cons – Requires coordination across teams to prevent one team from negatively impacting another team’s goal.
It’s easy to get confused about prioritisation. We often use that word when we mean other things. We should mean ordering things by relative importance, but sometimes we also mean the sequencing of those things. One word, used to mean different things to different people. And that’s where it causes confusion.
I think it’s clearer to separate how important something is from when you’re going to do it. And to make that separation even cleaner, we could prioritise the problems we want to tackle, and sequence the solutions we want to create.
Prioritising problems
Like all good product managers, we want to start by understanding the problems we want to tackle or opportunities we want to go after.
We want to know which are the most important problems, and to figure that out we might look at how many people have the problem, how affected they are, how much they need a new solution, etc. All this information helps us pick which problems to tackle and which not to. And that’s the point of prioritisation; choosing what to work on, not when to work on it. It’s the logic of ‘this, not that’, whereas sequencing is ‘this, then that’.
Sequencing solutions
Once we have the problems prioritised by importance, we can then sequence the solutions.
We want to sequence the solutions separately from prioritising the problems because there are different factors to consider. Now we need to think about team capacity, technical skills, dependencies on other systems, budgets and other organisational constraints, etc. These things don’t affect what problems we’ve prioritised but they make a difference to when we’ll be able to tackle them.
By thinking about problems and solutions differently we can avoid confusing how important a problem is from when we want to solve it. It helps us make better decisions about whether to tackle more important problems sooner or when to solve easier problems.
Delivery manager, project manager and scrum master are three quite distinct roles, but with a lot in common. Although each role is a valuable in it’s own right, for either of the roles to provide value, and for a person in a role to be successful, it’s important that the right role is selected for the circumstances. Exploring the commonalities and differences can help with matching the role to the working environment.
What the roles have in common
Delivery manager, project manager and scrum master are all non-authoritative. They don’t direct people or assign work. They exist to support teams to focus on the value-driving work by taking on the meta-work – the work that makes work possible – including things like planning, coaching and reporting. With so much overlap between the three, a Venn diagram helps us see some of the activities and responsibilities the roles take on.
What makes the roles unique
Delivery manager
Purpose: Enabling team health.
Responsibility: Creating an enabling environment by removing impediments, facilitation and coaching.
Method: Agnostic. Delivery management doesn’t follow any specific methodologies and can work equally well whatever methodology a team is using.
Best environment: Cross-functional teams tackling ambiguous problems.
Success measures: Individual’s purpose, autonomy and mastery.
Project manager
Purpose: Monitoring unplanned deviations.
Responsibility: Managing the day-to-day progress of a project to ensure it follows the plan.
Method: Predictive. Project methodologies (sometimes called waterfall) that involve upfront planning, reporting against the plan, and triggering corrective actions.
Best environment: Established project teams working on delivering known solutions.
Responsibility: Establishing Scrum and helping the team inspect and adapt their practice to become more effective.
Method: Adaptive, and Scrum specifically.
Best environment: Scrum team.
Success measures: Team velocity, throughput, sprint burndown.
Which role fits where
A delivery manager fits best as a part of a multi-disciplinary team tackling novel and ambiguous problems, where the organisational environment contains challenges for the team, and the team is open to being supported to tackling the challenges and removing impediments.
A project manager fits well in a team and organisation that is working on things that can be well-defined upfront, usually because they’ve been done many times before. Although project management has started to adopt adaptive methodologies, it still works best with pre-defined scope, budget and schedule.
A scrum master only works in a scrum team. That’s the only setting where a scrum master can be successful. Scrum master isn’t a profession in the same way delivery management and project management are, in that there is no career progression path of scrum master, senior scrum master, head of scrum mastery.
Matt Ballantine mentioned lots of little theories. Little theories are a great way of holding onto a questions while you look for signals to prove or disprove them, so I thought I’d make a note of some of mine.
The number of conversations leaders have with people below their pay grade and outside their reporting line is a leading indicator of organisational culture change.
Organisational self-image explains culture better than the behaviours of individuals.
Four day working weeks reverses Brook’s Law. It isn’t (only) less time at work that creates the benefits, it’s that everyone spending less time reduces the coordination challenge by 20% which is a massive efficiency/effectiveness gain.
Product managers should champion user needs within the team and within the organisation. They aren’t the only ones, of course, everyone should, but product managers can bring together multiple perspectives on meeting user needs because they don’t represent a specialist discipline.
User needs can be general and specific. So, whilst the specific user needs might be for a user researcher to discover and champion, it’s for a product manager to champion the general user needs. These are the kinds of things user’s need but a user researcher wouldn’t find out; things like making a product accessibility, making it work on various devices, how secure their account should be, etc., etc. In old money, they used to call these Non Functional Requirements, but for modern, user-centred product teams that term is too loaded with tech-first organisational needs, so better that we remind ourselves that it’s our users that need these things by calling them user needs.
Because product managers often think at scale, these general user needs have to be expressed in more generalisable terms. This is where standards, concepts and theories such as cognitive load theory, WCAG, COM-B behaviour change model, OWASP top ten, etc., become an important part of meeting those general user needs.
Championing these general user needs means working with the team to internalise them to the point where they are a given. When the team designs and builds accessibility, security, etc., in from the start, then they are meeting those general user needs. Then they are being user-centred. Then the product manager knows they’ve done the job of championing user needs.
George Stephenson pioneered a standard gauge of 4 feet 8.5 inches for railways with the Liverpool & Manchester line in 1829. In 1845, the Royal Commissioner recommended the standard gauge, and in 1846, the British Parliament passed a bill requiring all railroads to use standard rails in the future. Before that, railway lines had many different widths, but as the standard was exported from Britain to Europe and the United States it allowed railways to work as interconnected networks rather than individual lines.
Standardising the track gauge made train cars interchangeable and made railways interoperable. This brought commercial benefit to railway manufacturers and convenience to passengers. It’s why you can get a single train from St Pancras to Marseille or travel by train from New York City to San Francisco, if you’re into that sort of thing.
Although railways standardised track gauge, they didn’t standardise engine design. Between the 1820’s and WWII, steam engines increased rapidly in size and power. Being able to innovate led to experiments with stronger materials and new technologies, better cylinder design allowed for more efficient fuel usage and improvements in lubrication which increased running time. Without innovation and improvement, it might never have become viable for trains to travel such long distances to realise the benefits of interoperability.
So here’s the lesson: standardise where interoperability is required, otherwise optimise for innovation.
We should apply that same lesson to product management and beware of standardising the role in ways that prevents innovation. Product management is a highly contextual role and the demands organisations are placing on it are changing too quickly for it to become standardised.
However, organisations, sometimes unthinkingly, default to standardising things on the assumption that it makes them more efficient. If everyone works in the same way and uses the same tools, the assumption goes, then their outputs will be the same, which is more efficient. This might have been true when manufacturing steam trains, but it isn’t when tackling complex problems. As product manager KP Frahm, once told me, “Get effective first, then efficient. If you get efficient first, you’ll never get to be effective.”
This is the problem with product management capability frameworks, role-based skill descriptions, and standardised levels for what is expected of product managers; for organisations wanting to improve their product function – they seem like a good idea. They seek to standardise the knowledge and skills expected of product managers, which seems like it should improve the quality of product management. But those frameworks are built on the idea of interoperable product managers that can fit into a product team in exactly the same way as the product manager leaving the team, and carry on working in the same way with minimal disruption. Interoperability is great for physical systems like railway tracks and for digital systems like railway timetables. Without the ISO 8601 international standard allowing any computer anywhere in the world to exchange date and time-related data with any other computer, you’d probably miss that train to Marseille. But human beings aren’t like that. They are unique. And trying to make them interoperable is a bad idea.
The lesson of the railways is true for product management. Making choices about what to standardise and, just as importantly, what not to standardise, is important for optimising performance of an entire system. A product management function needs to have some things standardised, where there is a need for interoperability, but product managers need to have non-standardised freedom to respond to change and innovate in how they work. Without this, product managers will not be able to manage products, they’ll simply be building the same railway as everyone else.
There are better ways to improve the quality of product management in an organisation. There are ways that focus on effectiveness over efficiency, ways that allow product managers to develop areas of specialist knowledge in economics or payment systems or behaviour change techniques or network effects or marketing, ways to support and coach product managers to lean into their uniqueness.
No two product managers should be the same, and they shouldn’t develop the same product in the same way. If they did, what would be the point of product managers? The point should be for each product manager to bring their own knowledge, skills and experience to their role and use them to tackle complex problems in unique and innovative ways. The point should be for organisations to maximise innovation in product management as a competitive advantage. The point should be for the discipline of product management to evolve at pace in a changing world.
A short introductory session to Objectives and Key Results.
What does OKRs stand for?
Orca’s Keep Rollin’ – watch out for those aquatic mammal gangstas.
Organophosphate Keratinization Roentgenography – I don’t even know what that is.
OK, Roger – Yeah, whatever, move on.
Or is it Objectives & Key Results?
Yep, you guessed it, OKRs stands for Objectives and Key Results. So if you’re here for the talk on Organophosphate Keratinization Roentgenography, you’re in the wrong meeting.
Objectives & Key Results
OKRs are a goal-setting method that enables teams to focus on what matters most, and make changes when they don’t yet know how to achieve the goal.
There are two important bits to remember there:
Focusing on what matters, and not knowing how you’ll achieve the goal.
This is what makes OKRs different to other goal-setting techniques, and what we’ll revisit a few times in this talk. OKRs aren’t about recording and tracking all the work your team is doing, only the most important work, the stuff that contributes to the big OU strategy and priorities.
And they aren’t about defining the work you’ll do upfront, when you know least about how you might achieve the goal you’ve set. You should figure out the work later, and be open to changing what work you do to achieve your objective.
History of OKRs
OKRs were introduced to Intel in the 1970s.
And Google adopted them in 1999, and has been using them ever since.
They are also used by LinkedIn, Twitter, Uber, Microsoft and thousands of other organisations around the world.
Why does this matter? So you know that OKRs aren’t some funky new fad. They have a long history, and have been developed in lots of organisations. Books have been written about OKRs. There are OKR conferences (mostly for people who don’t get out much). They’ve been shown to be a useful technique for aligning teams with what the leaders of an organisation are trying to achieve, but doing it in a way that recognises things change, we learn as we go, and we need to be able to adapt.
Why use OKRs?
Align priorities
We use OKRs at OU to help teams align their work with organisational strategy. In large organisations in particular, the day-to-day work of the teams can get disconnected from the bigger priorities of the organisation. OKRs give us a way to leapfrog over the hierarchy of the organisation and directly connect what the team is trying to achieve to what matters most for the organisation.
Have two-way conversations
OKRs provide a means for two-way conversations between teams and leaders about the priorities for the organisation and how the work the teams do contributes them. OKRs don’t work without those conversations and the shared understanding that comes from them.
Give teams decision-making autonomy
We want teams to make the decisions about what work will achieve the Objectives, after all you all are the experts in what you do. OKR’s do this by separating the Objectives from the work to achieve them.
Track the things that matter
And they focus on tracking the outcomes that matter to the organisation, not the deliverables which may or may not contribute to the goal.
What is an objective?
An Objective is an easy-to-remember, qualitative descriptions of what you want to achieve.
It’s that simple. It doesn’t need to be complicated. It doesn’t have metrics or timeframes, it doesn’t say who is responsible. It just needs to express the most important thing the team is working on in a way that anyone can get.
Example objectives
Improve the quality of leads contacting us
This is a pretty good example. It’s easy to see why it would be the most important thing a team is working on, but it does require a bit of specialist knowledge to know what leads are, and maybe what a quality lead is.
Increase revenue by 20% in 3 months
This is a pretty poor Objective. It’s too specific and includes measures. And, although challenging Objectives are good, it’s probably unachievable.
Grow email subscriber list
This is a good Objective. It’s short and easy to remember, easy to talk about with people who aren’t specialists, and easy to see what it’s important.
When writing Objectives, it’s best not to over think it, don’t try to cover every caveat or be super specific. It’s much more important to have an easy-to-remember description of what you’re trying to achieve.
What is a key result?
A Key Result is a specific, measurable metric that shows movement from what it is now to what you want it to be.
They are always quantitative and need data to report on that movement.
Example key results
Increase form submissions from 5% to 10%.
Pretty good, tells you what the form submission rate is now and where you want to get to. Could be a bit more specific about which forms.
Motivate employees to enhance customer service.
Isn’t measurable, doesn’t show how motivated employees are now or what the change is.
Decrease user journey drop-off at step 4 from 25% to 20%.
This is a good Key Result. It’s specific about where the change will happen, and the direction the change will go.
Have a go
Write an Objective and a Key Result. It can be about anything. Work. Personal life. World peace, if you want.
Try to make your Objective easily memorable description of what you want to achieve.
And make your Key Result specific, measurable, and that shows movement from how things are now to towards achieving the objective.
Here’s mine.
Objective: Run five miles without stopping.
Key result: Reduce the time between stops from every ten minutes to every twenty minutes.
What did you notice?
Writing OKRs is easy right?
It’s often much easier to write the objective if you are clear on the bigger picture, and almost impossible if you aren’t. So, my objective of running five miles without stopping only makes sense if I know the bigger picture of wanting to take part in a marathon. Without that, it’s kind of a bit random and isolated. So, when you’re writing Objectives with your team, it’s important everyone has an understanding of the bigger picture of organisational priorities.
Key Results are often much harder. They need to be able to tell us that we’re making progress towards the Objective, not just tell us whether we’ve achieved it or not, and not just tell us that with completed steps along the way. So with my running objective, I wouldn’t want my Key Results to be ‘Go to the gym five times a week’, as that’s a done/not done task, and doesn’t tell me if I’ll ever be able to run five miles without stopping. My Key Result of reducing the time in between stops tells me if I’m getting closer to being able to run five miles without stopping because I know that distance is going to take a certain amount of time, and so if, each week I can run for longer without stopping then one day I’ll be able to run five miles without stopping.
We haven’t mentioned anything about the work we’ll actually do to achieve the objective.
OKRs is a goal-setting technique that doesn’t focus on, in fact doesn’t even mention, what work you’ll do to actually achieve the goal. And there are two good reason for this.
When we focus purely on what we’re delivering, and not on what we’re trying to achieve, the work can easily become disconnected from the goal. We could be doing the wrong work and never know it. Or we could carry on delivering more than we need to after we’ve already achieved the goal. OKR’s help us avoid that.
And, when we specify our goals as delivering pieces of work, it assumes we have a crystal ball and know that particular work is definitely going to achieve the goal. Instead, OKRs allow us to deliver a piece of work, use the Key Results to learn that it didn’t help achieve the Objective, and so change to delivering a different piece of work, all without changing the original Objectives.
What OKRs aren’t
Deliverables or initiatives
Getting a campaign or a web page live is a deliverable, it might be an important piece of work to do, but it isn’t an OKR Objective. OKR’s don’t specify the work.
Everything you’re working on
OKR’s should focus on only the most important things the team is working on, those things that achieve organisational priorities. We’re all busy working on lots of different things, but we wouldn’t put all of that work into OKRs.
KPI’s or other metrics and measures
OKRs don’t replace KPI’s and other metrics that your team tracks. Those other ways of showing performance and progress are equally valuable.
What makes a good OKR
You’ll know if you’ve got a good OKR if you can answer Yes to all of these questions.
Can everyone in the team see how our Objective contributes to an important org priority?
Organisational strategy is only achieved by the work teams do. Being able to connect the work you do directly to the big organisational priority tells you it’s important work.
Have leaders and teams talked about the Objectives?
A good OKR is one that has been well thought through, socialised, agreed and accepted. Remember our earlier definition of an Objective? It should be easily memorable. Anyone in the team should be able to say, “Our objective for this quarter is to improve the quality of leads contacting us” without even thinking about it, and definitely without having to look it up in a slide deck.
Is it within the team’s control to achieve this Objective?
If achieving the Objective relies on lots of other teams to do things that might not be a priority for them, or needs someone who’s going to be on leave, or depends on a system that isn’t set-up yet, then the team’s chances of achieving their Objective are affected by things outside their control. You don’t want Objectives like that.
OKRs are really simple, but…
OKRs are really simple, but some organisations like to make them complicated.
So, things to watch out for…
Demanding team’s set OKR’s every quarter, even if the team isn’t working on something that contributes to an organisational priority, or the work the team is doing doesn’t generate any measurable Key Results. OKR’s aren’t the only, or always the best, way to show what a team is achieving.
Objectives are cascaded down and team’s told what their Objective should be, or even worse what they should deliver. Talk to other teams and leaders about teams having the space to figure out for yourselves how best to contribute to organisational priorities.
Retrofitting work that has already been lined up into OKRs. Sometimes this can be ok, simply speaking work can be converted into an Objective by asking ‘why’ are we doing this work. But it’s a bad habit to get into as it means the team is getting locked into delivering a piece of work that may or may not achieve the Objective.
OKRs in practice
Some tips and tricks for getting the most out of OKRs:
Start small, learn as you go
Start small and learn as you go. Each time you think about OKRs, you’ll come up with more questions; how many OKRs should we have, how long should we have the same objective, what if the results only show in the future, etc., etc.? You’ll figure out the right answers for you by discussing those questions together.
Impact is better than perfection
There’s no single ‘right’ way to do OKRs. If the way you’re doing it means you’re talking to leaders to get aligned, focusing on your most important work, and measuring the results to know you’re making a difference, then that’s great.
Avoid lots of process
Avoid having lots of process around OKRs. You don’t want to create an industry around managing OKRs. They are meant to help your team focus on what matters most, not become lots of work to administer. So, if you find yourself spending more time updating slides about OKRs than learning from the Key Results, then you probably should change that.
Getting started with OKRs in six easy steps
Set the objectives
Teams and leaders talk about what’s important to the organisation right now, and what the team’s objective(s) should be. The team should write an Objective they think will contribute to that priority.
Set the Key Results
Teams figure out how they can measure the change towards the Objective.
Often the data is imperfect or not available, don’t let this stop you. Try to find some data. And use this to help you identify how to improve the data so that tracking gets easier in the future.
Do the work
Teams decide what work they’re going to do to affect the Key Result. Often you won’t know for sure, but that’s the point of OKRs, they help us deal with that uncertainty, but use your expertise to come up with a hypothesis about what work you think will achieve the Objective.
Share the Key Results
Sharing the Key Results with others helps everyone ask questions.
If they didn’t change, the team asks, did we pick the right Key Results? Did we pick the right work?
If they did change, the team asks, have we done enough to achieve the Objective or is there more we can do?
Review and learn
This is the important bit. Don’t miss it. This is the team’s chance to think about the work they did and whether it was the right work to affect the Key Results.
OKRs are a powerful tool for shifting teams from focusing on deliverables to focusing on having an impact on the things that really matter, but that only happens if you are regularly asking questions and learning what it takes to make that shift.
Repeat
Next quarter, start with the Objective again. Ask, is it still the right objective or should we have a new one. If you achieved it last quarter, you’ll definitely want a new one, but sometimes organisational priorities change so always start there.
