Your Unfit Product Goal and the Product Goal Canvas

We plan a lot in Scrum: There is a daily plan when the Developers think about progressing toward the Sprint Goal during the Daily Scrum. Of course, the Sprint Goal reflects an intermediate target the Scrum team considers valuable to solve their customers’ problems. Moreover, there is the Product Goal, a mid- or long-term objective of the Scrum team. 

The problem is that when Scrum teams already struggle with embracing the concept of the Sprint Goal—first, you agree on the objective of the Sprint, then you pick the work you consider necessary to accomplish it—they most likely also struggle with proper Product Goals.

Let’s check three critical issues Scrum teams have with Product Goals and a practical tool that helps you avoid the mess.

The Scrum Guide on the Product Goal

The Scrum Guide barely delves into the concept of the Product Goal, stating that “[It] describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. ” (Source.) (The Product Goal is the commitment to the Product Backlog, providing transparency.)

Also, the Product Owner is tasked with “developing and explicitly communicating the Product Goal” as part of their Product Backlog management activities. (Source.) 

No further guidance on the Product Goal is available from the Scrum Guide.

Product Goal Anti-Patterns

Given the Scrum Guide’s brevity on the Product Goal, there are three common Product Goal anti-patterns to observe:

1. No Product Goal: There is no Product Goal, or, even worse, the content of the Product Backlog is retroactively squeezed under a made-up “Product Goal,” as the Scrum Guide mandates the Product Owner to define one. This approach extends the bad habit of first picking the work of the Sprint and then figuring out a Sprint Goal that covers most of the work. Again, from a holistic perspective, turning a core part of Scrum’s process upside-down does not help maximize the value of the work of the Scrum team members; it is merely a form of cargo-cult Scrum.
2. Par Ordre du Mufti: The Product Owner decrees Product Goals in a solitary act, excluding the rest of the Scrum team from the process. This behaviour is highly problematic regarding mitigating the risk of a Product Owner falling in love with their solution over the customers’ problems. Therefore, their teammates should provide feedback and expertise to the Product Owner as early as possible, particularly on technical aspects and the Product Owner’s perception of what is valuable to their customers.
3. No Inspection: The opportunity to inspect progress toward the Product Goal during Sprint Review sessions is ignored. Practically, the Product Goal is never inspected or adapted until its completion or abandonment. Many humans crave continuity and routine. However, neglecting one of the four values of the Manifesto for Agile Software Development, here: responding to change over following a plan (Source.), undermines why the team chose Scrum in the first place: solving complex, adaptive problems while mitigating risk.

While the Product Owner is responsible for creating and communicating the Product Goal, it is beneficial to include the rest of the Scrum team in the process, similar to other Product Backlog management tasks. Again, this collaborative approach aims to foster a shared understanding among all Scrum team members about the Why, What, and How of the team’s journey. Also, it reduces the risk of creating technical risk due to a lack of understanding on the Product Owner’s side.

In this regard, Ralph Jocham developed and shared a valuable free alignment tool: the Product Goal Canvas.

Depending on your preliminary work, the time to create the first version of the canvas will vary. For example, if you have already invested in maintaining a Business Model Canvas and know your stakeholders well, it may take 60-90 minutes. On the other hand, it will take much longer if you haven’t done any preliminary work on the product and business side.

Once you create the first version, please regularly inspect and adapt your Product Goal Canvas for as long as you work on the respective Product Goal.

Download: The Product Goal canvas was developed by Ralph Jocham, available as a free download.

License: Creative Commons, Attribution-NonCommercial-ShareAlike 2.0 Generic (CC BY-NC-SA 2.0). 

Conclusion

Take the Product Goal to the Scrum team. No matter that the Product Owner has the final say in defining the Product Goal, it is beneficial to include all Scrum team members in creating the Product Goal to avoid introducing unnecessary technical risk through the backdoor or heading in the wrong direction as a Scrum team. The Product Goal Canvas is one tool that can structure this alignment process.

How are you creating Product Goals? Please share your findings with us in the comments.