Creating a Product Vision and Roadmap

Product vision describes the product’s goals and customer value. It relates to the problem that the product solves. A vision supports a product-oriented mind-set which increases clarity by creating a “product”. The idea of ​​a “product” should be in every IT organization. The vision improves clarity, whether you manage a system or build something completely new. A good vision can be used to define and select requirements.

The vision describes the high level of detail where we want to reach with the product in the long term. It helps the team to understand the big picture and is the basis of a roadmap. The vision is owned by the product owner. With the help of a vision, it becomes easier for the team to focus on what is critical.

Everything is based on the same thing, the vision. It becomes easier to understand the long-term goal. Without a vision, it is easy to focus too much on only short-term goals (2-4 week sprints). The vision minimizes unnecessary discussions. This is especially important with a vision of projects with high uncertainty. Vision’s meaning is different in different teams. In small teams, it is not as important with a clear vision. In larger teams or projects with multiple teams, the vision is important. The Product Owner is the one that stands for the vision and communicate it to the outside world.

It is very powerful for the team and the product owner together develop the vision. The growing understanding and consensus. Two common techniques to develop and package the vision is the Product vision box, which I discuss below, and the elevator pitch which we’ll explain in our next blog post.

Product Vision Box

The format encourages discussion and cooperation around a common goal. Participating development team and other stakeholders, such as sellers. Stores are filled with colourful product packaging that tell which products are new and improved. They tell of how the products will make us leaner, smarter and more environmentally conscious. Good packaging attracts more customers than a bad package. In a workshop can produce different proposals on the boxes but the end result is a joint product box.

Layout:

• Front: Product name, illustration, slogan and 3-4 sales pitch
• Other pages: More detailed description
• Time: 45 minutes + 5 minutes to present and sell the product

Roadmap

Shows at a high level what probably needs to be developed to achieve the vision. Add enough time in sufficient time to process enough. Refine you go. Roadmap is the level of detail in the vision. Shows roughly what’s needed (requirements for functionality) to achieve the vision. Helps the team to understand what comes in future releases. Laying the foundation for product back log. Owned by the product owner. As a product owner, use the roadmap to motivate and lead the way for the team. You use it to communicate with decision makers.

Epics

Epics fit well in the product back log for features to be implemented in the long term. An epic is broken down into several smaller, testable requirements. It is often written as a verb + object, for example:

• Buy ticket
• Pay Invoice

Selecting and deselecting features

It is important that the product owner both select and deselect. Features that are not entirely necessary leads to tests, bugs, management and releases. It is not dangerous to say no. If the requirement is important enough it pops up again. Requirements are partly perishable, if you save the requirement for the future, it is easy that it becomes obsolete. If you do not dare throw, saving requirements anywhere but do not have much time. Always consider: Why save everything?