At the basis of any innovation, whether in the arts, science or technology, lies the creator’s vision.
In software development terms, it’s the concept of what the final product will look like that galvanizes an entire team into action to turn the Product Owner’s vision into reality.
Here’s the tricky bit however: how can we communicate that vision floating about a person’s mind into a shared objective held by all the team members?
It isn’t just a question of explaining it in words and diagrams and transferring an intellectual understanding of the general idea, we want the team to really own the vision and put their collective weight behind organization’s effort to develop the new product.
What we need is a practical and collaborative exercise that helps team members to define and internalize the vision.
I believe that the product vision box technique described in this article is one such technique that inspires enthusiasm among all stakeholders and helps them align their efforts to a common vision.
* * *
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 accept and reject 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 and foster 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 a later blog post.
The vision describes the high level of detail where we want to reach with the product in the long term.
Introducing the product vision box
The product vision box is a very simple yet powerful techniques promoted by Jim Highsmith that can be used by both agile and traditional project teams.
This exercise is usually carried out at the beginning of a new project and involves a number of stakeholders from across the organization, including users.
The basic idea behind the product vision box is to create an actual, physical box that has to be used to market the product.
Stores are filled with colorful 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. More importantly, good packaging attracts more customers than a bad package.
The commonest analogy used to explain this exercise is to think of a cereal box.
Are you imagining your favorite brand of cereal? What do you notice about it?
Each side of the box contains information that summarizes the benefits and features of the cereal brand. The name, logo and slogan are on the front, as are a couple of points highlighting the top benefits of that brand. On the back you find more detailed information about the product’s ingredients and attributes, and some history about the product or company. The sides of the box also feature some additional information about the cereal brand.
Now, what if I told you that you have to the exact same structure of a cereal box to describe your product. That is the unique challenge posed by the product vision box exercise.
How to build your box
Don’t be fooled by the fact that it feels a little bit like an arts and crafts session. The product vision box can reveal deep insights into your product and help the team grasp the vision in a very concrete and memorable way.
Usually, a team will be divided into a number of subgroups, each subgroup armed with the tools it needs to create their box, or mock-up of a box.
The key point to remember is that there is one vision associated with one product, so the final outcome of the exercise will be to produce a single version of the vision box that all the team agrees to.
However, before that, there can be a series of intermediate boxes which represents a process of refining the vision until it is literally delivered in one package.
Guidelines to keep in mind
The key point to remember is that there is one vision associated with one product
The product vision box workshop typically takes between 40 minutes and one hour. Each team has to build their own box, which must include the following elements:
- Front: Product name with a picture or drawing, slogan, and three to four main selling points.
- Back: A more detailed view of the product, listing functionality, requirements, etc.
After the box is completed, each team is given 5 minutes to present and sell the product.
The teams can vote on which boxes they feel encapsulate the product vision best and integrate elements from various boxes until finally a single vision box is designed.
Ask questions to clarify your software developments goals
If you’re facilitating your team in creating a product vision box, then you need to lead them away from technical description and towards coming up with statements that sell the product vision on the basis of its features and benefits.
This objective can be easily aimed by having the team members ask themselves the classic Wh-question used by journalists.
- Who? Who is the target customer and which kind of language is most appropriate for them?
- What? What does the product aim to achieve? How does it make the user’s life easier or better?
- When? When is the product expected to be delivered and what does the project schedule look like?
- Where? Where will the product be used? In which specific circumstances?
- Why? Why should users use this product instead of similar software solutions to the problem it addresses?
Synthesizing the answers to these questions and presenting them concisely on the box will help concretize the vision further and enable the team to get a better feel for the intended user experience this product is meant to deliver.
Benefits of using a product vision box
The most important benefit of this technique is that it forces the team to construct their own understanding of the product in a very direct and visual manner.
A product vision box lets you prioritize functionalities and requirements, and reach a consensus on the most important benefits and features offered.
Instead of getting lost in long-winded technical descriptions of the product, pictures and bullet points are used since the box presents some very real constraints to the information that can be placed upon it.
Another benefit deriving from the physical limitations imposed by the box is that while making it, the team members have to prioritize functionalities and requirements, and reach a consensus on the most important benefits and features offered by the product to the end-user.
This exercise provides a playful yet insightful method to pass on a deeper understanding of the product vision, while promoting discussion and collaboration between all the stakeholders involved in its development.
Since users are also invited to participate in this exercise, the product vision box is also a customer-oriented technique which gives the team the opportunity to learn first-hand what the users want from the product and tally the vision with real-life requirements.
The whole process of creating a product vision box is to select and deselect features that will eventually become the requirements your team will work on during each sprints.
It is important that the product owner uses the insights and feedback generating during the workshop to 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?
- The team must take ownership of the vision and put their collective weight behind organization’s effort.
- The product vision box is a practical and collaborative exercise, usually carried out at the beginning of a new project, that helps team members to define and internalize the vision.
- A good vision is used to accept and reject requirements.
- The basic idea behind the product vision box is to create an actual, physical box that has to be used to market the product and help reveal deep insights into your product.
- The most important benefit of this technique is that it forces the team to construct their own understanding of the product in a very direct and visual manner.
- Due to the physical limitations imposed by the box, team members have to prioritize functionalities and requirements in order to reach a consensus on the most important benefits and features offered.
Have you ever created a product vision box or is this the first time you ever heard of this technique?
If this article inspires you to set up your own workshop, feel free tell us all about it in the comments below. We’re curious to know how other teams in other organizations use and adapt this technique.
Finally, share this article and spread the word about the wonderful concept of the product vision box!