Make sure you have a well-defined vision to start with. What is your product’s value proposition? What are the key benefits to be delivered to stakeholders? What is the overall scope of your effort? Are there certain critical dates you must hit, in order to achieve benefits realization? What are the key product attributes necessary to deliver the benefits being pursued? How is this product different from others already available, or known to be in development?
Your vision should be succinct enough to be easily read in a single sitting, but should be concrete enough to provide real guidance to the project team about what moves you towards the goal line vs. what moves you away from it, or simply leaves you running from one edge of the field to the other.
Once you have a draft vision, interview key stakeholders individually and ask them what the project visions means to them. Make sure you receive consistent answers. If you don’t, then you need to get the group back together to iron out inconsistencies and sharpen your vision.
The product vision need not be fancy, but it should be documented. Without some sort of overall vision for the product and its evolution, the project can too easily devolve into a simple aggregation of unrelated change requests, and the product can quickly become a victim of feature bloat, and suffer from scope creep. A product vision provides the cohesion necessary to make both the project team and the features being implemented more than just the sums of their respective parts.
As you are defining your vision, consider its implications. There will likely be elements that will need to be considered in other areas as you prepare to start your development project.
Although your product vision should be concise, it should be specific and meaningful. Avoid the sort of trap Bob Lewis warns you about when it comes to Mission Statements:
Good missions, and Mission Statements, exclude alternatives. Useless ones try to express everything you might ever want to do.
“We develop or install high-quality software” has no place in a Mission Statement, for example, because what other choice might you have expressed? The alternatives:
- We develop or install mediocre software.
- We develop or install awful software.
- We refuse to develop or install any kind of software.
- We’d really like to develop and install software, only we’ve forgotten how.
All are non-starters. Because the only statement you can make about software is that it will be high quality, don’t waste the paper and toner.
The Product Vision is similar in many respects to the Chief Engineer’s Concept Paper used at Toyota, and described by Morgan and Liker in their book The Toyota Product Development System.
There is nothing worse than a brilliant image of a fuzzy concept.
I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.
In most people’s vocabularies, design means veneer. It’s interior decorating. It’s the fabric of the curtains and the sofa. But to me, nothing could be further from the meaning of design. Design is the fundamental soul of a man-made creation that ends up expressing itself in successive outer layers of the product or service.
The whole difference between construction and creation is exactly this: that a thing constructed can only be loved after it is constructed; but a thing created is loved before it exists, as the mother can love the unborn child.
…system architects act as storytellers. They keep alive the promise and vision of the future system, which is particularly valuable during the confusing early periods of a project.