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:
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.
Post a Comment or Ask a Question
Many thanks for this great article, including your updated version of the GO Product Roadmap! With regard to the question of a compound product goal (with a user part and a business part): How do you feel about phrasing the Product Goal in a way that both clarifies and strengthens the aspect of connecting business value and user value? After all, we probably have an implicit but critical hypothesis/assumption about this connection. Using your example, a basic format could be something like this:
1. (Providing value by) helping users understand their eating habits (will lead to) ==> an initial user base (business value).
2. (Providing value by) helping users improve their eating habits (will lead to) ==> a growth in user base (business value).
3. (Providing value by) helping users get fitter (will lead to) ==> generation of revenue through in-app purchases (business value).
Not only would this be quite in line with the Scrum Guide 😉 asking us to “focus on one objective at a time”, and support the agile spirit of putting user value at the center. It may also reduce the risk of pursuing vanity metrics with regard to business value – and the waste that goes along with them. I also feel that a connective phrasing like this – especially of the third product goal – might give valuable food for thought about the “mechanics” (“engage” in getting fitter?) we assume behind the connection between providing user value and generating business value (in the end, no less than our business model?).
What do you think?
You’re welcome and thank you for your feedback and suggestion. The format you suggest looks interesting, and I recommend that you formulate product goals in whichever way works best for the person in charge of the product, the stakeholders, and development team(s). Personally, I like to keep things as simple and easy to understand as possible.
Regarding assumptions and vanity metrics, bear in mind that the content of a product roadmap is based on a validated product strategy in my model. The product goals are therefore derived from or constrained by validated needs and business goals.
Hope this helps!
Thank you Roman. You filled the gap which was created by the new Scrum Guide. In now find the new version of the cadence of goals more precise and convincing, now everything fits together. Thank you for the years of work – afterwards everything looks easy!
You’re welcome Christian and thank you for your feedback. I am glad that you found the article helpful!
Great article Roman! And thank you for helping us grow on this product development learning journey.
You’re welcome Alejandro and thank you for your feedback. I am glad that you found the article helpful.
Very nice article (and podcast). Thank YOU very much. This is very useful to me!
I particularly like, agree, and use the approach you mention about pairing our Backlogs (especially the Portfolio Backlog) to a corresponding Roadmap. This something I typically ask the Product Owners / Managers to do, by working on the Roadmap first, before even using our agile work item tracking tool to capture all this.
I especially liked the part about integrating the Product Goal into the Roadmap the way you propose. I have never done this (at least not explicitly) but I agree with you, and think capturing it this way is valuable.
I’m a fan of your work. Please keep up with these articles.
Thank you for your feedback Julio. It’s great to hear that you liked the article and podcast episode.
Hi Roman first I would like to say great article we I have shared with other BA’s I work with. Your example is perfect for a Patient Portal I am working on at present. I have used Theme io describe Product Vision.. I have a standard framework which I use to present each product, called TEPUI (Theme, Epic, Process, User, Information). From process as a user activity I derive a product feature.
Thank you Chris for sharing your feedback and the approach you use to derive a product feature. I am glad that you found the article helpful!