Product goal is a commitment to the PB but crafted by PO not the team . How often can this change ? How can we estimate how many sprints can it take to be fulfilled ? Shall we have also a kind of timeboxing or cancellation if become obsolete ?
The Product Goal can change as often as the sense of product direction needs to change It's in the Product Backlog, so forecasts about completion will depend on the rate of progress and how it is measured, and where the Goal is found in relation to the items needed to meet it.
A Product Goal must be fulfilled or abandoned before taking on a new one. If it helps to manage things effectively, a Scrum Team can timebox matters or implement a kind of cancellation policy.
Does all items in PB have to support product goal or some of them may be independent?
A Product Goal should give a sense of direction over multiple Sprints. Not all of the work on the Product Backlog needs to articulate to that current Goal. Some or most could be scoped for later implementation, and as an emergent body of work, may help future Product Goals to evolve and be refined.
So my thoughts are . As product goal is time related (and not timeboxed ) and is planned over multiple sprints of course if somehow it becomes invalid (not obsolete ) after ie 2 sprints then the work and value delivered during those may be off less indeed impact .
empiricism comes after sprint and is related to the product (new increment) . How can measure ie NPS for the product goal ? How can you Inspect my product goal ?
Inspection of the Product Goal occurs when you evaluate the value that the Scrum Team is delivering to the stakeholders. If you are not delivering value, then your Product Goal is probably invalid. You should strive to deliver value to the stakeholders in everything you do. It might be incremental value but the Product Goal is not meant to be short term. It is the goal that your organization hopes to achieve by delivering the product to stakeholders. It will adjust over time as environment, economics, technology advancements take place. For me, satisfying a Product Goal indicates that the product is no longer needed and is a candidate to be discontinued. But as long as the product is providing value to the stakeholders, there will always be something to use as a beacon for the product's life.
Why Satysfying product goal means the product is not longer needed? Once it is achieved, you should select another product goal I guess? Cancelling the product is not related to product goal satisfaction (it may be of course, when product goal is poorly selected, development is guided by wrong product goal/sprint goals and the product does not deliver value for couple of sprints)