Why the Product Goal is NOT the Product Vision in Scrum

• Product Vision: Long-term, aspirational goal that describes how the product or service under development helps the customer achieve their dreams or objectives.
• Product Goal: Medium-term target the business wishes to achieve for the product or service.
• Sprint Goal: Short-term objective that can be accomplished within the timebox of the iteration.

Three Common Mistakes Related to Product Vision

Vision is one of those topics in product management where people think they know what they are talking about, but when you start to ask probing questions or ask for specific examples, it is clear they have misunderstandings. In my experience, people tend to miss three key concepts related to product vision:

1. Too much focus on the business: The best product visions describe how the future state of the product benefits the customer and their needs. Of course, the business can have a vision of what they want from the product, but the customer’s vision must be put first. If we can deliver on the customer’s vision of success, we increase the likelihood of delivering on the business’ vision.
2. Too little imagination: Product visions should be aspirational and, as result, remain just out of reach for the business. That is OK because the product vision should motivate and inspire the product development team to discover new ways to serve the customer — not necessarily something that is easy and comfortable to achieve. 
3. Too many words: Editing and wordsmithing is crucial for an effective product vision. My recommendation is ten to fifteen words. When the vision exceeds fifteen words it is no longer inspirational or aspirational and probably has lost sight of the customer. This is often the case when the vision is trying to describe the product’s value proposition or has become a dumping ground to enumerate all the features and technologies in the product. Describing the value proposition and/or core capabilities of the product is important, but a vision statement is not the right tool. 

Frameworks for Creating Product Vision

There are a lot of great frameworks you can use to create a product vision: the classic Innovation Game® Product Box, Gamestorming’s Cover Story, Simon Sinek’s Golden Circle, or whatever you have used in the past. The key to writing an effective vision statement centered on the customer’s aspirational goals, in fifteen words or less, is to focus on the impact you seek to make. In our Certified Scrum Product Owner course, we share four simple frameworks that help people build concise and powerful vision statements. 

Selected Frameworks for Creating Vision Statements

Introducing the Product Goal

When the Scrum Guide was updated in 2020, Jeff Sutherland and Ken Schwaber introduced a new commitment associated with the Product Backlog called the Product Goal. Here is what the Scrum Guide has to say about the 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… 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 Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.”

There are many elements that I like about this definition — future state of the product, target, long-term objective, etc. — because it sounds like what they are describing is a product vision. Looking holistically at how the term Product Goal appears in the Scrum Guide and how it is used, one gets the sense that the co-creators of Scrum consider Product Goal and product vision as equivalent concepts. I do not agree with their usage and here is why. 

How Product Goal is Different From Product Vision

By definition, a product’s vision can never be realized. As I mentioned above, vision is a long-term, aspirational goal that describes how the product helps the customer achieve their dreams, which means it is perpetually out of reach. If we agree with this underlying principle, then how can this statement ever be true? 

”[The Scrum Team] must fulfill (or abandon) one objective before taking on the next.”

The short answer is that it cannot. 

Then how do we make sense of this contradiction in the Scrum Guide? The answer is by accepting that the Product Goal is NOT a long-term objective but a medium-term planning goal used by the business to steer the direction of the product. The big tell for why I think my interpretation is correct is how Jeff Sutherland and Ken Schwaber refer to the Product Goal as a “target for the Scrum Team to plan against.” Having a single Product Goal that must be fulfilled, or abandoned, before “taking on the next” suggests the Product Goal is a distinct, time-bound destination set by the business leaders. Consequently, the Product Goal becomes a unifying theme which connects all the items in the Product Backlog. 

So you might be thinking, “Who cares? This discussion sounds a lot like one of those conversations Agile coaches get all worked up about but have no real world impact.” Well, the confusion between vision and Product Goal has important implications which need to be clarified. 

Scrum's Approach to Planning Is Decidedly Short-term

For as long as I can remember, the maximum duration of a Sprint has been one calendar month. The reason given for this choice is that “when a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise and risk may increase.” Scrum assumes a usable product increment is put into production at the end of each and every Sprint. This allows the Scrum Team to inspect-and-adapt the product based on market and end-user feedback, which they use to drive the development of the product. Because the Scrum Team is never more than thirty days from this feedback, it also explains why Scrum does not have any long-term planning practices beyond the horizon of a Sprint. 

However, I feel Scrum’s reliance on a planning horizon of one calendar month (or less) has led to an overemphasis on short-term thinking dominated by the delivery of outputs, aka the Build Trap. Since all the attention is spent on the next feature, Product Owners and product managers spend less time considering how the Scrum Team will deliver on the outcomes that matter to customers and end users. While it is possible to deliver new software functionality in thirty days (or less), in many cases customers cannot realize meaningful outcomes in such a short period of time nor can the business measure the impact of these outcomes. 

With the addition of the Product Goal, I feel like the co-creators of Scrum have recognized the impact of this oversight and have given practitioners a way to incorporate medium-term thinking into their product development efforts. The diagram below is a modification of Mike Cohn’s planning onion and was first published in his 2005 book, Agile Estimating & Planning. It shows how the Product Goal slots into a range of planning horizons Product Owners and product managers take into consideration when building their products and services.

The x-axis represents time — a continuum between now and the future. The y-axis represents those who receive the benefits of the planning – a continuum between the Scrum Team and the enterprise. At the core of textbook Scrum are two planning events: the Daily Scrum, a day-to-day planning event, followed by Sprint Planning, a planning event for an iteration. If we think about the context of Scrum for the last twenty years and the assumption the product is released for feedback at least once a month, these choices in the design of Scrum make sense because Scrum is very team-centric and oriented towards the now. 

As we can see from the diagram, the inclusion of the Product Goal fills in the gap that existed between Sprint Planning and vision. When new Product Backlog items emerge, as they always do, the Product Owner can now use the Product Goal as a standard to evaluate the new requests from the business, customers and the market. If these emergent items support the existing Product Goal, they are incorporated into the Product Backlog. If not, they are rejected.

How Does the Sprint Goal Fit Into All of This? 

According to the Scrum Guide, “the Sprint Goal is the single objective for the Sprint” and represents a “commitment by the Developers” to deliver a usable increment of product to the business by the time of the Sprint Review. It is created during the Sprint Planning event described above.

It is crucial that the Sprint Goal be well-articulated because it is a common goal for the entire Scrum Team. For more about the Sprint Goal, see my article on “Five Steps to Creating a Sprint Goal.”