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.