Product Vision

Product Vision2017-10-12T22:05:26+00:00

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.
ElementWhat this tells the team
Product Definition
  • What specific problem will it solve for the user?
  • What will its market position be?
    • E.g., ‘best in class’, ‘market leader in…’
  • What specific business and/or operational outcomes will it lead to?
Scope and boundaries
  • E.g., the specific regions or markets where it will be available.
  • E.g., related products, product to be replaced, etc.
  • What specific business capabilities does the product need to provide?
Product Description
  • What specifically will the product be able to do?
  • What will it look and feel like?
Unique selling points
  • What will make it stand out in the market?
  • What does the product need to do really well?
  • What are the development priorities?
Who will it be sold to/used by?
  • Who are we selling the product to?
  • Who will the product be used by?
  • What sort of people/organizations are they?
  • What will they expect from the product?
  • How will they want to use it?
How will it be distributed and used?
  • How will this product be distributed?
  • What channels will it be used through?
    • Specialised device? Internal? Online? Mobile? Both? More?
  • Is there already a schedule for this product?
  • What (if any) are the critical events in the evolution of this product?
  • What calendar-related rules do we need to be aware of – seasonality, etc?
  • Which other areas (e.g., marketing) have time-critical scheduled or events?
  • How much can we afford to spend on developing this product?
  • What features will generate the income needed to finance development?
The competition
  • Who are we up against?
  • What does their product look like?
  • How is our product different from theirs?
  • How is their product better than ours?
  • How can we make our product better than theirs?

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.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?