Beware of the Dogma of Outcomes and find your own Approach
Tim Herbig is a Product Management Coach and founder of herbig.co – a Germany-based management consultancy providing help on building better teams and products. In this Voices of OKR piece Tim breaks the dogma that product teams should be focused only on Outcomes when using OKRs.
Focusing on Outcomes instead of Outputs has been repeated continuously amongst Product Managers for a while now. And while the underlying intent of trying to change behaviors instead of ticking off tasks feels objectively correct, it might not always be the right thing to do.
When you frequently hear about how vital Outcomes are for a real Product Manager’s work, it’s easy to get caught up in believing that they are the only viable way to measure progress. After all, you don’t want to be that person who’s still focused on building features instead of changing behaviors.
Shifting the various activities of Product Management to more Outcome-oriented product goals can almost always be beneficial. However, it can also lead to teams who lack a supportive environment or skills to do that right now remaining stuck. Out of fear of not doing things right from the start, they would rather wait for the perfect moment, instead of starting their journey toward Outcomes, which is the real failure—even if it means utilizing Outputs to measure progress and success temporarily.
With the repeated touting of Outcomes enabling all sorts of potentially positive changes for product teams, we, as an industry, are close to creating a Dogma. The dogma of being a “real” product team, only if the focus is solely on Outcomes. The dogma that only using Outcome-based OKRs is the right way to do OKRs. The dogma of doing a thing right, before doing it at all.
Don’t get me wrong. I still believe that a focus on Outcome OKRs is a great aspiration for a product team as long as you can tie it to an actual goal you want to achieve. Don’t try to force a principle upon you, if it doesn’t improve your work or boost progress. Focusing on Outcomes because someone else (including myself) suggests doing so is merely a means.
Finding your own Path toward focusing on Outcomes
Whenever you want to change your way of working, you should tie it to a trigger that holds you back at the moment. Have you seen too many prescribed feature ideas not moving the needle? Do you experience an extraordinary churn of team members who are looking for self-determination instead of micromanagement? Or do you continuously observe unnecessary overlaps and dependencies to other departments?
Addressing problems like these are the real ends for product teams. And picking Outcomes as a vehicle to get there is a great idea.
But what if you can’t utilize this vehicle in a prescribed form right now? This might be due to the company culture you are a part of because of conflicting ways of working or a lack of skill and experience.
But none of these will go away automatically. As the saying goes, “change it, love it, or leave it” are your best options here. Loving the status quo can be a tough ask, and so is also switching jobs. That is why you need to change the whole system.
That leaves you with “change it”. But, as many of you know, change is hard. And changing how an entire company thinks and works is as well. If you treat switching to a focus on Outcomes as the journey that it is, the question remains: What is your starting point?
It’s the here and now. Meaning – pick the benefits you can achieve through a different way of working right now. So, while using Objectives and Key Results (OKRs) right now without built-in Outcomes, it can still change your way of working for the better.
Even though Output Key Results look like a glorified task list, continuously measuring the progress towards achieving them is an often-surprising significant change from how most teams track progress.
Utilizing OKRs with Outputs at least gives you an objective list of priorities and creates a regular occasion to discuss your progress.
The best thing? By topping that up with not just a review of your progress at the end of the goal cycle but also reflecting on how to improve, you can take the next step.
Change requires intrinsic motivation to tackle a problem. To arrive at the point of changing things beyond your team’s control, you need to make your lessons learnt visible. Share the experiences you had with focusing on Outputs. What went well? What could be improved?
And don’t discard such exercises as something that is “already out there”. Every team that rolls their eyes on a prescribed feature idea is at least one team out there that doesn’t (yet) feel confident enough to define solutions for driving an Outcome themselves. And that’s ok.
For every product team that gets discouraged by an over-glorified definition of Outcomes, I would love to see at least one not being held back and instead getting at it. No matter how imperfect their starting point might be.
Don’t follow a prescribed approach others did come up with. Instead, gather the experiences from your experiments in YOUR context, solving YOUR challenges. And use the learnings from this journey to find your own approach to OKRs.
Ready to get started? Here’s an actionable bonus to help you out
It’s important to me that you can act on this shifted perspective I shared with you today. To help you do just that I’ve set up a special bonus section just for you. It includes my FREE 3-step email course with step-by-step guidance on creating the OKR approach your company deserves.
It will help you develop a shared understanding of OKR benefits based on what you want to achieve and find out what to do next when it comes to adjusting the way you use OKRs in your company.
You can enter the bonus area by signing up here .
Looking to get started with OKRs? Try Gtmhub FREE for 7 days!