Democracy is great, right? We'd all prefer to have direct participation in the decisions that affect our lives, from which multimillionaire will represent us common folk to which features we'd like to see in the next version of Microsoft Office. (Please, please, PowerPoint team, just copy Keynote's auto-align feature already.) The more voting we do, the more we feel that civilization has advanced, and the better the quality of the products or politicians we get.

Polls Are Valuable But Inadequate
In recent years, application development teams have grown increasingly open minded, and in many cases even enthusiastic, about voting or polls as a prioritization mechanism. Worried that your requirements rely too heavily on interviews with a potentially unrepresentative sample of users? Take a quick poll to get a more accurate estimate of real demand for the work you might do.

As important as polls can be, they're not perfect. Even if you don't go crazy with how you use the results, the quality of these findings depends a great deal on the questions you ask. Even if your survey question kung fu is great, other risks exist, such as the unfortunate tendency of people with no opinion answering the question anyway because they don't want to appear foolish.

One peril that holds special relevance to application development (or product development in general) is the missing part of the sample. By their nature, polls omit the customers you think you should have but don't yet have. 

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:

• The document plan, which outlines the topic and the research approach.

[For earlier posts in this series, click here and here.]

Imagine that you're dining at a new Italian restaurant that just opened in your neighborhood. You've heard that the chef is well known and widely respected, so you're expecting a great first experience.

You sit down, and the waiter hands you a menu. Actually, it's not a menu, but a listing of all the top-quality ingredients in the restaurant's refrigerator. Some ingredients suggest the kind of recipes that the chef might prepare: For example, the veal shank might be destined to become Osso Bucco. Since you're not an expert in Italian cuisine, it's hard to guess what kind of recipe might require some of the other ingredients (rabbit, goat, boar, etc.).

The waiter is no help. He'll dutifully return to the kitchen with the ingredients you tell him the chef should prepare, but he won't tell you if that combination will transform into a delicious meal or an indigestible lump. 

In this scenario, chances are slim that you'll get the sort of dining experience you expected. If you were hoping for an experience you've never had before, the kind that a world-class chef could provide, the odds are even worse.

Sadly, this is exactly the way in which technology companies have pitched their products. Rather than explaining the experience you should have, they leave it up to you to figure out what experience might be possible, given the ingredients (features and functions) available in the product. This approach has two pernicious consequences:

Scott Sehlhorst has an outstanding post at Tyner Blaine about documentation. Not technical documentation, but the information you write down to make the development process work. By work, I don't mean just the activities within the development team, but also the rest of the value chain, too.

Scott is talking about the role of documentation in Agile development, but his points are relevant to any team, Agile or not. Agile creates greater sensitivity to the issue, since too much documentation can cripple the team's velocity. Of course, the lack of documentation can damage the team's success:

Some collaboration is transient – communication happens right now, and is only important right now.  Other communications are persistent – the collaboration happens right now, but we need to remember later what we agreed upon and why.

Scott's post is a great illustration of what I was discussing yesterday about treating requirements as conversations, not dictionaries. Requirements are part of the conversation, but a lot of the same content that defines what to build, and why, gets recycled later when you need to describe what you built, and why. For example, personas get passed around quite a bit among groups. Perhaps the originate in the development team, but people in sales, marketing, support, and other downstream groups have a keen interest in that information.