Crafting a Product Vision
In his book, "Crossing the Chasm," Geoffrey Moore offers a template of sorts for crafting a product vision:
For (target customer)
Who (statement of the need or opportunity)
The (product name) is a (product category)
That (key benefit, problem-solving capability, or compelling reason to buy)
Unlike (primary competitive alternative, internal or external)
Our product/solution (statement of primary differentiation or key feature set)
To help wire this in, the following guided exercise can be helpful. Consider the following product vision statement for a fictitious software program, Checkwriter 1.0:
For the bill-paying member of the family who also uses a home PC
Who is tired fo filling out the same old checks month after month
Checkwriter is a home finance program for the PC
That automatically creates and tracks all your check-writing.
UnlikeManaging Your Money, a financial analysis package,
Our product/solution is optimized specifically for home bill-paying.
Ask the team to raise their hand when an item on the following list of potential features does not fit the product/solution vision and to keep it up unless they hear an item that they feel does fit the product/solution vision. By doing this, the team is being asked, "At what point does the feature list begin to move outside the boundaries suggested by the product vision?" Most hands should go up around item #4 or #5. All hands should be up by #9. A facilitated discussion related to the transition between "fits vision" and "doesn't fit vision" is often quite effective after this brief exercise.
Logon to bank checking account
Synchronize checking data
Generate reconciliation reports
Send and receive email
Create and manage personal budget
Manage customer contacts
Display tutorial videos
Edit videos
Display the local weather forecast for the next 5 days
It should be clear that one or more of the later items on the list do not belong in Checkwriter 1.0. This is how product visions work. They provide a filter through which potential features can be run during the life of the project to determine if they are inside or outside the project's scope of work. As powerful as this is, the product vision will only catch the larger features that threaten the project work scope. To catch the finer grain threats to scope creep, a product road map needs to be defined by the product owner.