Why PRDs Screw Up Product Development

Anybody who has ever been involved in product development, especially in the computer industry, knows that it is a process that rarely proceeds smoothly. At some point in the development process it is becomes obvious that the product will either not be what was hoped for or will be late. If you are lucky, you will get a product that is just about good enough and close to on time.

Sometimes, you get what you want (or more accurately, what the customers want) when you want it. Rarely. Products like the iPod are the exception to the rule. They hit the right market at the right time with the right features. It's rare because it takes an extraordinarily visionary with the clout in the company to make it happen. Not every company has a Steve Jobs.

Instead, we all get to that point in the product development cycle where Engineering and Marketing/Sales are at each others throats and things are heading south quickly. The culprit? The Product Requirements Document a.k.a. the PRD. It might be called almost anything (Specifications, Requirements, Concept) but it's always the same - the document that defines what the product is and who it's meant for.

"Now wait a minute!" you might be saying "That's the very situation the PRD is supposed to avoid!" By outlining the features in sufficient detail, engineering knows what to build and marketing has the commitment that it will be built when they need it. How could that be the problem.

The problem isn't the document per se. It is what it really means to the people involved. To most of the folks involved in product development, the PRD is a social contract. An agreement between those who build and those who sell to produce something that the company can make money with. There is a lot of emotional and social capital invested in it. For marketing people, their ability to do their job properly as well as their reputations are on the line. For the engineers, their sense of self - as builders and innovators - is at risk.

Inevitably, there is some important feature that turns out to be much harder to produce than was originally thought. That is the nature of innovative products. When the PRD - the contract - cannot be met all kinds of social problems start to raise their ugly heads. To some, failure to meet the PRD is a failure of the people involved, a kind of dishonesty. A breaking of the contract. There is a tendency to try and find fault with "the other side". The feature wasn't well defined. Sure. You guys in the back have been goofing around with unimportant features. Right!

This inherent conflict cannot be resolved easily either. Too much is at stake for all parties for that to happen. Two major drivers inhibit resolution. The first is humiliation. To the engineers especially, this is personal. They are the makers and they can't make. It's like a chef messing up burning your steak. Few organizations are able to deal with this effectively. Even if most of the team acts well, there is almost always some who do not. There is always a few folks who will act dismissively. It is typical for the marketing fool to say something like "I don't understand why this is so hard. It's just code (or plastic or whatever). This is a non-too-subtle way of saying "You are a loser who can't do your job". Not that the marketing dweeb in question has any idea how hard it can be do to code or plastic or toilet seats.

By the same token, there is always some geeky engineers who, in trying to save face, say things like "Why don't you just sell the features we have finished". Again, a dismissive attitude about something they know nothing about. Sure. No problem. Of course, the fact that the competition has what we have plus the feature you can't make doesn't matter. Sometimes that's ignorance talking (most engineers have never had to sell anything - and we are thankful for that). Most of the time it is a clumsy attempt to deflect criticism. In the end, acting this way toward each other makes everyone furious and shuts down the ability to solve the problem.

As an aside, one of my favorite behaviors that you see in these circumstances is The Pointing Out of Flaws. Similar to the Airing of Grievances at Festivus (Watch Seinfeld reruns if you don't get that) it consists of one arrogant jerk pointing out all the problems with a plan while never offering up a solution. I can't stand that. It accomplishes nothing while making everyone want to slap the pompous ass doing it. These people must be put on the spot with "What do you suggest then?" or "Thanks for the analysis. I'm making you responsible for coming up with solutions to these problems."

The only thing that short circuits this behavior is a lack of tolerance for it. Team members have got to be able to admit they are struggling with something without fear of being publicly humiliated by others. Not only shouldn't the dismissive behavior be tolerated but an environment has to exist where small failures can be admitted so that the team can come together and form a solution.

The other reason for product failure is, oddly enough, lack of accountability. In too many cases, either no one or the wrong person is held is held accountable for failure. That happens all the time. In some cases, we are afraid to take people to task because they will become unmotivated (a highly questionable assumption). In other cases there is no way to do so since metrics are vague or nonexistent. Or worse, the metrics are stupid such as lines of code per day. Since no one is accountable for failure, no one is responsible for solutions. So, you don't get any solutions.

The whole team suffers from the slackers or incompetents. Either everyone has to work doubly hard to make up for those who fall behind or everyone gets blamed. That's when the humiliation factor kicks in. If you feel like you are being tarred with the same brush as the guy who isn't keeping up, you will get pretty defensive. It's simple mental self-protection..

The way out of this dilemma is also good management style. Those who bear the most responsibility, the team leaders, need to identify ways to measure outcomes along the way and deal with those who are not making the grade. That can be frightening when it means you may end up shorthanded on the project. Shorthanded is still better than behind held back. If you can't rely on someone, you're better off without them. Jettison them immediately before they do too much harm.

And perhaps, most of all, change the PRD into something that sets the initial course of the project then, toss it in the back of the file cabinet. Let the managers manage to the people and the needs of the market and not a slip of paper. Make decisions together rather than pointing at a paragraph in a document and say "See! It's right there and you signed it. Loser!"

PRDs are fine for describing what you want to do. The team is what makes it happen. Free your team from the contract, refuse to tolerate dismissive behavior and hold everyone (including yourself) accountable for success and failure. You will get better products that way and on-time.

Looking Forward in 2007

At this time of year, there is a tendency to look back on the year that just passed. Subsequently, the industry press and blogsphere is chock full of articles with titles like "The Best of 2006 in.." or "Looking Back at 2006 in...". I thought about doing that too. For about ten seconds. Who wants a recap of stuff we already know. That's fun for cultural ruminations about music or movies but not for technology, especially a subspecies like data storage. We are more interested in where we are going than where we've been.

One of the reasons I was tempted to do a retrospective is because the upcoming year seems to be shaping up to be, well, a bit dull. The last few years have been, technologically speaking, quite exciting. We have seen the mainstreaming of ILM, CDP, disk-to-disk backup, and WAFS. Highly scalable NAS devices and file virtualization, on the edge just a few years ago, are now commonplace.

With all this new technology having previously been introduced, a slowdown is inevitable. Once technology is proven to the point where managers can feel it is safe, they deploy it. That's where the focus will be in 2007. Getting all of this useful technology into the data center without something going horribly wrong. The good news is that after all the data disasters of the past year, there is renewed interest in data protection at the highest levels of the corporation. That means there will be budget for these projects.

For vendors, this is good news indeed. Rather than evaluating new technology, IT managers will actually be buying it. It's a salesperson's dream - something new to talk about that works and that customer might actually buy.

Also on the vendor side, consolidation will continue. The big companies will continue to gobble up the small ones that are still left. Their focus will be on integrating these newer technologies into their overall product lines. To that end, CDP is fast becoming a feature of disk-based backup and WAFS another network service.

Since everyone will be spending their time digesting acquisitions and technology, don't expect radical new technology to hit the streets. Think incremental changes to products rather then revolutionary new technology. Most folks will be too worried about deployment to care about something disruptive.

For sure, some areas will continue to show innovation. Information management tools such as classification or information tracking are still in their infancy. A lot can happen in this arena in the next year. Application specific storage also has some ways to go and will be a hot area in 2007.

A lot will be happening on the consumer side as well. While more a packaging project, making advanced technology available to consumers will be an interesting path for some companies. Seagate and Iomega are gearing up to attack this market head on. As more and more households store and share lots of digital photos, music, and videos, they will need better storage options then a PC hard drive. These products will be well received once the prices come down a bit.

In a nutshell, 2007 will be a bit boring unless you are making or spending money. In that case, you will be very busy.