Product goals are the measurable form of a strategy, and objectives and key results are the notation most organisations now write them in. A roadmap says what a team will work on and in what order. It says nothing about what would count as having succeeded, and that gap is where goals belong. The lineage starts with Peter Drucker's management by objectives, set out in The Practice of Management in 1954. Andy Grove adapted it at Intel during the 1970s and documented the result in High Output Management in 1983. John Doerr learned the method working for Grove, introduced it to Google in 1999 and later wrote it up for a general audience in Measure What Matters in 2018, which is where most product managers meet it now. A badly written key result does more damage than no goal at all, and writing them is a product manager's job. A bad one points a team's effort precisely. It points it in the wrong direction for a whole quarter.
The sections below put goals in their place under the strategy and separate an objective from a key result. Two sections then work through the failure modes behind most disappointing rollouts. The page ends with cascading against aligning and with the seventy per cent convention. A last section names the situations this notation does not suit.
Where product goals sit in the strategy stack
The product strategy stack puts product goals at the bottom, underneath the roadmap. That placement looks wrong at first. Goals feel like the thing that should direct the work.
The reasoning is about where the information comes from. A goal is a claim about what the current work should achieve, so it can only be written once the work has been chosen. Because no strategy sits above them, the targets get picked from whatever the organisation already measures, and the roadmap is then bent to move those numbers. Teams arrive at this position honestly. It is also the single most common reason an OKR programme is abandoned after four quarters.
What an objective is and what a key result is
An objective states what the team is trying to achieve, in language a person can repeat from memory. It carries no number.
A key result is the evidence that the objective has been reached. It carries a number, a baseline and a target, and it names a change the team can strongly influence and cannot guarantee.
That last property separates a key result from a task. Work the team fully controls is delivery, and putting it in this notation converts a plan into a set of promises while changing nothing about what the team actually does.
The first failure, output written as outcome
Most disappointing key results are deliverables with a number attached. They pass review because they are specific and measurable, and they fail because reaching them proves only that work happened.
| As commonly written | What it actually measures | A stronger form |
|---|---|---|
| Ship the parts catalogue by March | Whether the work got done | First visit fix rate rises from 60 to 80 per cent |
| Run twenty customer interviews | Activity | Three of five target accounts confirm the parts problem costs them over £50,000 a year |
| Increase the satisfaction score by ten points | A proxy chosen because it already exists | Repeat booking rate rises from 41 to 55 per cent |
| Reduce page load to 1.2 seconds | A genuine outcome, if the diagnosis named speed as the problem | Keep it exactly as written |
The last row matters as much as the first three. A technical measure is a perfectly good key result when the strategy's diagnosis says that is the problem. A key result is weak when no diagnosis sits behind it, and never because of the shape of the number.
The second failure, measuring where it is easy
The second failure is harder to see and harder to argue with. A team picks a target that is genuinely an outcome and genuinely measurable. It is simply not the outcome the strategy needed, because that one is expensive or slow to observe.
The usual symptom is a quarter spent moving a number that nobody outside the team believes changed anything. A strategy aimed at retention among large accounts gets a key result about total weekly active users, because that figure updates daily and the account level figure takes a whole quarter to read.
The defence is to write the key result the strategy actually implies first, and then to ask what it would take to observe it. If the honest answer is that no reading will arrive inside the quarter, the right move is to name a leading indicator explicitly as a stand in for the measure the strategy really wanted. The goal then records the lagging measure the indicator stands for, and the team checks whether the relationship held once the slower number finally arrives.
Cascading and aligning
Cascading means a level sets its goals and each level below breaks them into sub goals. It produces perfect arithmetic alignment and takes most of a quarter. It also removes the judgement of the people closest to the problem, which is usually the reason the team was hired.
Aligning means each team writes its own goals against the strategy above, then the set is read together to find the contradictions and the gaps. It is faster and it keeps the thinking where the knowledge is. It also needs one person to genuinely read the whole set, because collecting it achieves nothing.
Doerr's own account of Google's practice describes goals set both upward and downward, with a large share starting in the teams. The version that fails is the one that keeps the top down mechanics and drops the upward half.
The seventy per cent convention
Google's practice, widely copied, grades key results on a scale from zero to one and treats around seven tenths as the expected result for an ambitious goal. The purpose is to make an aggressive target safe to write. If full achievement is the expectation, every rational team writes a target it already knows it can reach.
Two conditions make the convention work, and both get dropped in practice. Grades have to stay out of individual performance assessment, because a number that affects somebody's pay stops being an honest instrument the moment they work out that it does. And the organisation has to tell an ambitious goal from a committed one. Some things do have to be fully delivered, such as a regulatory deadline, and scoring those at seven tenths is a failure.
When this notation is the wrong tool
Objectives and key results suit a team with real freedom over how to reach an outcome. Three situations sit outside that.
Work with a fixed external date and a fixed scope is a commitment. A compliance change is the obvious example, and a commitment belongs on a plan. A team in the first weeks of searching for product market fit has nothing stable enough to set a quarterly target against, and a learning goal serves better. And some functions exist to keep throughput steady at a steady quality, such as a platform team that has an availability target to meet. Those functions do better with standing measures that never reset. A fresh set of goals every quarter buys them nothing.
A strategy now has choices, a sequence of work and a definition of success. Every one of those exists inside the heads of the few people who built them. The next problem is getting all of it into an organisation intact.