The Product Goal was formally added to the Scrum Guide in its 2020 update, and its relationship to a broader product vision is genuinely easy to blur, since both operate at a level above individual Sprint Goals. The distinction is worth being precise about, because conflating them tends to produce Product Goals that are either too vague to guide sprint-level planning or too narrow to provide the medium-term direction the concept is meant to offer.
Where it sits in the hierarchy
A product vision is the long-term aspiration: where the product is ultimately headed, potentially years out. A Sprint Goal is the immediate, two-week (or however long the sprint is) objective. The Product Goal sits between them: a medium-term target, typically spanning several sprints, that gives the Product Backlog genuine coherence and direction beyond just "whatever's highest priority in the moment."
Without an explicit Product Goal, a Product Backlog risks becoming a loosely ordered wish list, reprioritized reactively sprint to sprint based on whatever feels most urgent right now, without any sustained direction connecting one sprint's work to the next. The Product Goal is what gives a sequence of sprints coherence as a connected body of work moving toward something specific, rather than a series of disconnected two-week efforts.
What makes a Product Goal genuinely useful, versus decorative
A working Product Goal should be specific enough that it's possible to say, with reasonable confidence, whether the team has achieved it or not once enough sprints have passed. "Improve the product" fails this test completely: it can never be definitively achieved or missed, because it's not falsifiable. "Enable self-service onboarding for new customers with fewer than 50 employees, without requiring sales team involvement" passes it: there's a genuine, checkable answer to whether this has been accomplished.
The Product Goal should also be achievable within a reasonably foreseeable number of sprints, not an open-ended aspiration with no natural endpoint. Once a Product Goal is achieved (or genuinely determined to be unachievable and abandoned), the Scrum Guide expects the Product Owner to establish the next one, keeping the backlog perpetually oriented toward a concrete, current target rather than drifting without one.
How it should actually be used day to day
Sprint Planning should reference the current Product Goal explicitly when selecting Sprint Backlog items: does this sprint's work meaningfully advance the Product Goal, or is it disconnected from it? A team that can't answer this question for its current sprint's work has either lost sight of its Product Goal in practice, or has a Product Goal too vague to actually guide this kind of decision, and either problem is worth surfacing and addressing directly rather than let the disconnect persist silently.