Have you ever worked on a Scrum project where the overall goal was not clear? Where you had a product backlog but the people involved in the development effort only vaguely understood the purpose of the release? It happens more frequently than any of us would like, even on projects with multi-million dollar budgets! Often Scrum’s emphasis on “getting work done” is misunderstood as a rush to develop with not enough thought to where the project should be going. Don’t make that mistake. Every Scrum project needs a product vision that acts as the project’s true north, sets the direction and guides the Scrum team. It is the overarching goal everyone must share – Product Owner, ScrumMaster, team, management, customers and other stakeholders. As Ken Schwaber puts it: “The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is.” (Schwaber 2004, p. 68)
“Vision is the art of seeing things invisible,” observed the English writer Jonathan Swift. The product vision paints a picture of the future that draws people in. It describes who the customers are, what customers need, and how these needs will be met. It captures the essence of the product – the critical information we must know to develop and launch a winning product. Developing an effective product vision entails carefully answering the following questions:
- Who is going to buy the product? Who is the target customer?
- Which customer needs will the product address?
- Which product attributes are critical to satisfy the needs selected, and therefore for the success of the product?
- How does the product compare against existing products, both from competitors and the same company? What are the product’s unique selling points?
- What is the target timeframe and budget to develop and launch the product?
Answering these five questions also gives us the information to create a business case. It allows us to decide if and how the project should proceed.
Creating the Product Vision
Since the Product Owner is responsible for the success of the product and its return on investment (ROI), he or she should lead the vision-creation activities through close collaboration with the team (Pichler 2008). For innovative projects, this team may include business and technical people; for instance, marketers, product and user interface designers, and developers. The more innovative and complex the product is, the more important the vision is and the more effort is required to create it. For new-product development projects and major product updates, market research and prototyping activities are usually carried out. Since it may take several weeks or even months to compile the relevant information in this case, running one or more sprints is the best way to carry out the necessary work. Contrast this with a small product update or a maintenance release where creating the vision may only take a few hours or days.
The Heart of the Product Vision
At the heart of the product vision is the description of the selected customer needs and the necessary product attributes meeting those needs. To arrive at this vision, we first select our target customers and then the relevant customer needs, thereby deciding which market or market segment we are going to address. Then we identify the product attributes, those critical high-level requirements the product must fulfill to satisfy the needs.
Product attributes typically comprise both nonfunctional and functional requirements. Nonfunctional requirements include performance, robustness, and usability requirements. Functional requirements describe specific product functions or features, for instance making a call or sending an email. The product attributes serve as a guide for the team; they constrain the solution space – the set of all possible solutions.
Describing product attributes at the right level of detail is a balancing act that requires close collaboration between the Product Owner and the team. Under-specifying attributes causes a lack of guidance and direction. Over-specifying product attributes results in making decisions earlier than necessary and negatively impacts the team’s creativity. The techniques useful to describe attributes include personas and scenarios, use cases, and user stories.
Like any important goal, a good vision equally appeals to our intellect and to our emotions. It should motivate and inspire people. The product vision should be clear and stable; broad and engaging; and short and sweet.
Clear and Stable
The product vision must be clear and easy to understand to create alignment and a common purpose, and to avoid misinterpretation and confusion (Lynn&Reilly 2002, Pichler 2008). The English term vision is derived from Latin visio, which translates to “seeing, view, notion, idea.” The product vision should hence allow us to see the future product. The vision should not be fuzzy or hazy.
Vision changes, particularly with regards to customer needs and critical attributes, can cause confusion, de-motivation, and project failure. Small adjustments are usually fine, as long as the product’s value proposition stays the same.
Broad and Engaging
The product vision should describe a broad and engaging goal: a goal that guides the development effort but leaves enough room for creativity; a goal that engages and inspires people, fosters creativity, and generates buy-in.
Short and Sweet
The product vision should be brief and concise (Pichler 2008). It should contain only information critical to the success of the product. The blockbuster products researched by Lynn&Reilly (2002), for instance, had visions with no more than six product attributes. The product vision is, therefore, not a feature list and should not provide unnecessary detail.
The Elevator Test
The classic way to validate the product vision is to answer the elevator test: “Can you explain your product in the time it takes to ride up in an elevator?” Moore (2006, p. 152). Passing this test ensures that your product vision is clear, engaging, and brief (assuming we ride up a building with the right height and don’t get stuck). Notice that the elevator test does not tell us if we have selected the right customer needs and the right product attributes; only early customer feedback can do that.
Even our business-as-usual projects should be guided by a product vision. For example, I manage my own marketing activities using Scrum. I fill my marketing backlog with new items on a regular basis, sometimes as frequently as every other day. It would be an overkill to carry out market research and prototyping activities before I decide what to work on. Instead, I set myself a marketing vision that guides my work and provides focus. My vision is, by design, less substantial than the vision for a new-product development project but it’s still important that I have one.
An effective product vision guides the Scrum team and aligns stakeholders and customers. Spending time and money on vision creation is a worthwhile investment. As Robert G. Cooper notes: “Too many new-product projects move from idea stage right into development with little or no up-front homework. The results of this ‘ready, fire, aim’ approach are usually disastrous. Solid pre-development homework drives up new-product success rates significantly and is strongly related to financial performance.” (Cooper 2000, p. 3) This does not mean procrastinating the start of development, using an upstream waterfall process that creates a mighty product concept or employing a separate project. The trick is to spend as little time as possible but as much as required; to use Scrum to create the vision; and to ensure that as many of the team members involved in the vision creation as possible also transform it into the actual product.
Cooper, Robert G. Doing it Right. Winning with New Products. Ivey Business Journal. July/August 2000.
Lynn, Gary S. and Richard R. Reilly. Blockbusters. The Five Keys to Developing Great New Products. HarperCollins. 2002.
Moore, Geoffrey A. Crossing the Chasm. Marketing and Selling Disruptive Products to Mainstream Customers. Revised edition. Collins Business Essentials. 2006.
Pichler, Roman. Scrum – Agile Projektmanagement richtig einsetzen. dpunkt.verlag. 2008.
Schwaber, Ken. Agile Project Management with Scrum. Microsoft Press. 2004.