7.2 Product Goal Management
Key Takeaways
- The Product Goal is the long-term objective for the Scrum Team, describing a future state of the product
- The Product Goal is contained in the Product Backlog; the rest of the backlog emerges to define what will fulfill it
- A product has only one Product Goal at a time; the team must fulfill or abandon it before adopting the next
- The Product Goal is the commitment for the Product Backlog artifact (Sprint Goal commits the Sprint Backlog; Definition of Done commits the Increment)
- Sprint Goals are stepping stones toward the long-lived Product Goal; the Product Goal is not re-created every Sprint
The Product Goal as a Long-Term Objective
The Product Goal is one of the most heavily tested 2020 Scrum Guide concepts in this focus area, precisely because it was new in the 2020 revision. Before 2020 there was no formal Product Goal at all, so the exam writers lean on it to separate candidates who studied the current Guide from those relying on older 2017 knowledge. The Product Goal describes a future state of the product that serves as a long-term objective for the Scrum Team. It gives the team a meaningful target to plan and progress toward, and it provides context and purpose for both the Scrum Team and its stakeholders.
Quick Answer: The Product Goal is the long-term objective for the Scrum Team. It lives in the Product Backlog and is that artifact's commitment. The Scrum Team must fulfill (or abandon) one Product Goal before taking on the next.
Hard Scrum Guide rules
- The Product Goal is in the Product Backlog. It is not a separate document, a slide, or a roadmap artifact. The rest of the Product Backlog emerges to define "what" will fulfill the Product Goal.
- A product has one Product Goal at a time. The Scrum Team must fulfill or abandon the current Product Goal before moving on to the next one.
- The Product Goal is the commitment for the Product Backlog artifact. Each of Scrum's three artifacts has exactly one commitment that reinforces transparency and focus: Product Backlog → Product Goal; Sprint Backlog → Sprint Goal; Increment → Definition of Done.
Why do commitments matter? Commitments exist to strengthen empiricism. A commitment gives an artifact a measurable objective against which progress can be inspected. Without the Product Goal, the Product Backlog would be a list with no shared direction; the commitment is what turns the list into a coherent strategy the team can adapt against each Sprint.
Relationship to Sprint Goals and the Backlog
Think of the Product Goal as the destination and Sprint Goals as the stepping stones along the route to it. Each Sprint Goal is a single, coherent objective for one Sprint; achieving a series of Sprint Goals progressively moves the product toward the Product Goal. The Product Goal itself is long-lived — it is not re-created every Sprint, and it is not the same thing as a Sprint Goal even though both provide focus. The Sprint Goal is created during Sprint Planning and provides flexibility on the exact work; the Product Goal predates the Sprint and outlives it.
| Artifact | Commitment | Time horizon |
|---|---|---|
| Product Backlog | Product Goal | Long-term (one at a time) |
| Sprint Backlog | Sprint Goal | One Sprint |
| Increment | Definition of Done | Per Increment |
Common exam traps
- "A team can pursue several Product Goals in parallel." False — a product has one Product Goal at a time. Splitting into parallel Product Goals (or parallel Product Backlogs for one product) contradicts the Guide.
- "The Product Goal is created during Sprint Planning." Sprint Planning addresses why this Sprint is valuable (the Sprint Goal), what can be done, and how the work will be done — it does not create the Product Goal, which already exists in the Product Backlog.
- "The Product Goal lives in a separate roadmap document." The Scrum Guide explicitly places it in the Product Backlog.
- "Once a Product Goal is set, it can never change." The team may abandon a Product Goal that is no longer worth pursuing; abandonment is an empirical decision, not a failure.
Supporting professional practice
How you discover, frame, and validate a Product Goal — opportunity assessment, product vision, outcome statements, objective-and-key-result style framing — is professional product management practice. The Scrum Guide requires the Product Goal to exist and to live in the Product Backlog; it does not prescribe a template, a format, or a method for writing one. Watch for answers that invent a required Product Goal format — there is none.
Why the Product Goal Strengthens Empiricism
The Product Goal is more than a label — it is the mechanism that makes the Product Backlog transparent and inspectable at the strategic level. Recall the three pillars: transparency, inspection, adaptation. A commitment exists for each artifact specifically to support these pillars:
| Pillar | How the Product Goal supports it |
|---|---|
| Transparency | A single, explicit long-term objective makes the intent behind the backlog visible to the team and stakeholders |
| Inspection | Each Sprint Review discusses progress toward the Product Goal, giving a clear yardstick to inspect against |
| Adaptation | When evidence shows the goal is no longer valuable, the team can adapt — refine, re-order, or abandon and adopt a new Product Goal |
Because the Product Goal is the commitment for the Product Backlog, every item in that backlog should be there to help fulfill it; items that no longer serve the goal become candidates for removal. This is how the Product Goal keeps the backlog from sprawling into an unfocused wish-list.
Worked scenario
A team's Product Goal is "Become the fastest mobile checkout in our market." During Sprint Reviews, stakeholders see Increments and discuss progress toward that goal. Mid-way, data shows checkout speed is already competitive but cart abandonment is driven by trust concerns, not speed. The empirically correct move is not to silently add a second Product Goal in parallel. The team finishes or abandons the current Product Goal and adopts a new one (e.g., "Make checkout the most trusted in our market"). One Product Goal at a time keeps focus intact and the backlog coherent.
Product Goal vs. Sprint Goal — side by side
- Product Goal: long-term, lives in the Product Backlog, one at a time, describes a future product state.
- Sprint Goal: single-Sprint, lives in the Sprint Backlog, created at Sprint Planning, can flex scope within the Sprint.
- Both provide focus and both are commitments, but they operate at different time horizons and must not be conflated on the exam.
Where does the 2020 Scrum Guide say the Product Goal resides?
A leadership team wants the Scrum Team to actively pursue three Product Goals at the same time to "move faster." What does the 2020 Scrum Guide say?
Match each Scrum artifact to the commitment the 2020 Scrum Guide attaches to it.
Match each item on the left with the correct item on the right
Which statement about the relationship between Sprint Goals and the Product Goal is most accurate?