I’m sure that no one has ever said something that stupid out loud, but everyday many companies are run with this as an unwritten rule. The “Product People” are the ones who know the product, and they tell the “Developer People” what functionality they want. The developers are supposed to take what they are told (usually in easy-to-digest specs that explain where every checkbox needs to go) and code away in their cubicles. As long as they program what they’re told, everything works fine.
It’s a fallacy to assume that product knowledge should be exclusively the realm of non-developers. Both sides need to have a common language to communicate, and this language needs to be based on product knowledge. As a purely technical concern, most software systems are large, complicated, and interrelated. A change in one part of the system might have ramifications that only a developer will be able to track, provided that they have an understanding of how each part of the system fits together from a business perspective. From a project perspective, treating a developer as the “person who goes off and codes what we need” confuses the relationship between the product side and the development side. Most companies think of it as a “middle office vs. back office” relationship, but in reality the product side is the development side’s client (as the users of the product are the product side’s clients). The product side needs to provide a set of requirements, and the development side needs to find out what the client needs, and how to deliver it. The development side has to have enough product knowledge to determine the actual need, not the stated want. In the “go off and code what I asked for” type of relationship, the product side gets what they want, which isn’t always what they need.
I’m not saying that development teams aren’t to blame here. I’ve worked with many developers who are content to do whatever they are told, even if it means re-doing the same code multiple times as the product side figures out what it actually needs. There are some developers who are purely interested in the technology side of things, and will not pick up any product knowledge no matter what they do. Companies need to recognize that there are times when product-focused developers are needed for a project, and there are times when you need a pure tech geek (especially when a server has just crashed). But in general, companies should make general product knowledge readily available to development teams (and a requirement for certain developers), which will improve the dialogue that composes the software development process.
*Craig thinks that this is part of a larger “Business” vs. “IT” phenomena, and is going to post on this topic soon.