- Forrester Councils
- Councils Overview
- log in
Posted by Tom Grant on February 15, 2011
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:
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.]
Lead BT Transformation
Develop customer-obsessed strategies to drive growth »
Forrester's CX Index
Predict how actions to improve CX will affect revenue performance.
Measure the customer experiences that matter most »