Setting and Using a Product Goal: The Good and the Bad
When the 2020 Scrum Guide introduced the Product Goal, it gave the Product Backlog something it had often lacked: a single, longer-term objective that the Scrum Team works toward. The Guide describes the Product Goal as a commitment for the Product Backlog — the future state of the product that gives the backlog its reason for existing. A team can only work on one Product Goal at a time, and they should fulfil or abandon it before taking on the next. For distributed teams in early 2021, leaning on a shared written goal mattered more than ever, because you could no longer rely on hallway conversation to keep everyone pointed the same way.
The idea is simple, but it is easy to get wrong. The difference between a Product Goal that pulls the team forward and one that is just words at the top of a document is worth looking at directly.
What a good Product Goal looks like
It describes a meaningful future state of the product — a real outcome for users or the business, not a feature checklist.
It is singular: the team has one Product Goal in focus, so priorities do not splinter across competing ambitions.
Every Sprint can be traced back to it — the team can explain how this Sprint's work moves them toward the goal.
It is measurable enough that the team can tell whether they have reached it, without pretending to forecast the exact date.
It lives in the Product Backlog where the team and stakeholders can see it, not buried in a planning deck.
What a bad Product Goal looks like
It is a restatement of the team's mission — too broad to ever be 'done', so it never focuses anything.
It is actually three or four goals stapled together, so the team quietly works on whichever is loudest that week.
It is a list of features dressed up as a goal, which tells you what to build but not what outcome you are chasing.
It never changes and is never retired, so it becomes wallpaper the team stops reading.
Only the Product Owner has seen it, so the Developers cannot use it to make trade-offs during the Sprint.
How to use it well
Write one Product Goal and make it visible. Put it at the top of the Product Backlog where everyone refers to it, and revisit it in Sprint Planning.
Use it as the filter in Sprint Planning. The first question for any candidate work is whether it moves the team toward the Product Goal; that keeps the Sprint Backlog coherent.
Let the Sprint Goal ladder up to it. Each Sprint Goal should be a concrete step toward the Product Goal, so the two reinforce rather than compete.
Retire it deliberately. When the goal is met — or clearly no longer worth pursuing — say so, then set the next one. A goal that is never closed loses its meaning.
A Product Goal is not paperwork. Used well, it is the thread that lets a Scrum Team say no to good-but-off-target work and yes to the few things that actually move the product forward. Write one, keep it singular, point every Sprint at it, and retire it honestly when its time has come.
If your teams are running Scrum but struggling to connect day-to-day Sprints to a real product direction, XNM's program & project delivery advisory can help.