Product Goals

Product Goals
Using Objectives and Key

Results (OKRs) for Agile
Teams (2020)
This is my complete guide to Product Goals in 2020.
In this all-new guide you’ll learn:
What Product Goals are and why they matter

The difference between Outcome and Output Product Goals
How to combine Objectives and Key Results (OKRs) with Agile
practices like Theme-based Roadmaps, Product Discovery, or
Scrum
Proven techniques to set Product Goals
Lots of advanced tips, strategies, and tactics
If you’re asking yourself how you can connect Product Strategy and
your Product Discovery/Delivery efforts through outcome-oriented
goals, you’ve come to the right place.
Let’s get started.

__________________
Tim Herbig
www.herbig.co
tim@herbig.co
Introduction
Does your team ask, “How do we know that we’re on
track?”Besides knowing what success might look like “in the
end,” it can be even more important to know how your activities
and progress match your ambitions while you’re moving ahead.
And that doesn’t just depend on the type, quality, and choice of
your defined Product Goals, but even more on how you use
them. If you set a goal with a specific ship date, that probably
won’t help you organize your everyday activities.
Product Teams certainly spend a significant amount of time with

their heads down, focussing on Product Discovery or Delivery.
But when they look up, to seek guidance for their next move,
they shouldn't just be presented with a list of features and
release dates.
That’s what differentiates effective Product Goals from setting

arbitrary milestones.
This guide wouldn't have been possible without the input and
advice from my partnership with Sonja Mewes, Founder and
OKR Consultant at Beautiful Future.
Product Goals -
Using Objectives and Key Results (OKRs) forAgile Teams (2020) 02
Contents
A Primer on Product Goals Using Objectives and Key Results

(OKRs) for Product Goals
Combining (OKRs) and Product Goal Examples

Agile Product Management
Product Goals Resources
Product Goals -
A Primer on Product Goals
In this Chapter I want to introduce the basic concept of Product

Goals by answering some fundamental questions.
What are Product Goals?

Obviously, it’s hard to squeeze a generic term like goals into a one-
size-fits-all definition. So, instead of trying to define what exactly
Product Goals ARE, I will focus on what they DO—at least when
used properly.
The main thing Product Goals should DO for Product Teams and
your organization is to make your strategic direction more
tangible. While the strategic direction for the next three to twelve
months provides high-level orientation, Product Goals help to make
sure that more tactical decisions are also in-line with that direction.
And while Product Strategy can also include high-level numbers to

express a certain strategic priority, Product Goals become more
effective when they exclusively focus on measurable progress.
Product Goals can incorporate more aspects of building a product
than just pure performance. We’ll talk about the combination of
qualitative and quantitative goal setting later.
Product Goals -
But be careful. Because Product Goals are meant to connect
Product Strategy and Product Execution, it’s easy to confuse
these three terms.
With these things in mind, let’s settle on a working definition for

moving through the rest of this article.
Product Goals Definition
Product Goals are a set of tangible and measurable

expressions of what success looks like for a product.
Product Goals connect Product Strategy and Product
Execution by providing teams with a concrete and
holistic set of metrics, so they know if they are moving in
the right direction and can adjust their actions if needed.
Product Goals -
How are Product Goals
different from Product
Strategy?
Without going into too much detail about Product Strategy, here
are the main questions every (good) Product Strategy should be
able to answer:
1. What are the essential problems your product is solving for

your users and which ones do you want to address in the
future?
2. What alternatives could your users use to solve that problem
(ie. direct and indirect competitors)?
3. What are the core value propositions that define your
product?
4. What makes your product unique compared to those direct
and indirect competitors?
I like to visualize the answers to these questions using

the Product Field framework to have the (constantly evolving)
pillars guiding Product Discovery efforts constantly visible.
Product Goals -
Product Strategy is the starting point for Product Discovery. But
Product Teams shouldn't blame it on their manager or the C-level if
the Product Strategy isn’t clear. Instead, I encourage them to create
clarity about their strategic direction themselves. By utilizing
collaborative frameworks like the Product Field, you can outline the
strategic direction of your product and identify the existing blind
spots pretty easily.
The point is not to create a McKinsey-level company strategy. But

something to refer to when you have to make trade-off decisions as
you navigate through the problem space of a discovery mission.
In general, I like to differentiate the main disciplines of Product

Management into three flight levels.
1. Product Purpose/Vision/Mission and Product Strategy

2. Product Goals and Product Roadmaps
3. Product Discovery and Product Delivery
Product Goals -
So, instead of treating these six disciplines as siloed activities, I
believe in a more connected perspective:
Not only are the disciplines within one flight level connected, but
the insights and experiences from one discipline flow up or down
to inform the other flight levels. Because of that, the quality of
every of these six disciplines radically influences how well one of
the others can be implemented. When Product Strategy isn’t
clear, many teams struggle when asked to “define goals for the
quarter.”
Arriving at the “right” set of Product Goals is a journey that

requires iteration—often both within and between goal cycles.
But it can get a lot easier when teams have the right strategy to
begin with.
Product Goals -
How to identify Product
Goals?
Product Discovery entails creating alignment around which
problem space to pursue and diving deep into the challenges your
users, customers, or stakeholders face.
After all, you want to make sure you have understood what the
actual (and often underlying) problem is and if it's worth solving.
But once you have identified and structured your findings in the
forms of user behaviors worth changing, teams often get lost.
Now, user problems are rarely suited to be used as goals right away.
Instead, we have to think about how you could measure your
success. To set tangible Product Goals you must boil down the
gathered qualitative and quantitative insights from your user
research to determine HOW to change your user segments'
behavior.
Let's look at a b2b example first. Assume you're building analytics

software and your strategic priority is to increase revenue from
agency customers. Through research, you might identify specific
problems your target audience faces.
For example, account managers may be struggling with how

long it takes to report results to their clients, and IT
administrators need constant updates on data compliance. So, if
you focus on the identified outcome for account managers, the
“How might we…?” (HMW) challenge based on their core
problem might read like this:
"How might we speed up the client reporting process of results

for account managers?"
Product Goals -
And even though this provides lots of context for ideation and
prototype creation, you need to be more specific.
If you're shipping a solution for that problem, you want to know

what success looks like. Rarely can you tie one product release to a
high-level metric like company revenue. This means the team
should think about specific metrics that express what "speeding
up" would look like for account managers.
From a qualitative perspective, you might utilize a modified

Customer Effort Score on-site survey to see how the perceived
speed has changed: you could set a Product Goal like "Customer-
Effort-Score of 4.5 for the report generation process."
From a quantitative perspective, you could look at metrics like

"time spent" in this product area or the number of reports created.
Both metrics could tell you how the behavior has changed.
Defining a Product Goal that works for the solution you have settled
on should be a cross-functional effort. The analytics manager might
help you with what's possible. The UX designer might bring a new
user perspective to defining "what success" looks like.
Product Goals -
The way you transition identified user problems into measurable
Product Goals should be aligned with the way you utilize goals in
general at your company. Make sure to adjust this process if you're
using something like Objectives & Key Results (OKRs), the North
Star Framework, or the Balanced Scorecard.
Product Goals -
Using Objectives and Key
Results (OKRs) for Product
Goals
OKRs are a very effective way to set, track, and review Product
Goals. In this Chapter, I will outline the structure of OKRs, as well as
the difference in using Output and Outcome OKRs.
What are Objectives and Key

Results (OKRs)?
OKRs stands for Objectives and Key Results. In short, OKRs
combine the best aspects of goal setting into one framework: A
highly-inspiring qualitative vision with concise and measurable
metrics to determine success or failure.
Product Goals -
An Objective is like a mission statement, only for a shorter period. A
great Objective inspires the team, is hard (but not impossible) to do
in a set time frame, and can be done by the person or people who
have set it, independently. An Objective should typically be:
Qualitative and inspirational

Difficult but not impossible to achieve
Time-bound
Actionable by the team independently
Key Results take all that inspirational language and quantify it. You
create them by asking a couple of simple questions: How would we
know if we met our Objective? What numbers would change? A
company should have two to five Key Results per Objective. In
general, Key Results can be based on anything you can measure.
Product Goals -
Objectives and Key Results (OKRs)
Definition
OKRs combine the best aspects of goal setting into one

framework: A highly-inspiring qualitative vision with
concise and measurable metrics to determine success or
failure. Key Results take all that inspirational language
and quantify it through 2-5 holistic measuring criteria.
If you select your KRs wisely, you can balance forces like growth and
performance, or revenue and quality, by making sure you have both
the potentially opposing forces represented.
The 'invention' of OKRs is often credited to Andy Grove during his

time at Intel. Later on, it got popularized through wide-spread
implementation by Silicon Valley companies like Google. While
many people admire the improvements Google made in employee
performance management, OKRs have evolved to become much
more.
Here’s an example of an OKR set:
Objective: We are an integrated and mature platform solution

Key Result 1: Our Enterprise client satisfaction rate is >75%
Key Result 2: No sales pitch is lost through “immaturity of the
product”
Key Result 3: 100% of interviewees associate our website with
the terms “enterprise,” “trustworthy,” and “capable”
Product Goals -
Nowadays the appeal of OKRs for agile product teams lies in its
core promise for improving the way we work:
1. More focus
2. More autonomy
3. More alignment
More Focus
A typical cycle for OKRs is a quarter. Smaller companies could

combine that with a yearly OKR to let every Objective aim at
something beyond the next three months.
Also, while it's standard (and ok) to set up to three OKRs for a team
per quarter, this already poses a drastic improvement in terms of
being able to focus on a few key initiatives. While some
stakeholders confuse 'Agile' with changing their mind every two
weeks just in time for the Sprint Planning, OKRs provide a
continuous path to pursue throughout the entire quarter.
Moreover, even though OKRs don't necessarily need to cover ALL of

your work (everybody knows some maintenance work can be
critical), they should reflect what's most important for your team.
More Autonomy
By design, effective Outcome-OKRs don't talk about features.

Instead, they shift the conversation to the impact a team should
seek to make, as opposed to measuring the number of released
features.
Product Goals -
For your stakeholder environment this means they will delay
talking to you about their feature wish list, but instead agree on a
set of outcome metrics first. We’ll talk about Outcome goals later.
For teams, it means focusing on the (most critical) problems first to

reach their (ambitious) Key Results.
More Alignment
The process of defining OKRs should involve all levels of a company.

While it's natural that a leadership team sets the company-level
OKR, the next step is to get the rest of the company on board.
That’s how a single team gets inspired by the overall direction of
the company to define their contribution in the form of a matching
OKR. Making the OKR definition and review a focussed effort for the
entire company at the beginning/end of a quarter reduces
misunderstandings across teams significantly.
Product Goals -
Outcome OKRs vs. Output
OKRs
Many product teams are looking for ways to shift their way of
working and thinking towards outcomes. Whether that's
through theme-based roadmaps, Impact Mapping,
or...Objectives and Key Results (OKRs).
However, there's a common misbelief that OKRs come with

"built-in" outcomes. Setting goals this way will automatically
limit your discussion to fewer solutions - ie. Outputs.
Now, before we go further, let’s go over what I mean when I talk

about Outcomes and Outputs.
To me, an Outcome describes a measurable change in behavior

that contributes to an Impact. (This definition is inspired by Josh
Seiden’s excellent book “Outcomes over Outputs.”)
An Output, on the other hand, is an artifact that has been

delivered through activities. It's one way of creating this change
in behavior, whether for customers, users, or internal
stakeholders.
OKRs can work with either Outcomes or Outputs. As with every

framework, the benefits of OKRs highly depend on how you use
them. It's certainly possible to set some or all of your Key Results
as Outputs. In some instances, this might even be a better way to
get started. Some teams get stuck in the Key Results definition
process because they try to turn everything into an outcome—
just for the sake of it.
Product Goals -
Here’s a practical example of how Outcome OKR and Output OKR
sets might differ:
But there’s more to shifting to Outcome-based Product Goals in

your organization than to define more “Outcome-ish” Key Results.
Putting Outcomes into practice requires changes to your processes

beyond defining OKRs. My upcoming course “Outcome Goals for
Product Teams” helps you learn which levers to focus on and
shares practical advice on how to shift your team’s focus from
Outputs to Outcomes.
Product Goals -
Combining (OKRs) and Agile
Product Management
This Chapter will shine some light on how teams can effectively
combine the strengths of OKRs with existing Agile practices like
Product Discovery, Product Roadmaps, and Scrum.
Building digital products can often seem to be all about pushing

tickets and releasing code. Instead, I want to broaden your horizon
for the three levels of a sustainable Agile product management
process:
1. Product Roadmaps
2. Product Discovery
3. Product Delivery (ie. using Scrum)
Agile Product Teams experience the biggest additional value from

using Objectives and Key Results if they are able to focus their Key
Results on Outcomes and integrate OKRs into existing tools,
practices, and routines.
Product Goals -
Defining their OKRs helps Product Teams align and commit to
goals. But they still need an additional session to pick specific
initiatives and next steps. A dedicated session to prioritize Epics and
Initiatives is necessary to get a team into the Product Discovery
phase of a Problem Space or the Delivery of a (previously
discovered) solution. But how can you structure it?
Using Impact Mapping to

select Epics after the OKR
Definition Workshop
Let’s shine some light on how Impact Mapping helps Product
Teams during this Epic Selection session.
As a quick recap, here are my five levels of Impact Mapping:
WHY - The Impact-level goal that matters to the whole

company/department.
WHO - The (internal and external) user segments (Actors)
who contribute to the Impact.
HOW - The change in behavior the team seeks to create for
the Actors.
WHAT - The potential solutions (Outputs) a team could
pursue to create a change in behavior.
WHETHER - The experiments the Product Team is running to
determine if the output is worth pursuing.
If you work with company-level OKRs, chances are that these Key
Results can be candidates for your Impact as the starting point.
This represents the quantitative measurement of success for the
company from a quarterly or yearly perspective.
Product Goals -
The Actor level should be clear from previous research efforts. If not,
schedule additional research for the quarter.
If your team has established Outcome-oriented Key Results, those

can now serve as input for the HOW level. Ideally, your Impact Map
has informed your OKR definition process, so there's no gap
between the two perspectives.
Because you (hopefully) know which Outcomes in the form of your

Key Results are a priority, you can now transition into the solution
space. If those Outcomes are based on existing Product Discovery
work, one of your next actions should be structured ideation to
come up with feature ideas.
These ideas (along with the following experimentation) could have

already happened in a previous quarter to inform the Delivery work
you now want to focus on. Because, after all, you will probably only
achieve those Key Results through shipped solutions.
Product Goals -
Communicate Epics and
Initiatives using Theme-
based Roadmaps
Sadly, most businesses still plan product development up to 12
months into the future by relying on time-based roadmaps
following a Gantt chart style visualization. While this approach
may have worked for the static waterfall planning we used to do
'back in the days,' it's hardly suited for agile and iterative
methods, which embrace uncertainty instead of trying to fight it
with deadlines.
A more fitting approach for planning your efforts is based on so-

called Theme-Based Roadmaps. They enable you to prioritize
broader initiatives, rather than fixed feature sets, and
acknowledge increasing uncertainty as you look into the future.
You can also compare themes as the parent element of specific

Epics. A theme represents a more significant user or business
problem you draw on to discover a solution (ie. Epic) to reach
your goals.
Product Goals -
The three categories of a typical Theme-Based Roadmap can be
differentiated like this:
1. NOW - Ideas that have been validated, specified in more detail,

and are currently implemented.
2. NEXT - A prioritized list of the strategic priorities Product Teams
will explore using Product Discovery.
3. LATER - Ideas that might fit current strategic priorities, but have
not been committed for Discovery or Delivery work.
Examples for a theme could be things like 'User Growth,' 'Revenue,'

'Churn,' or 'Enterprise.' Corresponding Epics could then be 'Referral
Mechanism,' 'Free Trial, ‘Self-Service Help Center’, or 'Single Sign
On.'
C. Todd Lombardo delivered a great presentation on this modern

approach to building roadmaps at the Mind the Product San
Francisco Conference in 2018:
click to watch
Product Goals -
OKR and Theme-Based Roadmaps play nicely together right after
you have committed and aligned OKR sets, e.g.quarterly. You don't
have to turn Key Results into release dates and Gantt charts right
away. Instead, the themes from the roadmap inform your OKR
priorities and vice versa.
But it's not about choosing between themes OR Epics at this point.
A Theme-Based Roadmap also incorporates the Epics (IF identified
through Product Discovery).
But what if you haven’t done the work to decide which Epic to
pursue? Then there's little to no point in using Outcome OKRs in
the first place. You could have just tasked teams with building "this
thing."
There's a time and place for date-based release plans.But

communicating chosen Epics coming straight from the OKR
definition workshop is not one of them.
Combining OKRs and

Product Discovery
Product Discovery describes the iterative way of collaboratively
answering two key questions:
1. Is this a problem worth solving?

2. Is this a solution worth pursuing?
Just as with Objectives and Key Results (OKRs), I prefer to help

teams find their own way of using Product Discovery techniques
in a way that works for them, instead of prescribing a given
process.
Product Goals -
As a result, I have developed the Adaptable Product Discovery
approach, that guides teams through the non-linear process of
reducing uncertainty around the problem space of a given mission.
As mentioned, Product Discovery works great in combination with

Theme-Based Roadmaps, as it encourages your Product Team to
think about Outcome instead of settling on detailed feature ideas
right from the start.
But there are also challenges when using OKRs in Product

Discovery. For one, there's the aspect of timing: When you have
defined your OKR at the beginning of the quarter, then embark on
a (typical) 6-week Discovery phase, you have hardly enough time
left to make an impact with what you're building. Remember that
shipped features sometimes need weeks in the hands of customers
before they cause a change in behavior and thereby metrics.
Product Goals -
On the other hand, how should you decide on which area to focus
on, if you don't know the goals for the next quarter yet? Here's
where the concept of the Theme-Based Roadmap comes in handy.
Because you have a rough understanding of which areas your team

wants and needs to work on 'Later,' you can define a Product
Discovery OKR for the current quarter. This might include Key
Results like 'Understand the key needs of 10 Enterprise product
prospects' as the ‘Enterprise’ themes for the following quarter.
This way, the Dual Track efforts of an Agile team can be organized
using OKRs, and the Product Manager has clarity about what to
focus her Product Discovery efforts on:
While Product Discovery focuses on the problem space, a lot of Key

Results focus on Delivery and business results (which is another
discussion by itself). The biggest problem here is that this draws the
attention away from the Discovery activities of a team. By agreeing
on, and regularly revisiting, a dedicated Discovery OKR, teams can
raise the awareness for this (often unseen) part of their work.
Product Goals -
If your company agrees on the fact that OKRs should reflect the top
priorities, that’s an even bigger argument for utilizing a dedicated
set of Product Discovery OKRs. After all, Product Discovery should
be one of your priorities. A separate OKR set can help establish a
shared understanding of that.
In my opinion, one of the most significant additional benefits of

OKR for Agile environments is the (continuous) connection to
everyday tasks. So, when you spend 20-30% of your daily activity on
Discovery, I believe that there should be an overarching goal in
place for those tasks.
Effective OKRs enable a holistic perspective. So, besides business

results (a performance aspect), it's worth incorporating things like
product quality or process improvements. A Product Discovery OKR
can help establish alignment across individuals and teams to focus
on essential practices. Alternatively, you can also establish specific
Discovery aspects as an individual Key Result, instead of dedicating
an entire set to it.
Please keep in mind that the primary job of a Product Discovery

OKR is to make Product Discovery work a visible priority for your
team. It doesn't have to be the perfect incarnation of existing OKR
blueprints.
Product Goals -
How to combine OKRs and
Scrum?
When it comes to Product Delivery, you need to make sure that as
many items as possible in your product backlog can be associated
with an OKR. That is the only way to connect your team’s everyday
tasks with the higher goals of the organization. If you're using JIRA
for managing your user stories and agile processes, you can easily
integrate this OKR connection through a set of custom fields.
The built-in dashboards then give you a concise overview of how

much work a team has dedicated to reaching an OKR:
Next, you can also link each of your Agile routines to your goals by
tying your activities to questions about their relevance:
Bi-weekly Sprint Planning: What are the next priorities to make

progress with our OKR?
Bi-weekly Review: Which output AND outcome did we achieve?
Bi-weekly Retrospective: How did our collaboration hold up to
our norms?
Product Goals -
In my talk “OKR – 3 Letters for Effective Product Organisations” at
the 2019 Product Management Festival Europe, I shared more
insights on how Product Teams can utilize OKRs for their daily
work:
click to watch
Product Goals -
Product Goal Examples
Whether you’re using OKRs to set Product Goals or are facing

specific challenges based on your industry, this Chapter will deliver
practical examples to inspire your next goal cycle.
Besides some generic metrics like Page Views, Conversion Rate,

Customer Satisfaction, or Churn, I want to address some domain-
specific product goal examples in this section.
Product Goals for SaaS

Product Management
SaaS products mostly use subscription revenues to monetize their
offerings. Which means that in the short- to mid-term, Product
Managers need to focus on more tangible leading indicators than
the actual churn event.
Product Goals -
From a Product Strategy perspective, it might make sense to
prioritize the reduction of the churn rate as an overarching priority
for the company. But for measuring the success of ongoing
product work, teams need to look somewhere else.
Here some example metrics Product Managers can adopt for that:
Completion rate of onboarding steps

Number of key metrics (like number of connections, collected
research insights, set up integrations) achieved in the first 30d
that mirror an aha! moment for your users
Usage frequency, while keeping in mind the natural usage
patterns of your product
On a mid- to long-term level, other metrics like ARR, Number of

Logos, or Annual Contract Value can be used as well, to make a
strategic direction (Growth vs. Monetization vs. Retention) more
tangible.
Andrew Chen suggests visualizing the product usage using the

“Power User Curve”:
“Some products should be analyzed in a 7
day timeframe – like SaaS/productivity – and
others on 30 days:Another flavor of the
Power User Curve is a histogram of users’
engagement for a 7-day period, also
commonly called L7. The 7 day Power User
Curve shows weekly actives, not monthly
actives. Plotting this version can make sense
if your product naturally follows a weekly
cycle, for instance, if it’s a productivity/work-
related product that users engage with
Monday through Friday. B2B SaaS products
will often find it useful to show this version,
as they want to drive usage during the work
week.”
Product Goals -
Product Goals for Enterprise
Product Management
When it comes to building a product for the Enterprise, many
Product Managers will grow frustrated with the lack of quantitative
data.
After all, whether you achieve 70 or 75 page views of that new

product area, is often insignificant. Yet, it’s the reality of building a
problem for a limited number of companies, with an even more
limited number of users per account.
But this doesn’t mean that goals become obsolete. Instead, you
have to double-down on qualitative metrics and internal process
excellence.
Here are some examples:
Number of live bugs reported by customers

Feature usage frequency per customer (properly segmented!)
Customer Effort Score (ie. per newly released feature)
Product Goals -
Product Management OKR
Examples
Product Delivery OKR Examples
Objective: Satisfy existing enterprise clients to lay the

foundation for contract renewals
Key Result 1: 0 major incidents (like blocker bugs or data-loss)
per client
Key Result 2: Every requested and implemented feature gets
used by the respective client at least once
Key Result 3: Establish a feedback process for enterprise clients
with the average feedback being "satisfied"
Objective: Successfully launch version 3 of our main product

Key Result 1: Get published product reviews in over 15
publications
Key Result 2: Get 10.000 new signups
Key Result 3: Achieve trial to paid ratio of over 50%
Product Discovery OKR Examples
Objective: Our users are excited about what we‘re building next.
Key Result 1: JIRA integration User Research, Ideation, and
Validation of most promising ideas.
Key Result 2: Test three new research techniques which capture
user excitement.
Objective: Activate user-testing of our product

Key Result 1: Conduct 21 face to face user testing & interview
sessions
Key Result 2: Receive 15 video interviews from Usertesting.com
Product Goals -
Product Goal Resources
Here are some additional resources that have either inspired my

own work over the years or are great deep dives into some specific
areas of setting Product Goals.
Why the secret to success is

setting the right goals by
John Doerr
WATCH ON YOUTUBE
Product Goals -
How Ambitious Should your
OKRs Be? by Felipe Castro
Quote from the article:
“Think of stretch goals as goals that are so hard that make the team
rethink the way they work, ask hard questions and have the difficult
conversations that have been avoided. Stretch goals make teams
wonder how far they can go. In fact, in a meta study of 35 years of
empirical research, goal-setting theory pioneers Edwin Locke and
Gary Latham found scientific evidence that shows that “the highest
or most difficult goals produced the highest levels of effort and
performance.”
READ THE ARTICLE
Don't Let Your North Star

Metric Deceive You by Brian
Balfour, Shaun Clowes, &
Casey Winters
“The search for one key metric for a complex ecosystem like
Pinterest over-simplifies how the ecosystem works and prevents
anyone from focusing on understanding the different elements of
that ecosystem. You want the opposite to be true. You want
everyone focused on understanding how different elements work
together in this ecosystem. The one key metric can make you think
that is not important.”
READ THE ARTICLE
Product Goals -
How to fix Your Product
Goals for Better Human
Outcomes by Rob Boyett
"So, product goals and metrics – the tools that allow you to build
design foundations and shape a strategy. These often-confused
bedfellows can set you up for problems later on, because metrics
are not goals. You know that, right? Tech entrepreneur Avichal
Garg puts this very well in his aptly named piece Metrics: “The
biggest risk in creating a metrics-informed culture is that over time,
people conflate metrics and goals.” Avichal goes on to say: “If you
lose sight of the value you are ultimately creating, you can move
metrics for the sake of moving metrics.” For clarity, goals can be
summarised as an aspiration to create real value for customers. A
metric is a proxy for that value, an abstraction that allows you to
track progress toward a goal."
READ THE ARTICLE
Product Goals -
5 Ways Your Company May
Be Misusing OKRs by Itamar
Gilad
"But here’s the thing - OKRs are just containers for goals. They serve
bad goals just as well as they do good goals. In fact, of all the
management tools, OKRs are the easiest to misuse, overuse and
abuse - many companies fall into this trap. This is a major problem
because bad OKRs can amplify the issues the org is troubled with
rather than fix them."
READ THE ARTICLE
Empower Product Teams

with Product Outcomes, Not
Business Outcomes by Hope
Gurion
"Product teams struggle to drive business outcomes because many
companies haven’t taken the time to define their strategy. Marty
Cagan highlighted this in his recent post “Product Strategy –
Focus.” Cagan laments that many companies think they are
prioritizing and strategically focused when in fact the opposite is
true. He quotes Richard Rumelt, author of Good Strategy Bad
Strategy: “Good strategy works by focusing energy and resources
on one, or a very few, pivotal objectives whose accomplishment will
lead to a cascade of favorable outcomes."
READ THE ARTICLE
Product Goals -

Product Goals - Using Objectives and Key Results OKRs For Agile Teams 2020 v2

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Product Goals - Using Objectives and Key Results OKRs For Agile Teams 2020 v2

Uploaded by

Copyright:

Available Formats

Using Objectives and Key

What Product Goals are and why they matter

Let’s get started.

Product Teams certainly spend a significant amount of time with

That’s what differentiates effective Product Goals from setting

A Primer on Product Goals Using Objectives and Key Results

Combining (OKRs) and Product Goal Examples

Product Goals Resources

In this Chapter I want to introduce the basic concept of Product

What are Product Goals?

And while Product Strategy can also include high-level numbers to

With these things in mind, let’s settle on a working definition for

Product Goals Definition

Product Goals are a set of tangible and measurable

1. What are the essential problems your product is solving for

I like to visualize the answers to these questions using

The point is not to create a McKinsey-level company strategy. But

In general, I like to differentiate the main disciplines of Product

1. Product Purpose/Vision/Mission and Product Strategy

Arriving at the “right” set of Product Goals is a journey that

Let's look at a b2b example first. Assume you're building analytics

For example, account managers may be struggling with how

"How might we speed up the client reporting process of results

If you're shipping a solution for that problem, you want to know

From a qualitative perspective, you might utilize a modified

From a quantitative perspective, you could look at metrics like

What are Objectives and Key

Qualitative and inspirational

OKRs combine the best aspects of goal setting into one

The 'invention' of OKRs is often credited to Andy Grove during his

Here’s an example of an OKR set:

Objective: We are an integrated and mature platform solution

A typical cycle for OKRs is a quarter. Smaller companies could

Moreover, even though OKRs don't necessarily need to cover ALL of

By design, effective Outcome-OKRs don't talk about features.

For teams, it means focusing on the (most critical) problems first to

The process of defining OKRs should involve all levels of a company.

However, there's a common misbelief that OKRs come with

Now, before we go further, let’s go over what I mean when I talk

To me, an Outcome describes a measurable change in behavior

An Output, on the other hand, is an artifact that has been

OKRs can work with either Outcomes or Outputs. As with every

But there’s more to shifting to Outcome-based Product Goals in

Putting Outcomes into practice requires changes to your processes

Building digital products can often seem to be all about pushing

Agile Product Teams experience the biggest additional value from

Using Impact Mapping to

As a quick recap, here are my five levels of Impact Mapping:

WHY - The Impact-level goal that matters to the whole

If your team has established Outcome-oriented Key Results, those

Because you (hopefully) know which Outcomes in the form of your

These ideas (along with the following experimentation) could have

A more fitting approach for planning your efforts is based on so-

You can also compare themes as the parent element of specific

1. NOW - Ideas that have been validated, specified in more detail,

Examples for a theme could be things like 'User Growth,' 'Revenue,'

C. Todd Lombardo delivered a great presentation on this modern

There's a time and place for date-based release plans.But

Combining OKRs and

1. Is this a problem worth solving?

Just as with Objectives and Key Results (OKRs), I prefer to help