Recently, the city of San Jose used a serious game, Buy A Feature, to address some tough budgetary challenges. Since serious games have relevance across a wide range of contexts, including application development and delivery, it's worth relating one anecdote from San Jose's exercise that demonstrates the importance of having a shared vision.

I was a "facilitator" for this exercise, which involved more than 100 members of the community, plus a couple dozen city officials, including Mayor Chuck Reed. According to the ground rules of this exercise, organized by Innovation Games, each group of several community members had to decide which municipal projects (libraries, parks, school programs, fire, police, etc.) to fund and which not to. These "wish list" items formed List A. A complementary List B included other projects that the participants could decide to cut and then shift the money into projects from List A.

Every participant had a small amount of money, but not enough to buy anything from List A outright. Funding anyone's favored project, therefore, required investment from more than one person. Money from any List B project was available only if everyone at the table agreed to cut it.

One enterprising participant realized that, if the group agreed to cut everything from List B, they would have enough money to fund every item on List A. At this point, the game took an interesting and unexpected turn: instead of the usual horse-trading that happens during Buy A Feature, the participants spent the bulk of their time trying to figure out if cutting everything on List B was a good idea. By the time they decided to go ahead and slash everything on List B, there was very little time left to talk about the items they wanted to fund on List A.

And here was where the participants discovered how little real agreement there was among them. In focusing on the means to fund hypothetical projects, the group never really got to any point of agreement on the ends that city projects, funded or not, were supposed to achieve. One participant made a passionate plea for a school anti-drug program. Another wanted to get money for an anti-gang project. Others worried what would happen if fire department staffing dropped below the national average or how the quality of life in San Jose would suffer if libraries closed. The group rushed to fund as many projects as it could but eventually agreed on fewer projects than other groups armed with the same lists.

Without a vision of what they wanted San Jose to be, the amount of available money didn't matter. The same is true of any software development project, or product, that teams want to produce.

Say you're a product manager at an ISV, responsible for a product that has 1,000 customers. Every customer has a list of enhancement requests, which means that the list of potential projects, the equivalent of List A from the San Jose exercise, is very large. Not only must the final list satisfy your customers, but it also has to benefit your company. (And, of course, be realistic about what you can accomplish with finite resources and time.) Here are some approaches to deciding what enhancements to fund:

  • On the customer community site, open a thread to ask what customers want. And let the loudest, pushiest customers win!
  • Take a poll. This technique will give you a reading of how strongly people want something, but not why they want it. Polling was part of the San Jose city event, after the Buy A Feature exercise. While voting on particular budget-cutting initiatives (raising the retirement age for city employees, postponing projects, etc.) provided valuable information, it didn't communicate, ipso facto, why people preferred one option over another. This technique also pulls you in the direction of what a majority of customers want, assuming that they represent the future market you want to serve. (Maybe not.)
  • Segment the customer input. In this case, you're taking a step towards identifying the type of company you want to be. For example, if you want to be an enterprise software company, you can filter the list of enhancements by company or project size. You may not make everyone happy, and you might get a result that would be very different from any poll you take. That's fine, as long as the results serve your long-term vision of the company.
  • Run a serious game with your customers. This option goes a step beyond just asking for information. Serious games like Buy A Feature push customers, or business users, or whoever the stakeholders are, into a real conversation, not just a statement of demands. Not only do you need to explain what you want, and why, but you also have to discuss the enhancement, city program, or any other project in the larger context of possible work. 

In no way is this list comprehensive, and in truth, no single technique suffices. In all likelihood, you'll combine techniques, including some that I haven't mentioned. It's not easy to understand what people value — in the technology that they use or the city where they live. 

[If you're interested in the San Jose exercise, here's a link to a blog entry by Gerry Kirk.]