The Product Goal is the Product Backlog's commitment. It describes a future state of the product, and the rest of the backlog exists to reach it. That relationship runs one way. The goal comes first and the backlog emerges to serve it, not the other way round.
The Guide gives it a specific job, which is to be the target the Scrum Team plans against, and that is what makes it more than a statement of intent. Sprint Planning opens with why the coming Sprint is valuable, and the answer is expected to connect to the Product Goal.
The backlog emerges to fulfil it
The Product Goal sits in the Product Backlog, and the rest of that backlog emerges to define what will fulfil the goal. The word emerges is doing real work there. It says the backlog is not written in advance and then executed, but grows as the team learns what reaching the goal actually requires.
It also hands refinement a criterion. An item that would not move the product toward the current Product Goal has to justify itself on some other ground, and much of what accumulates in a backlog cannot. Ordering gets easier for the same reason.
One at a time
This is the part these exams press on. A Scrum Team holds one Product Goal at a time, and must fulfil or abandon it before taking up another. The reasoning is practical rather than dogmatic. A team steering toward three destinations is choosing between them implicitly every day, at the level of individual tickets, where nobody can see the decision being made.
A single goal is also what makes a Sprint Goal possible. Serving three targets means dividing each Sprint between them, and the single objective for the Sprint decays into a summary of unrelated work. The constraint is on the team's attention rather than on the size of the ambition, since one Product Goal may take many Sprints.
Abandoning is a real outcome
Fulfil or abandon is a genuine pair, and abandonment is not the failure case. A Product Goal is a bet placed with what was known at the time. Evidence arrives every Sprint, and some of it says the target is no longer worth reaching because the market moved or the early releases showed that nobody wanted the thing.
Abandoning openly is the healthy version. The alternative is a goal nobody believes in sitting at the top of the backlog while the team quietly works around it, which destroys the transparency the goal was there to provide. The decision belongs to the Product Owner, who is accountable for developing and explicitly communicating the Product Goal.
How it differs from the Sprint Goal
Both are commitments and they attach to different artifacts. The Product Goal is the commitment for the Product Backlog and the Sprint Goal is the commitment for the Sprint Backlog, so one says where the product is heading and the other why this Sprint is worth running. A Sprint Goal nobody can connect to the Product Goal signals either drift or a stale goal.
They differ in how they end. A Sprint Goal ends with the Sprint whether or not it was met, and unfinished work returns to the Product Backlog, while the Product Goal carries on for as many Sprints as it takes. The Sprint Goal is created by the whole Scrum Team in Sprint Planning, and the Product Goal is the Product Owner's accountability.
What the Guide leaves open
Scrum says what a Product Goal is for and almost nothing about its shape. There is no timebox, no required format, no rule that it be numeric, and no stated number of Sprints it ought to take. Writing one as an objective with key results borrows a technique from elsewhere, which is permitted and not required.
That silence gets examined. An option offering a rule such as a Product Goal must be achievable within a quarter is describing a local convention rather than the framework. What Scrum does fix is who is accountable for it, that there is one at a time, and that the backlog emerges from it.