Skip to main content

Product Goal

November 18, 2020
This is part #10 of 59 in the series Scrum Guide 2020 Updates
Stepping stone
Think of Product Goals as a stepping stone in the river of complexity

One of the more challenging aspects of Product Management is to create a tangible relationship between the work we do today and the business strategy. Product Goals are an often overlooked mechanism that can help you in this area.

“If you spend too much time thinking about a thing, you’ll never get it done. Make at least one definitive move toward your goal.” — Bruce Lee

With the release of the 2020 version of the Scrum Guide, we now have Product Goals but what are they? Well, they are not new, lets take a trip down memory lane to the year 2009 and the book “The Toyota Kata” by Mike Rother. 

The Toyota Kata
The Toyota Kata

At Toyota there is a clear difference between where we want to go, and how we get there. Setting measurable goals towards the next target condition is a concept that resonates well with the idea of Product Goals.

So, what is a Product Goal?

“Product Goals are measurable stepping stones designed to push the threshold of knowledge towards our Product Vision.” — Product Samurai

A way to think about Product Goals are manifestations of your Product Strategy. The diagram I scribbled below may help to explain.

The union
See the Professional Scrum Product Owner book for more details.

Where the Business Vision is often holistic and describes a moonshot, the Business Strategy serves to make that more concrete. How are we going to achieve this? what are our goals for the next 6 quarters? next quarter? what does success look like? Most companies use a form of OKR (Objective and Key Results), KRA (Key Result Areas) or KPI (Key Performance Indicators) to forecast and set business goals.

Akin to that, Product Goals provide measurable guidance towards the Product Vision. If your company only has a single product or service, these will be very much alike. Product goals connect the work on the Product, (as recorded in the Product Backlog,) to the Product Vision.

What are some elements of Product Goals?

Often I find Product Goals to be either fluffy, or unattainable. Neither really helps, so what are some elements that make a Product Goal great?

  • They are set, meaning actually written down not just verbally passed on. SMARTIVEST, whatever is your favorite.
  • Product Goals are stepping stones towards the Product Vision. Scrum Teams and stakeholders can “see” how they connect.
  • Market driven, not Product Backlog driven. Product Goals are a result of responding to emerging market conditions rather than an abstraction of work.
  • They are achievable. This is where many of the OKR goals go off the rails. Stretched goals are a great way to grow but often teams simply don’t see themselves getting there. Make sure your goals can be achieved.
  • They can be measured. The EBM framework provides some excellent metrics as do Pirate or HEART metrics.
  • They are ordered, but I would go even further and suggest  “The Highlander Rule.” Focus means that a product team should only be pursuing a single goal at the time. 
  • They communicate intent and not solution. It is better to talk about problems to solve than work to do.

How do I create Product Goals?

“In any way that works for you,” would be the consultant answer. There is no particular law or rule, but there are some things that we have seen working better than others.

  • Set Product Goals together, leveraging the collective knowledge of the group but also as a first step towards acceptance and sharing of the goals. If you find this difficult to facilitate, have a look at liberating structures.
  • Make sure you communicate the Product Vision before talking about goals, make sure we all have the same North Star. In the book “The Product Samurai” is a great framework which you can also find here.
  • Next focus the discussion using “the lens of the product manager”. You don’t need the exact format listed below, but make sure you take an outside in view of the goals you are setting.
Product Owner lens
The Lens of the Product Manager
  • When do I set a Product Goal? it could be as late as Sprint Planning, but I would not advice it. Try aligning your Product Goals with quarterly business reviews. Though goals could be shorter or longer, it makes sense to maintain a cadence that allows for alignment with changes in the business, whilst maintain a focussed mission for a longer period of time.

What is a good example?

There are many ways to capture product goals. Lets take an example from Melissa Perri

Melissa Peri's Product Goals Canvas

What I like about this example is that she clearly distinguishes the Product Vision from the Product Goal (target condition). This canvas also aims to explain the particular challenge that is to be overcome, though it is very likely that over time we will get new insights on what is actually blocking us.

Inspect and adapt?

In the complex domain, it is hard to define truths. More commonly they are the result of emerging patterns, hence frequent inspection and adaptation. So obviously we need to inspect and adapt our goal right?

Well yes and no. Obviously if a goal is no longer attainable, (e.g. in the Netherlands the law was changed to make Uber’s goal impossible) it can be abandoned and a new one can be formulated. Likewise if we discover that the goal was misunderstood (e.g. what does driver mean? and what is a city) we can refine the topic to create a better understanding.

But a Product Goal is a mission for the team to work on, we expect them to be committed to it, so changing the definition would be odd. Think of the commitment to Product Goals as you would to the commitment of marriage, renegotiating what commitment means midway is bound to bring more problems than it’s worth.

More than one?

So can I have more than one Product Goal? Perhaps. It is easy to see that a single team pursuing 25 Product Goals has set itself up for failure. However if you have multiple teams working on the same Product, it might be possible. The Scrum Guide is pretty clear on what you should do, or rather what you should try to avoid:


Focus really pays off, so for a single team I would say no and for multiple teams “perhaps”. (and 25 goals is a bad idea in any situation) If you find yourself chasing multiple goals, ask yourself the question whether it is truly a single product.

Final thoughts

Product Management is hard, but mechanisms like Product Goals can really help to make your life easier. If you’d like to experience the all-new Professional Scrum Product Owner-Advanced class, go to to find a class in your area. If you’d like to participate in one of my classes, check out the Xebia Academy page for more information or drop me a message.







What did you think about this post?