Traditional requirements stink on ice, continued

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 featuresprojects, 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.]



re: Traditional requirements stink on ice, continued

Tom,I can't agree more on your comments that traditional requirements stink. The primary reason they stink is they are written without regard to the market problem they are supposed to solve. "The product shall have 14 user-defined fields", "The product shall email users when the ion flux regulator heats up", "The product shall have 4 USB ports", and so on, ad naseum. When the agilists started asking for user stories, they were attempting to get closer to what the user wanted.But without understanding what the user is really trying to do, and what problem she is trying to solve, any form of requirements (sticky notes, index cards, user stories, or IEEE Std 1220-1994) will continue to stink, no matter the form. Product managers (or anyone charted with articulating WHAT needs to be built and WHY it needs to be built) must uncover problems to be solved. Discover the root cause. Look for how the problem is solved today. Out in the market, not sitting in the office. For vendors, the product manager must also figure out if the problem is pervasive (for many, not one customer) and where the willingness to pay exists. Not every problem is worth solving, even if it has a nice user story that fits the sprint.Barbara NelsonInstructor, Pragmatic MarketingPS It was nice to meet you at my session at P-Camp.

re: Traditional requirements stink on ice, continued

The real problem is not whether or not one requirements methodology "stinks", but a combination of ensuring that the right inputs are coming into the process and that the right tools are being used to communicate those inputs to your teams effectively. You don't drive a nail with a screwdriver, and you don't drive a screw with a hammer, and you don't use either if the intention is to have something that's supposed to be easily removed and replaced.Agile user stories have their place in our toolbelt as Product Managers, as do waterfall "bullet-point" requirements as well. But knowing when to use one over the other, and knowing what information you're out there gathering is important enough to communicate in whatever form is the core competency of any successful Product Manager. I try to focus on two questions:1. What is the problem that we need to solve?2. How can I most effectively communicate that problem to the people who can design the solution?If you're not doing both of these effectively, you're likely struggling as a Product Manager.