Product Goals in Scrum

The 2020 edition of the Scrum Guide introduced a new type of goal, the product goal. This article shares my recommendations to help you as the person in charge of the product set effective product goals.

Listen to this article:

Product Goals Defined

The Scrum Guide released in November 2020 states that “the product goal describes a future state of the product … [It] is the long-term objective for the Scrum team.” It also suggests that “the product goal is in the product backlog. The rest of the product backlog emerges to define ‘what’ will fulfill the product goal.” The product owner is accountable for “developing and explicitly communicating the product goal.” The entire Scrum team is “focused on one … product goal” at a time.

If this definition leaves you scratching your head, don’t worry. Scrum is a simple framework designed to facilitate the development of complex products. It does not intend to prescribe how the practices it offers should be applied. As a consequence, different people have suggested different ways to apply the product goal. Some view it as the product vision, others equate it to the product’s value proposition.

I find, however, that a product goal is best used to describe a specific and measurable benefit or outcome a product should create in the course of the next two to six months. A sample goal might be to acquire users, increase conversion, generate revenue, or reduce technical debt. Such a goal aligns the stakeholders and development teams, and it directs their work.

What’s more, I like to ensure that product goals are connected to the product strategy and its user and business goals. This helps me choose the right product goals and it ensures that meeting a product goal is a step towards creating the desired value for the users and the business, as figure 1 shows.

In figure 1, the vision is the basis for choosing the user and business goals, and the latter create the context for determining the right product goal. At the same token, each product goal acts as the foundation for identifying helpful sprint goals. In other words, the goals are connected and form a cascading set of product-related goals.

Please see my article “Leading Through Shared Goals” and my book How to Lead in Product Management for more information how to effectively use the goals in figure 1, which includes securing the necessary buy-in from the stakeholders and development teams.

Background Story: Readers familiar with the history of Scrum—sometimes lovingly referred to as Scrumtorians—will undoubtedly know that it has contained sprint goals at least since 2002 and a (product) vision since 2004, even though the latter is not mentioned in the Scrum Guide. When I started to work with Scrum in 2004, I could not get my head around the question of how to systematically connect a big, inspiring vision to a tactical, short-term sprint goal. It took me years to come up with the set of goals in figure 1. In hindsight, the set looks disappointingly simple 😉

You can also access the contents of this article on my YouTube Channel:

Sample Goals

To better understand how the goals in figure 1 can be applied, let’s take a look at an example.

In figure 2, I first captured the vision “Help people eat healthily” and then used it to choose the user and business goals “Reduce the risk of developing type-two diabetes; create new revenue source.” In order to determine the right product goal, I asked myself, “What would be a first good step to meet the from the user and business goal?” I consequently chose the product goal “Help the users understand their eating habits and acquire an initial user base.” I then used this goal to determine the right sprint goal. I figured that finding out if users are willing to share personal information when activating the app would be the most important risk to address and hence should be the goal of the first sprint.

Note that I chose to use a compound product goal in figure 2 that has a user part—help the users understand their eating habits and business—and a business one—acquire an initial user base. Both parts are closely connected: In order to acquire a user base, the product must offer tangible value to the users, and a first step to help people eat more healthily is to help them become aware of their current eating habits. You don’t have to work with compound product goals of course, if you prefer to focus your objectives on either the user or the business benefits.

Product Goals and the Product Roadmap

Setting a single product goal is great. But unless you can’t see further than the next few months, I recommend determining the next three to four product goals and capturing them on your product roadmap, as figure 3 below shows.

Figure 3 shows a sample roadmap based on my GO product roadmap template, which contains three product goals. Each goal builds on the previous one thereby nicely progressing the product: The first goal helps the users become aware of their eating habits and creates and initial user base. The second one helps people improve their eating habits and acquires additional users. The third product goal, finally, helps the users improve their overall fitness and generates revenue.

While the Scrum Guide does not mention identifying future product goals and adding them to the product roadmap, I find this practice very helpful: Stakeholders and dev teams usually benefit from understanding how to product is likely to evolve beyond the next two to three months. This helps the individuals create an effective sales and marketing strategy, for example, and to make the right architecture and technology decisions.

Product Goals and the Product Backlog

With a product roadmap in place, I like to select the product goal to be worked on and copy it from the roadmap to the product backlog together with any coarse-grained features that are associated with the goal. This approach is illustrated by figure 4.

The beauty of using a product goal in the backlog is that it focuses the latter, as I describe in my article “The Product Roadmap and the Product Backlog.” This addresses a common issue: Many product backlogs I have seen over the years were too big and too detailed. This made them hard to prioritise and difficult to update, which is bad news as long as your product is young or experiences more than small, incremental changes. In most cases, the product backlogs grew so big because they lacked a measure to decide which items should be added to the backlog and which should not. The product goal is this measure: Only add an item to the product backlog if it helps meet the product goal.

Let’s briefly explore how a product goal might be used on the product backlog. Say I was to start the development of my healthy eating product, I would copy the product goal “Help the users understand their eating habits and acquire an initial user base” into the product backlog together with the features “healthy eating dashboard” and “integration with smart watches and fitness devices.” I’d ask myself which additional features are required to meet the product goal and add these to the backlog. I would the start breaking some of the features into epics and prioritise the product backlog. Finally, I’d refine the high-priority items to be ready to start the first sprint.

As you can tell, I like product goals and find them very helpful, and I would encourage you to try them out if you haven’t used them.