First, let me belatedly acknowledge Luke Hohmann, who ranted eloquently about traditional requirements at his P-Camp session several days before I started this current screed. His observation was Hemingwayesque in its pithiness: "Requirements suck." Mine is more Faulkneresque, using an idiom ("stink on ice"), undoubtedly with a colorful origin that no one remembers.

The second reason why traditional requirements stink on ice is, ultimately, a question of perspective:

  • Development teams build technology for people who are wholly unlike themselves.

  • No team has the resources to live side-by-side with the people for whom they're building the technology. The users don't have the time or inclination, too.

  • Most development teams rarely interact with people on a different floor in the same building, so living side-by-side with the target users wouldn't be an automatic mechanism for osmotic transmission of insight.

  • Therefore, development teams generally view requirements in their own terms, and not the world as the end user sees it.

By necessity and habit, development teams think and speak in terms like features, projects, and releases. Occasionally, users may use this language to make themselves understood to you, but it's not the terms that define their world. They want to do their jobs more quickly and successfully, and  then go home and think about something other than inserting a table of figures into a Word document.

Traditional requirements both reflect and reinforce this language barrier. Obviously, at the end of the day, you do need to go back to your cubicle and work on features. However, at some point in the process of designing, building, and releasing technology for people unlike you, you need to speak and understand their language, not yours.

To illustrate, here's an archetypical exchange between an ISV and a customer:

Customer: "We've been asking for this feature for a while. When will we get it?"

Vendor: "Very soon now. Meanwhile, what do you think of this feature? We think it's a great idea."

Customer: "Sure, it looks interesting."

Vendor: "Cool, because we're hoping to get it into the next release. We thought you might like it."

While there are many, many things going wrong in this conversation, for our purposes, the chief problem is linguistic. Both parties are guilty of speaking the vendor's preferred language, without making it clear how it translates into the customer's. Asking where the ion flux regulator appears in the product roadmap doesn't clarify why it's important to have one in the first place. Nor does it help understand whether the etheric vortex stabilizer helps solve the same problem for the customer, or anything at all.

Here's when some Agile aficianados are jumping out of their chairs to say, "Oooh! Oooh! Let me tell you about personas and user stories!" I largely agree that these Agile-approved requirements media can go a long way towards understanding the customer. However, they're not complete solutions for two reasons:

  • The medium often constrains the understanding. For people whose Agile approach involves a lot of Stickie notes or index cards, it should not be a shock to hear that minute tiles of information, as useful as they are, do not always automagically transform into a beautiful, accurate, or complete portrait of the target user. At least in practice, that is.

  • The sources of information still deserve some skepticism. You might drop the jumbo Word and Excel documents for personas and user stories, but you still may be extracting information from an unrepresentative sampling of users.

Social media are not a panacea for this language problem, or any other congenital defect that afflicts traditional requirements. Nonetheless, there are ways to use social media to help crack the language barrier.

Mandatory caveat: As in other situations, it's possible to use social media badly here. For example, giving users the ability to vote on feature ideas is a wonderful thing. However, keep in mind that this new channel of communication you are allowing them to speak your language more clearly, without necessarily improving your ability to speak theirs. In fact, some vendors' parochial use of social media resembles what many Americans do when confronted with someone who doesn't speak English: "Maybe you people will understand us IF WE JUST SPEAK MORE LOUDLY."

[Cross-posted at The Heretech.]