What is the Product Vision?
The Product Vision is the starting point in the Product Management cycle:
- It is the ultimate statement of what the organisation is trying to achieve with and for this product.
- It is the goal at which the Product Owner and the organisation they represent are aiming.
- It is the basis of the team’s understanding of the product.
- It explains the business’s aims, context and thinking.
- It helps the team to understand the situation, background and long-range thinking that informs the business and the Product Owner’s decisions.
- It helps the team to ask intelligent questions about what exactly individual stories mean or what individual releases are trying to achieve.
In brief, the Product Vision is your statement of what ultimate success will look like.
Generally speaking, the Product Vision is simply given to the Agile team, so we make no attempt to explain how to create one here. In an Agile organisation the team will be able to comment and advise on the Vision’s technical feasibility and operational viability, but the basic content will be defined in the business or other senior management environment that is ultimately responsible for the product’s success.
Elements of the Product Vision
Every organisation will have its own definition of what goes into a Product Vision. However, what the Agile team need to get out of the Vision can be defined quite clearly. From their point of view, the basic elements of the Product Vision are outlined below, and if you can’t find them in the Product Vision available to you, you will have to discuss your additional needs with the relevant stakeholders.
These basic elements are divided into two basic parts:
- The Product Definition.
- This defines the organisation’s view of the product.
- The Product Description.
- This defines the team’s view of the product.
|Element||What this tells the team|
|Scope and boundaries|
Unique selling points
Who will it be sold to/used by?
How will it be distributed and used?
Level of detail
It’s important to get the level of detail right:
- The detail should be enough be helpful to the team without committing the business to too much precision.
- It should describe the outcomes that would justify claiming goals are reached.
- E.g., specific indicators of ‘best-in-class’.
- It should define the context and parameters for the team’s approach.
- And much of its day-to-day work.
- It should make it easier to interpret individual stories.
- It should clarify delivery priorities and make it possible to organise individual releases into viable units.