Traditional requirements stink on ice, and then some

I, The Customer
I've already talked at length about how the assumption of the unified, rational actor called "customer" is a myth. That notion is just as chimerical and comical in product requirements as it is in economics and political science. Customers, like firms and governments, are neither unified nor rational.

Any point that important is worth making again, particularly as part of my recent litany of problems with requirements, as traditionally conceived. Rather than repeat what I already said, I present you with a pungent example, ripped from the pages of Two-Fisted Tales Of Product Management.

This PM For HIre
At one of the tech vendors who employed me as a product manager, we had a Very Important Customer whose implementation of our software had run aground. Our main contact people in the customer's organization were complaining that we had delivered a product that bore little relationship to what we sold them. The primary medium for communicating their dissatisfaction was a string of enhancement requests that were as baffling as they were urgent.

Despite several long conference calls, we couldn't figure out what the real issue was. We actually had the features they needed, with a couple of notable exceptions that were already in the roadmap. What, then, was the source of their dissatisfaction? No amount of patient explanation about how the product already worked, or what was planned for the next release, assuaged them. They needed a particular set of changes, and they needed them now.

The Customer Always Rings Twice
Unfortunately, the person who had actually sold them the product, and who had met with the customer regularly, couldn't provide any further insights. Someone from the product team needed to visit them. Fingers crossed, I got on a plane.

My first day of meetings with "the customer" were a major step forward, at least in understanding what was going on. Here's the thumbnail sketch:

• We had worked with the head of the implementation team--let's call him Floyd--on an earlier project for the same customer. The need was clear, and the deadlines were firm. For a variety of reasons, Floyd's team built a custom application on top of the Vendor X technology, to meet the needs of this particular project. Floyd and my company, Vendor X, emerged with a golden aura around us.

• Having heard about this success, another part of the customer organization wanted to use Vendor X's technology to solve a different set of problems. The implementation would span the entire organization, and (in theory) the project fit the out-of-the-box functionality rather neatly.

• Unfortunately, Floyd had tasted what it was like to build custom code on top of Vendor X's technology, and he liked it. Even though Vendor X's engineers had invested thousands of hours building an application on top of this platform, it was their vision, not Floyd's, that went into the design. Therefore, in Floyd's mind, his vision of how the application should behave overshadowed what the software already did.

• This vendor/customer snarl might have been easier to untangle, had bureaucratic arrangements been different. Unfortunately, Floyd's implementation team reported into a different part of the org chart than the people funding and project managing this initiative. The business analysts and IT people lived in completely different organizations, housed in different facilities. The 20 to 30 minute drive between their buildings felt more like the gulf between the Earth and Saturn.

• The business analysts were struggling to steer their conversation with us back on a productive vector, but they kept having to fight Floyd for the wheel. Given Floyd's prior experience with the technology, the business analysts sometimes second-guessed themselves. In the process, the line between requirements and implementation disappeared.

The Big Creep
This customer's "requirements," therefore, were actually a boiling pot containing many legitimate concerns, mixed with that organization's conflicts and confusions. The ultimately poisonous combination was impossible for either side in this discussion to digest. Meanwhile, feature creep continued, as both the Floyd's them and the business analysts kept throwing new ideas into the pot, hoping that they'd stumble onto some recipe for success.

Eventually, the altogether too many cooks in this customer's kitchen grabbed for their knives. After the survivors mopped up the blood, they were too weakened by the experience to continue with the project. They looked at other technological alternatives, which didn't progress any farther than we did, since the problem wasn't the technology.

The Customer Has A Thousand Eyes
This cautionary tale may be a bit extreme, but it's hardly unprecedented. Conversations with "customers" often dramatize the quasi-feudal conflicts within their organizations, as they did in this case.

However, requirements conversations may also be deceptively placid. As long as the Support and Consulting people at Vendor X spoke only to Floyd, his requests for product changes were heated, but laregley manageable. The grand mal seizures started, tellingly, as soon as the business analysts entered the conversation with us.

I've certainly faced other situations, as a product manager, in which there were great risks in taking at face value any "customer requirements" from a seemingly calm, rational customer. In a few of those cases, we in Development were dealing with the wrong people. And that's when the wackiness ensued.

I Am A Fugitive From A Dev Team
If I were teaching a class on product requirements, day one would focus on the question, "Who's the person who's telling you what's important in your product?" That person might be reputable, reasonable, and sincere. Or, he might be Floyd. Alternately, Floyd might be lurking nearby, waiting to pounce on the discussion. In the worst possible scenario, the "customer" turns out to be a confederacy of Floyds.

Sadly, too many newly-minted product managers wander into these dark alleys far too easily, with the best of intentions. There must be better ways to learn about the mean streets of customer requirements than the infamous school of hard knocks.

[By the way, if you're not as much of a film noir fan as I am, you might not have recognized the paraphrased film titles that I used as headings in this post. Here's an overview of this genre.]

[Cross-posted at The Forrester product management blog.]

Comments

[Beme]

ok look,the answer is very obuovis- don't eat too much!!think about it- the countries where people don't stuff themselves with food, such as asia, the people are slim, and in perfect healthtoday, the society is all about foodwe're eating because the food tastes good, not because we're hungry!you see food ads on tv, magazines, everywhere!food is everywhere, you cannot go anywhere without being offered food!you need to learn to resist the temptations. back in the older days, you didn't eat everyday! you ate when you hunted and caught food!you would be perfectly fine not eating for a day, it's actually good for you because it cleanses out your body!! all that getting a minumum of at least 1500 calories a day is BS!! you can survive perfectly fine on just 500 calories consumed from HEALTHY food. Sure, you'll have an uncontrollable desire to eat, but trust me, you'll LIVE.and all this diet crap is aimed at overweight consumers. the media suggests that anorexia is bad, all these models are dying blablahblah..that's all just to make the normal obese american feel better!! i mean, how often do they show people dying from being overweight???there's really no need to eat junk food either. it's a waste of money, and all it does is make you fat!! think about it. twinkies and soda and chips don't fill you up, they just taste good, which makes you want to eat more!look at the skinny people nowadays. they don't constantly crave for icecream or stuff themselves with food whenever they see it.