Editor’s Note: As I constantly reiterate on these pages, good design requires making often difficult choices between imperfect options. Making those decisions consistently requires a touchstone — some kind of guiding principle — often called a vision statement. For my company’s product CityDesk, for example, a part of the vision was “content management when you can’t run code on your web server.” That meant that features which required code on the server, like membership or discussion boards, were left out.
Last week at the Cutter Summit Jim Highsmith described a useful way to figure out your vision statement, which he calls Design the Box. Here’s his article, which originally appeared in the 23 August 2001 issue of Cutter Consortium’s Agile Project Management E-Mail Advisor and was reprinted with permission. Register here for a free, four-week trial to the E-mail Advisor. – Joel Spolsky
A sample product vision statement:
“For a mid-sized company’s marketing and sales departments who need basic CRM functionality, the CRM-Innovator is a Web-based service that provides sales tracking, lead generation, and sales representative support features that improve customer relationships at critical touch points. Unlike other services or package software products, our product provides very capable services at a moderate cost.”
This product vision model helps team members pass the elevator test — the ability to explain the project to someone within two minutes. It comes from Geoffrey Moore’s book Crossing the Chasm. It follows the form:
- For (target customer)
- Who (statement of the need or opportunity)
- The (product name) is a (product category)
- That (key benefit, compelling reason to buy)
- Unlike (primary competitive alternative)
- Our product (statement of primary differentiation)
For any project, but particularly those with high uncertainty for which significant requirements changes are anticipated, creating a product vision statement helps teams remain focused on the critical aspects of the product, even when details are changing rapidly. It is very easy to get focused on the short-term issues associated with a 2-4 week development iteration and lose track of the overall product vision.
Even within an IT organization, I think every project should be considered to produce a “product.” Whether the project results involve enhancements to an internal accounting system or a new e-commerce site, product-oriented thinking pays back benefits.
One practice that I’ve found effective in getting teams to think about a product vision is the Design-the-Box exercise (developed originally by colleague Bill Shakelford). This exercise is great to open up a session to initiate a project. In this exercise the entire team, including users, breaks up into groups of four to six (this works best with cross-functional participation). The team makes the assumption that the product will be sold in a shrink-wrapped box, and their task is to design the product box front and back. This involves coming up with a product name, a graphic, three to four key bullet points on the front to “sell” the product, a detailed feature description on the back, and operating requirements.
Coming up with 15 or 20 product features proves to be easy. It’s figuring out which 3 or 4 would cause someone to buy the product that is difficult. One thing that usually happens is an intense discussion about who the customers really are. Using a very simple product example, it always amazes me that the product vision boxes end up so disparate among three to five teams. Presentations by each of the groups are then followed by discussing how the multiple focal points can be reduced to a few that everyone agrees upon. A lot of good information gets generated by this exercise — and it’s fun. Once this exercise has been completed, the group can then work on constructing their own version of Moore’s product vision statement. Finally, with several hours of active discussion recorded on flip-chart paper, the group can construct a good outline for a complete one- to three-page product vision document that might include: the mission statement, a project profile overview (scope, schedule, cost, defects) with priorities, pictures of the “boxes,” target customers and each of their needs, customer satisfaction measures, key technology and operational requirements, critical product constraints (performance, ease of use, volumes), and key financial indicators.For a four- to six-month project, this visioning exercise might take from a half-day to a full day, but it will pay big dividends. The more critical the delivery schedule and the more volatile the project, the more important it is that the team have a good vision of the final desired outcome. Minus this vision, iterative development projects are likely to become oscillating projects — going round and round in circles because everyone is looking at the minutia rather than the big picture.
Jim Highsmith is the Practice Director, Agile Project Management, Cutter Consortium.
If you’d like to comment on today’s Agile Project Management E-Mail Advisor, send e-mail to apm@cutter.com, or send a letter by fax to +1 781 648 8707 or by mail to The Agile Project Management E-Mail Advisor, Cutter Consortium, 37 Broadway, Suite 1, Arlington, MA 02474-5552, USA.
© Copyright 2001 Cutter Consortium. To sample Cutter’s other weekly e-mail advisors, register here.
