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 that state, so the goal comes first and the items emerge to serve it.
The Guide gives the Product Goal a specific job, which is to be the target the Scrum Team plans against, and that job is what makes it more than a statement of intent. Sprint Planning opens on why the coming Sprint is valuable, and the answer is expected to connect to the Product Goal.
The backlog emerges to fulfil the Product Goal
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 grows as the team learns what reaching the goal actually requires, so a backlog written out in full at the start has already stopped describing the work.
The same word 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, because the question of what comes next has an answer the whole team can check.
A Scrum Team holds one Product Goal at a time
All of that depends on there being one goal, and the limit of one is the constraint assessment questions press on hardest. A Scrum Team holds one Product Goal at a time, and must fulfil or abandon it before taking up another. The reason is practical. When a team holds a goal for checkout conversion, a goal for API latency and a goal for migrating off a legacy billing service, it chooses between them every day, one ticket at a time, and nobody ever sees the choice happen.
A single Product Goal is also what makes a Sprint Goal possible, because a team serving three targets has to divide each Sprint between them, and the single objective for the Sprint then decays into a summary of unrelated work. The constraint applies to the team's attention, since one Product Goal may take many Sprints and may be as ambitious as the Product Owner likes.
Abandoning a Product Goal is a real outcome
Fulfil or abandon is a genuine pair, which means abandonment is one of the two ways a Product Goal is supposed to end. A Product Goal is a bet on what was known at the time, and evidence arrives every Sprint. Some of that evidence says the target is no longer worth reaching, because the market moved or the early releases showed that nobody wanted what the goal described.
The healthy response is to say so and abandon the goal. 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 the Product Goal differs from the Sprint Goal
Both are commitments, and they attach to different artifacts. The Product Goal is the commitment for the Product Backlog, so it says where the product is heading. The Sprint Goal is the commitment for the Sprint Backlog, so it says why this Sprint is worth running. If nobody can connect a Sprint Goal to the Product Goal, the Sprint Goal signals either drift or a stale Product 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.
The Scrum Master's part in the Product Goal
Both commitments leave the Scrum Master outside the decision and inside the conditions for making it. The service the Guide names is helping the Product Owner find techniques for effective Product Goal definition, so the help is with the method a Product Owner uses to arrive at a goal. Choosing the goal, wording it and abandoning it stay with the Product Owner.
The Scrum Master's interest is narrower. One goal has to exist, and the team has to know what it is. Sprint Planning opens on why the coming Sprint is valuable, so a team unable to answer that has either no Product Goal or one nobody has communicated, and the event then produces a Sprint Goal that summarises whatever was selected.
Three live goals produce the same symptom from the other direction. In that case the impediment sits with the Product Owner, so raising it there comes before coaching the team through another thin Sprint Goal.
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 Scrum permits and never requires.
That silence gets examined. When an exam option offers a rule such as a Product Goal must be achievable within a quarter, it is describing a local convention and the framework has no such rule. Scrum fixes only three things about the Product Goal. The Product Owner is accountable for it, a team holds one at a time and the backlog emerges from it.