In his book, “Crossing the Chasm,” Geoffrey Moore offers a template of sorts for crafting a product vision:
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:
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.