The Product Vision

9 January 2009

Roman Pichler
Pichler Consulting Limited

True North

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)

Five Questions

“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:

  1. Who is going to buy the product? Who is the target customer? 
  2. Which customer needs will the product address? 
  3. Which product attributes are critical to satisfy the needs selected, and therefore for the success of the product? 
  4. How does the product compare against existing products, both from competitors and the same company? What are the product’s unique selling points? 
  5. 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.

Desirable Qualities

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.

Business-as-Usual Projects

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.

Summary

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.

References

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.

Article Rating

Current rating: 4.3 (3 ratings)

Comments

Tom Steele, CSM, 1/9/2009 1:22:13 PM
Another important benefit of a Product Vision is its ability to prevent features/functionality from being unnecessarily added. Programmer/creative types are all about ΓÇ£embrace and extendΓÇ¥ even if it is not the right thing to do. A good vision can prevent this.
Roman Pichler, CST,CSP,CSM,CSPO, 1/12/2009 2:27:21 AM
Hi Tom, you are spot on: An effective vision helps us to decide if a requirement should be part of the release or not. If the requirement helps to fulfill the vision, it should be implemented. If not, it shouldn't. Roman
Ryan Shriver, CSM, 1/13/2009 10:59:45 PM
You talk about what a good vision is, but I don't see any examples that have some (or all) of your desired qualities. Can you share examples of great visions for kicking off Scrum projects?

I would say that having a vision is very important. But equally as important to lofty "vision prose" is practical "planning prose". This involves quantifying the key business objectives, key product qualities and nonfunctional requirements so that teams cannot fail to understand what's being requested, and provide feedback on whether that's achievable with the budgeted resources. Check out Planguage (www.gilb.com) for more info on a method for doing this that will fit with your desired qualities outlined here and enhance it to use quantitative statements of results.
Roman Pichler, CST,CSP,CSM,CSPO, 1/14/2009 2:35:29 AM
Hi Ryan, I would prefer Product Owner and team collaborating closely to create the product vision over trying to express requirements precisely. Remember: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." (www.agilemanifesto.org/principles.html) As I mentioned in the article, I use personas and scenarios, (business) use cases, and user stories to describe product attributes. If Tom Gilb's Planague works for you to express the vision requirements, great.
Stephen Palmer, CSM, 1/27/2009 5:27:09 AM
As a warm-up exercise with a new team I'm working with, I often ask them to come up with a 'statement of purpose in 25 words of less' for what they are building (a strategy learnt from Peter Coad's - #2 in his old Object Models: Strategies, Patterns and Applications book). If they can't do that within 10-15 minutes then I know we have to step back and look at the vision/objectives for the project. It is surprising how many teams cannot do this, not necessarily because they do not have one but often because for some reason it has not been communicated well enough.

Of course, traditional waterfall projects often spend considerable time on producing vision documents or executive summaries or whatever they want to call it, have complicated document templates for it, worry as much about the formatting as about the content, and set it in concrete long before a developer is assigned to a project. The 'Desireable Qualities' above are crucial!
Alexey Krivitsky, CST,CSM,CSPO, 2/22/2009 10:03:44 AM
Roman, thanks for the article.

I think vision is very important that helps to build a common understanding of "why and what are we here suppose to build". Somehow this activity sometimes is forgotten. Not each CST talks about product vision on her class.


I usually ask my team to go through the vision exercise just before the user story workshop. Actually by discussing details of the vision they start thinking of the stories at some point which basically means they are ready to switch to the brainstorming session.

In order to build up the vision we usually stick a flip-chart sheet to the wall, give our PO markers and stickies and let him talk for 5-15 minutes...

To keep this a little bit more structured we're trying to fill in the following aspects of the vision:
- the working product name
- the product metaphor (a sentense, subheadline of the product name)
- main users to use the product
- expectations of the release schedule (dates, regularity, scope) and the metaphor of the 1st release (this usually changes after first sprints, but it is still worth discussing PO's expectations)
- competitors (and how we can be better)
- similar products to look at for getting more ideas from
- sources of the revenue and when the PO actually is going to start getting income (say 1st release will have no paid features)

And this helps a lot to involve the team members into discussing user stories afterwards.
Arvind Patil, CSM, 4/29/2009 12:44:28 AM
Good Article. We often create a vison statement as part of Iteration-0. We spend couple of hours as team based activity representing cross functional members (dev, test, BA and proxy product owner). Vision statement contains who are all the stakeholder's for this product/featue, why they have to use this, what is productivity gain for their day to day work etc....And some important key functionalities of that product/feature
Roman Pichler, CST,CSP,CSM,CSPO, 4/29/2009 5:36:35 AM
Hi Alexey and Arvind, Thanks for the feedback and sharing how you create your product visions. You can read my suggestions for creating the vision in my new book called "Agile Product Management. Turning Ideas into Winning Products with Scrum." The book also contains more and updated information on the vision. You can access draft chapters at http://www.mikecohnsignatureseries.com/books/agile-product-management.
Girish Hegde, CSM, 10/3/2009 5:49:03 AM
Very good article. As said in a Japanese Proverb "Vision without action is a daydream. Action without vision is a nightmare"
In addition to what you explained, I think revisiting a vision statement is vital since in the beginning of any engagement we lack clarity. So I would prefer to suggest teams to spend not more than 30 mins before the sprint planning meeting, during earlier iterations to fine tune the product vision with the guidance of PO if feasible. This may help in arriving at an efficient vision statement as it is a difficult exercise to complete in one go.
Roman Pichler, CST,CSP,CSM,CSPO, 10/5/2009 2:43:20 AM
Hi Girish, I recommend to Scrum teams to revisit the vision in the sprint review meeting, to see if the vision is still valid or if it has to be adapted. As Ken Schwaber puts it in the Scrum Guide: "The entire group then collaborates about what it has seen and what this means regarding what to do next. The Sprint Review provides valuable input to subsequent Sprint Planning meeting." The vision is detailed in the product backlog by the way since the backlog describes the outstanding work necessary to develop a successful product.
Tulio Oliveira, CSM, 3/22/2010 11:16:14 PM
An effective product vision ensures the success of SCRUM by guiding your team and aligning stakeholders and customers.
Fabrice Aimetti, CSM,CSPO, 11/21/2010 8:55:23 AM
Hi Roman, thanks for this article, it's great! I have translated it into french : <a href="http://www.fabrice-aimetti.fr/dotclear/index.php?post/2010/11/21/La-Vision-du-Produit">La Vision du Produit</a>.
Regards, Fabrice
Fabrice Aimetti, CSM,CSPO, 11/21/2010 8:55:54 AM
The link : http://www.fabrice-aimetti.fr/dotclear/index.php?post/2010/11/21/La-Vision-du-Produit
Roman Pichler, CST,CSP,CSM,CSPO, 11/22/2010 2:20:41 AM
Thanks Fabrice!
David Charles Nurser, CSM, 8/17/2011 9:23:43 AM
Nice article, I got some useful pointers from it (and from the comments). Thanks!
John Nair, CSM, 7/16/2012 2:39:35 AM
Hi,

Thanks this article helped me as a pointer to Product Vision.

You must Login or Signup to comment.