A while back, I had a spirited exchange with someone who took a rather extreme position about the role of product management in software as a service companies. The less polite version: He staked out a silly position – just poll your customers about what to build, and eliminate the PM role altogether – so I felt obliged to refute it. With two additional years of research into SaaS and PM, it's worth returning to that contretemps for a moment.
Then, I argued that PM was necessary in SaaS ventures.
Now, it's clear that PM is not merely necessary but essential.
Product Managers Are Really Innovation Managers
If the sole responsibility of PM were requirements, as my foil assumed, a poll might replace a person, but only if you had no interest in the long-term success of your company. Polls are extremely useful tools, and it's far better to use them than not to. However, polls have their limitations: most obviously, as a tool for taking the temperature of the customers you have, they tell you absolutely nothing about the customers you don't have yet.
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.
[For earlier posts in this series, click here, here, and here.]
Imagine yourself back in childhood, sitting in the back seat of the family station wagon, en route to one of those long, high-stress family vacations that Americans have honed to perfection. Mom and Dad are arguing over what went wrong so far on the trip, and of course, how they could have avoided these mishaps. Why didn't we ask for directions at the last gas station, instead of letting Dad navigate by dead reckoning? Should someone have called ahead to ensure that there wasn't a problem with the hotel reservations? Who was supposed to remember to pack the camera? Was it reasonable to expect a travel rate of 500 miles a day? Quickly, your vision of vacation as a straight line into the heart of fun evaporates. Replacing it is a circuitous flowchart, each serpentine twist representing a different set of decision points, estimates, and possible outcomes. Who knows what might happen next? The wheels will fall off on a desert highway, and someone will have forgotten to renew the AAA membership?
Internal pilots (a.k.a. "eating your own dog food," or "drinking your own champagne") are important tools. But how? What kind of feedback do you get from these exercises, and what sort don't you get?
That's the topic of a new research project that we just launched. While Forrester starts hundreds of new research efforts this year, I'm highlighting this one for two reasons: (1) I'm doing the research, and I think that everything I do is interesting; (2) this is the second time I've done a research project in a very transparent way. From start to finish, we're going to work in the open, to give you, Dear Reader, an opportunity to comment on the research as we do it.
The first project done in this fashion, which investigated "thought leadership" (whatever that means) in the technology industry, resulted in this RoleView document. Along the way, we solicited comments on the basic research plan, the questions we asked our interview subjects, and the content of the document. We threw out questions to Forrester community members along the way, and at the end, we did a brief retrospection on how well we succeeded.
We're Interested In Your Feedback Again. No, Really.
We're following the same game plan this time. Three documents just went live in The Forrester Community For Application Development & Delivery Professionals: