Who should write the Spec?
Today, at an excellent presentation/discussion of Continuous Deployment organized via IL-TechTalks, one of the presenters (I believe it was Gig from Wix) talked about this novel idea: The traditional role of a product manager is to write specs, which developers then digest and implement. This leaves the PM with the question – after reading the spec, does the developer really understand what we’re trying to achieve with this feature?
Instead, why not create the opposite process? A developer/feature owner and a PM can discuss a feature verbally to get the message across, and then the developer can create a spec document. If the developer really understands the business goals of his feature, this can be an easy way for him to “prove” this to the project manager. I think the role of spec documents is important in some features, because they are relatively cheap to build (compared to a full fledged POC), and help to create a focus point for all parties involved with the feature. By creating and owning the spec document, the feature owner can begin to really take ownership of the feature, instead of interpreting a document written by someone else. Also, shifting the ownership of the spec document to the feature owner enables him to be creative in ways the product manager can’t, because he has specific domain knowledge.
The feature owner is empowered to build the best feature he can that satisfies the business goals and vision outlined by the PM, as opposed to the traditional approach which tends to encourage developers to only make minor changes in the “PM’s spec”.
What do you think? Can this process work at your organization?
