Product Goals articulate the strategic objective a Scrum Team is trying to achieve over time. They are part of the commitments tied to the Product Backlog and guide what is selected, refined, and delivered Sprint by Sprint. Unlike Sprint Goals, which are short-term and limited to a single Sprint, Product Goals are longer term, often lasting several Sprints (likely a few months), and importantly, they both provide direction. Used alongside Product Goals, OKRs (Objectives & Key Results) support better focus and empirical feedback.
To me, it’s helpful to consider the Product Goal to be the direction, but the OKRs as the mile-markers used on the journey to check your progress. The Objective states the qualitative intent and the Key Results quantify what success looks like. OKRs are not part of the Scrum Guide, and they introduce concepts that go beyond the framework. When used effectively, OKRs complement Product Goals by making direction measurable and outcomes transparent. Personally, I’m a fan of writing them using Jeff Gothelf & Josh Seiden’s model of “Who does what by how much?”
Who Does What by How Much?
Taken from the book of the same name, this is a simple way to ensure that Key Results are rooted in behaviour change. We all know that Product Goals should be measurable and associated with key outcomes and metrics, so what I’m suggesting is that OKRs fulfil this need instead of being used as a standalone technique in product development. Let’s look at an example:
Product Goal: Reduce customer in-bound support calls by 20% to alleviate low staffing issues across the call centre.
So, we know what we want to achieve with a suggestion as to why. To achieve this, we might do many things such as creating a ChatBot, a customer FAQ board, a WhatsApp chat etc., but for now we need to avoid the tactical and stick with a strategic mentality. How will we know when our Product Goal is achieved?
Objective: Enable users to complete key workflows without external assistance, improving satisfaction and reducing support volume.
Key Results:
- 30% of customers resolve their support issues without speaking to us on the phone.
- 60% of call-centre staff reduce their overtime by 4-hours per month.
- 70% of customers rate their support resolution as ‘simple’.
What do you notice about this example? If you look closely, you will notice how each Key Result focuses on a behaviour and a degree of measurable change. We are basing progress on outcomes that matter to the customer and the organisation.
Connecting Product Goals to Evidence
One of the recurring difficulties teams encounter is the temptation to treat Product Goals as aspirational rather than decision-making tools. A Product Goal should help you make trade-offs and should cut through noise, making it obvious which work belongs in the Product Backlog, and which work needs to wait. OKRs are useful here because they translate strategic intention into a small set of directional metrics that can be inspected regularly.
Consider the flip-side - reviewing your Product Backlog without any OKRs. You could easily fall into a cycle of prioritising what feels urgent or what the most vocal stakeholder insisted on last week. When OKRs are present, they act as steps on the ladder to achieve the Product Goal. For each Sprint Goal or PBI, think about whether this item help move any of the Key Results? If not, why are we discussing it? The presence of OKRs encourages a degree of discipline that many teams find refreshing once the habit sticks. Another benefit is the way OKRs normalise the idea of testing assumptions (if you’ve ever read my content before, you’ll know I’m a big fan of this). If your Product Goal hinges on improving customer self-service behaviour, you can choose experiments that demonstrate whether a particular change is nudging behaviour in the right direction; don’t assume success, you measure it!
Avoiding the Output Trap
Product Teams often fall back into output thinking because it feels more certain. It feels safer to commit to delivering three new features than to commit to changing customer behaviour which they feel far removed from. If we focus only on outputs, we drift away from delivering value and drift towards shipping functionality for the sake of it. Believe me, I’ve been there, and you’re floating towards the edge of the waterfall.
A Key Result that states that customers will do certain things without external help encourages a team to ask more thoughtful questions. Which processes do we want them to avoid? Why are they currently struggling? What evidence do we have? What experiments can we run? These questions move the conversation upstream and create opportunities for better learning, faster discovery, and, usually, more effective delivery. OKRs turn vague ideas into specific statements of value which is vital when justifying progress internally.
Starting Points
I never like to finish a blog without giving ideas of something practical to try, so here they are:
- Create two or three OKRs rather than a sprawling list - you do not need more! One clear Objective with two or three measurable Key Results is enough.
- Anchor each Key Result in behaviour. Look for verbs such as complete, choose, return, reduce, increase etc. as these nudge you away from measuring outputs and towards meaningful change.
- Keep the language plain because there is no award for the most elaborate OKR. A straightforward sentence that everyone can remember is often the most effective.
- At the end of a Sprint if none of your OKRs have moved forwards (achieved, learned, validated or simply progressed), the Product Owner needs to own that discussion.
Conclusion
In the end, Product Goals and OKRs matter because they bring clarity to two different layers of intent. A Product Goal sets the strategic direction in that it tells everyone involved why the work exists and what change the team is collectively aiming to bring about. OKRs take that direction and make it tangible. They turn intention into a set of observable shifts in behaviour that can be inspected, challenged, and improved through the normal rhythm of Scrum.
On their own, each is useful but together, they create a system of focus that reduces distraction and encourages learning. Product Goals keep the team aligned on the long view, while OKRs help the team understand whether the choices made along the way are actually working. With both in play, a Scrum Team has a clearer path forward, a sharper sense of progress, and far greater confidence that what is being built will genuinely matter to the people they serve.