The Scrum Guide defines a product as a vehicle to deliver value, with a clear boundary, known stakeholders and well defined users or customers. Vision sits above that definition. It describes where the product is going over a horizon longer than any single Product Goal.
Vision is not part of Scrum. The Guide names three artifacts and vision is not one of them, it never asks a team to write one, and it offers no format if a team does. That silence is deliberate, since Scrum fixes accountabilities and feedback loops and leaves product strategy to the people who know the market. Everything below is practice grown up around Scrum rather than a rule inside it.
What the boundary decides
A vision written for something that is not a product cannot be acted on, so the boundary comes first. Where it is drawn determines what belongs in one Product Backlog, who the Product Owner is, and which Product Goal applies. A boundary drawn around a team rather than a product produces several backlogs for what users experience as one thing, and then nobody can order the whole.
What makes a vision usable
A usable vision lets the team decide something without asking. That is the test. Given two reasonable options and no chance to convene the stakeholders, does the vision say which one belongs to the product being built? If both options fit it equally well, it is decoration, however well it reads.
A vision that decides things has to exclude something. Naming who the product is for excludes everyone else, and naming what it will be better at accepts being worse at something in exchange. A statement nobody could disagree with cannot settle a disagreement.
Most written visions fail because they aspire without excluding. To delight our customers, to be the market leader, to be the platform everybody builds on. None of these rules anything out, so tomorrow's argument between two features is no easier for having them on the wall. The quick check is to take a decision the team actually argued about last month and ask whether the vision would have settled it.
Vision, Product Goal, Sprint Goal
These form a chain of decreasing horizon. Vision describes the future state over the long term and changes rarely. The Product Goal is the single objective the Scrum Team is currently working toward, and it is fulfilled or abandoned and then replaced. The Sprint Goal is the objective for one Sprint, and only the latter two are defined by the Scrum Guide.
A vision is reached, if it is reached at all, through a succession of Product Goals. Each one is a nearer target chosen because achieving it moves the product toward the vision, and the evidence gathered from each informs the choice of the next. A Product Goal with no vision above it is a target with no reason attached, which makes it hard to tell when it has stopped being worth pursuing.
Telling a vision from a revenue target
Doubling revenue in three years is a target rather than a vision. It states how much the business wants and nothing about what changes for anyone using the product, so it can be pursued by raising prices, by dropping the cheapest customers or by building something better. All three satisfy the number and they point in different directions.
A vision describes a future state of the world for the people the product serves, and revenue then arrives as evidence that the state was worth something to them. The order matters. A target treated as a vision makes the number the thing being optimised, and a number optimised directly is usually reached by the cheapest route rather than the best one.
Abstract products
A product may be a service or something less tangible than software. The test is whether it has a boundary, stakeholders and identifiable users, not whether it ships in a box. An internal platform used by other teams qualifies, and its users being colleagues changes who has to be talked to rather than whether the definition applies.