Struggling with Product Goals? Don’t worry, I’ve got you covered!

Understanding the new kid on the block by turning to our trusty old friend the Epic

Published in

Serious Scrum

9 min readDec 7, 2020

With the release of the 2020 Scrum Guide, Scrum practitioners all over the world are suddenly confronted by three novel commitments:

Product Goal
Sprint Goal
Definition of Done

The purpose of these three commitments is to “Reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders”. Especially the addition of the Product Goal seems to have left many Scrum practitioners stumped and confused.

I receive a lot of messages asking how to deal with Product Goals. Here are some examples of typical questions I get asked:

What is the optimal time horizon for a Product Goal?
How far ahead in time should you create Product Goals?
How should you formulate a Product Goal?
How do you split up a Product Goal into Sprint Goals or Product Backlog Items?
Can Product Goals be equal to Sprint Goals?
Is the Product Goal the same as a Product Vision?

For the Sprint Goal and Definition of Done, I receive far fewer questions. That’s because these two aren’t new, just the fact they are now presented as a commitment is novel. I would argue they already were commitments in the previous version of the Scrum Guide. The new Scrum Guide makes explicit what was already implicit in practice.

Many Scrum practitioners seem to struggle with the appearance of the three commitments. The word commitment leaves a bad aftertaste for them. I don’t get what the fuss is about. Commitment is one of the Scrum values. What is the point of having Commitment as a Scrum Value, if you’re not allowed to call anything a commitment?

In this article, I’ll answer all the questions I presented above, but let’s first refresh our memory with the Scrum Guide’s Product Goal definition.

What is a Product Goal?

Here’s how the Scrum Guide defines a Product Goal:

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against — Scrum Guide 2020

To put it in simpler terms:

The Product Goal is an outcome you aim to achieve.

What is missing from this definition, and also from the Sprint Goal definition:

The why of the outcome should be clear. Why does this outcome matter to our customers and the business?

In the army, a combination of a desired future state, and a why, is called the Commander’s Intent. Here is how the British Army defines the Commander’s Intent:

“Intent is similar to purpose. A clear intent initiates a force’s purposeful activity. It represents what the commander wants to achieve and why; and binds the force together; it is the principal result of decision-making. It is normally expressed using effects, objectives and desired outcomes….The best intents are clear to subordinates with minimal amplifying detail.” — British Army Doctrine

In the military, every mission is accompanied by a Commander’s Intent, to allow those on the ground to make better decisions as the situation evolves and unfolds. It prevents following the plan to become more important than meeting the objective.

Here is the Commander’s Intent from D-Day:

To secure key bridges, road junctions and other locations in Normandy that would allow the ground invasion forces to advance inland.

As you can see, the Commander’s Intent consists of two essential parts:

Outcome — “To secure key bridges, road junctions, and other locations in Normandy.”
Why it matters — “Allow the ground invasion forces to advance inland.”

If you don’t understand why the outcome matters, you won’t be able to make the best decisions if circumstances change. Imagine you’re part of D-Day, and all bridges would be bombed to burning rubble. It would no longer make sense to secure those locations. But you would only be able to draw this definitive conclusion if you understood why securing them mattered in the first place.

Now let's turn to the following sentence in the Scrum Guide that explains where you keep track of Product Goals:

The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal — Scrum Guide 2020

The Product Goal is part of the Product Backlog and needs to be broken down into smaller parts that will constitute the what. Is this all starting to sound familiar to you?

The Product Goal is an Epic

I would argue nearly everybody who uses Scrum is familiar with Epics. Epics are large chunks of functionality that are too big to work on directly. You first need to break Epics down into smaller pieces first that fit in a Sprint. Then you plan and work on those smaller slices.

If you want to know more about Epics, I can highly recommend reading Mike Cohn’s post where he explains User Stories, Epics, and Themes.

Now Product Goals suddenly don’t sound so mysterious and unfamiliar anymore, do they? How do you formulate Epics, so they are expressed as Product Goals?

When you formulate an Epic, you need to clearly explain the Epic’s Intent:

The outcome you’re trying to achieve. You can then also use this to ultimately validate whether the Epic achieved the desired result.
Why this outcome matters to our users and our business.

Once you cover these two elements, the Epic can easily be broken down into smaller chunks, which can be worked on directly.

Armed with this new way of looking at Product Goals, let’s start answering the important questions at the top of this article one by one.

What is the optimal time horizon for a Product Goal?

You can have big Product Goals, which I call super-Epics, that need to be further broken down into smaller Epics, sometimes across multiple teams. Unless you are 100% sure the big Product Goal is valuable, it makes no sense to break it down completely and plan it ahead of time. You first need to gain confidence that it is valuable by building something small and getting feedback.

The best way to achieve this is by formulating a small Product Goal. By keeping it small you reduce risk, uncertainty, and increases confidence your big Product Goal is valuable. Achieving the small outcome first gives you feedback on whether doing the rest will still make sense.

In short, as a guideline, it is okay to have big Product Goals, but you have to plan one step at a time. Only if the first step takes you in the right direction does planning further steps make sense. When you have validated confidence what you’re doing is valuable, then you can plan a few steps ahead. But many people overestimate the amount of value confidence they have, actually backed up by evidence and data.

If you keep your Product Goal small, you will be able to get feedback from the market quicker. Looking at it from this perspective, smaller is better. By keeping Product Goals smaller, the Empirical core of Scrum shines. You will make decisions based on what you learn and discover, not just the limited knowledge you can have before starting the work.

How far ahead in time should you create Product Goals?

When Product Goals are created, they are shaped based on your current understanding. When doing complex work, more is unknown than known. As a result, creating Product Goals too far ahead of time will lead to unnecessary waste.

As I’ve written before in my article ‘A large Product Backlog is pointless’:

“You should treat your Product Backlog like milk: you should have just enough for the near future but no more. Otherwise your Product Backlog will become stale and it will take effort to make fresh again.”

The same applies to your Product Goals, as they are part of the Product Backlog too. By keeping the list of Product Goals short and fresh, you will always have Product Goals shaped by the latest and greatest insights, and you prevent waste by having to rework, polish, or remove them.

How should you formulate a Product Goal?

I came up with the handy FOCUS acronym for formulating Sprint Goals. You can use the same acronym to check whether your Product Goals are formulated in the best way:

Fun
Outcome-oriented
Collaborative
Ultimate
Singular

Fun. Keeping it exciting and uplifting will motivate and inspire your Scrum Team to go the extra mile. Give your Product Goals a fun title. This keeps your Product Goals memorable and gives your team an easy hook to drop it during a conversation.

Outcome-oriented. Be geared towards a valuable outcome.

Collaborative. The result of your whole Scrum Team working together and reaching an agreement.

Ultimate. The final explanation, providing the why behind what you aim to achieve. By understanding why the outcome matters to customers and the business, your Scrum Team will have the best understanding to make the right decisions if circumstances change.

Singular. Set a single, unifying, and common goal to improve teamwork and collaboration.

Using this acronym, you will have an easy checklist to check whether your Product Goals are good enough.

How do you split up a Product Goal into Sprint Goals or Product Backlog Items?

If you know how to express Product Goals and break down Epics into smaller chunks, then the only hurdle you still need to take is to formulate a Sprint Goal. This was something you also had to do in the previous version of the Scrum Guide, so I won’t cover more ground on this topic in this article. I’ve written many articles on Sprint Goals, which will help to craft them the right way.

Here are a few articles to help get you started:

Now let’s try to answer the final question I asked at the beginning of this article. I hope after reading this article, you will be able to answer it on your own.

Can Product Goals be equal to Sprint Goals?

The answer is a resounding, yes! You may be able to complete an Epic in a single Sprint after splitting it up. Therefore it is also possible that the Sprint Goal is equal to the Product Goal.

Is the Product Goal the same as a Product Vision?

No. A Product Goal is a concrete step that brings you closer to realizing your Product Vision. The Product Backlog can contain multiple Product Goals, even though the Scrum Team can only work on a single Product Goal at once. The Product Vision ensures there is coherence between Product Goals, so completion of a Product Goal moves you in the right overall direction of your Product Vision.

Reframing Product Goals as Epics allows Scrum Teams to tap into their existing body of knowledge

Before Product Goals were introduced, I always framed Epics as an outcome together with a why. We would then break down the Epic into smaller pieces by collaborating and discussing it with the Scrum Team. The only difference is that instead of an Epic, we now call it a Product Goal.

I hope this article will make you think differently about Product Goals and look at them with less bewilderment. You’ve probably been working with Epics already for many years. Tap into that existing knowledge, and use it to deliver even more value by phrasing your Epics as Product Goals.

Whenever you formulate a goal, the two most important things are:

What is the desired outcome?
Why does this outcome matter?

By understanding these two elements, you’ll be able to develop a better course of action, no matter what happens. Adjust your existing Epics by phrasing the desired outcome, together with why it matters, and you’ll be able to hit the ground running with Product Goals.

It is important to keep in mind, just phrasing your Epics the right way isn’t sufficient. Aiming to achieve a Product Goal isn’t good enough. You need to revisit what you actually achieved to check whether you hit the initial target.

It’s not about what you build, but how it is received by your users.