How to generate an awesome product vision

09 January 2011

It strikes me that web development projects often do not learn enough from the past experiences in other fields. One of these problems lies in the area of (new) product development. Most web development projects have not enough emphasis on product management. While agile development practices heavily encourage to "take action", they are off course not against substantial thinking about the product. To stress the importance of a well thought out product road map, Scrum tries to constrain it by saying "A sprint should only begin if the product backlog is prioritized and ready".

Web development projects have not enough emphasis on product management.

But Scrum doesn't give you product management tools because Scrum is not a silver bullet. It is just a framework for completing complex projects. Scrum is not a market research method or a tool for generating new business ideas. It is said so many times but maybe not often enough, because I hear still people talking about Scrum if it is a silver bullet. Scrum is neither a substitute for skilled and experienced developers who write good code or solid engineering practices.

I see that web development projects are often trying to reinvent the wheel. I don't mean it as in code or application reuse. Most developers use principles like DRY actually very appropriate. I mean it as in general problem solving and business problems. Most problems we face are not new. Other people have encountered the problem and have probably found solutions that we can use directly or get inspired by.

Writing a product vision using Heilmeier's catechism

George Heilmeier, spent much of the 1970s in the United States Department of Defense and initiated major efforts in stealth aircraft, space-based lasers, space-based infrared technology and artificial intelligence. In the case of product vision, we can use existing and proven tools. A simple starting point is for example Heilmeier's catechism which can be used as questions that should be answered when creating a product vision:

  • What are you trying to do? Articulate your objectives using absolutely no jargon.
  • How is it done today, and what are the limits of current practice?
  • What's new in your approach and why do you think it will be successful?
  • Who cares? If you're successful, what difference will it make?
  • What are the risks and the payoffs?
  • How much will it cost? How long will it take?
  • What are the midterm and final "exams" to check for success?

I think that these questions are especially useful because they are so simple. It is for everybody understandable and doesn't introduce any technical barriers. While there are much more comprehensive models and tools, these questions grasp the essence. If a product owner can not answer these questions convincing and enthusiastic then there is definitely something wrong and beginning such a project is just asking for problems.

" While there are much more comprehensive models and tools, these questions grasp the essence. "

Web development projects have multivariate problems that can't be projected onto a single axis. We may wrongly attribute causation to one factor, when the real problem may be more complex. While I strongly suggest that the product vision is often a problem, it is not the only succes factor. Paul Graham listed here 18 start-up mistakes.

To read: