Product Goal - Techniques to define one

The following is my opinion and may not be shared by others.

The Product Goal communicates what the organization wants to the product to become.  It should be defined and maintained as the environments in which the product are used change.  How the information gathered for the purpose of determining that really depends on the reason the product exists.  For example, gathering information for a product used in coal mining would be different than one used for managing payroll.  The company should know how to do the research.  If not, then I would not expect that company to be very successful. Truthfully, the Product Goal should be the easiest of things mentioned in the Scrum Guide to define. 

Consider using a Product Goal Canvas.

Here is my view which is not widely shared: a good Product Goal conveys a Product Vision in the SMARTest terms possible. 

e.g. "this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the Moon and returning him safely to the Earth".

The Product Goal enables validation early and often by means of small empirical experiments (c.f. Sprint Goals), and hence the definition of it is perhaps best thought of as an ongoing activity. There is increasing clarity. Interestingly, the securing of buy-in may or may not be necessary (58% of citizens were initially opposed to the above goal, for example).

Here's my view, which is different from the others.

I've always started with a long-term product vision statement, which is something bold and may take several years to achieve. The vision statement should tie back to corporate goals and strategies. This is, of course, a complimentary practice.

I see the taxonomy as follows:

• Product Vision (strategic, long-term, not required by Scrum)
• Product Goal (intermediate Goal, usually longer than 1 Sprint, required by Scrum)
• Sprint Goal (1 Sprint, tactical, required by Scrum)

From the vision statement, the Product Owner would craft a Product Goal, which would be an intermediate step of one or more Sprints toward the Product Goal. The Product Backlog emerges from the Product Goal. There may be only one active Product Goal at any one time, and for each Sprint Review, the Scrum Team and stakeholders inspect progress towards the Product Goal. They may even question if the Product Goal is the right one. Over time, many Product Goals may be used to get closer towards the vision, yet there can be only one active Product Goal at any one time. Each Sprint Goal would be a tactical stepping stone toward the Product Goal. 

Roman Pichler also has introduced a template and added another dimension: https://www.romanpichler.com/blog/product-goals-in-scrum/

As you can see there are many ways to skin the cat, and perhaps that is why the Scrum framework is intentionally incomplete.

Thank you so much Daniel, Ian and Chris for taking the time to answer my question and for providing your insights, I knew this was a great place to ask!

As the enthousast of evidence based management, I should say that Product goal should be defined based on a long strategic vision: it should depend on the strategic goal of the organisation and reflect both intermediate goals and intermediate tactical goals on the path towards it.

During the path towards a strategic goal, the intermediate goals and even actual Strategic Goal can change, which should be reflected in the definition of Product goal. 

Once defined the product goal should be well formulated. To formulate it properly, the SMART techniques mentioned by Ian  can be employed.

It is worth noticing that the Scrum Guide emphasizes that Scrum is helpful when working on Complex Problems and "A Product Owner orders the work for a complex problem into a Product Backlog".

Therefore, I think it is also useful to step back and look from the Problem perspective. What complex problem are we trying to solve? Is our idea of the Product just one of the possible solutions? What is the quickest way we can validate it?