This blog has moved to Medium

Subscribe via email


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?

4 Comments

  1. Avish:

    I wrote a really long reply but it got lost in a crappy error message. In short: it’s a good idea in non-user-facing features (e.g. “provide good product recommendations that would make the user buy more products that suit her taste”) but is very hard and dangerous in user facing features, since the process of going from business goals to spec requires a lot of skills not normally held by (all) developers, e.g. “thinking like a user”, UX, understanding the use case and translating it into a streamlined flow, copy writing, “product attitude” etc. These are skills product managers should hone and developers are frequently blissfully unaware of. That being said, it’s important to involve developers in this process so that those of them who show an interest in it can be grown to be product managers.

  2. Moshe Kaplan:

    Hi Ron,

    Gig indeed talked about it, but his phrase was something like “I hate specs and try to avoid them”. Gig prefers that every engineer will be a product manager and write his own PRD.
    I like Gig opinion and I believe that specs should include only API when needed, otherwise they turn old once you finished writing them…

    It was a great event and probably I will contribute a post regarding it in the next few days,

    Keep Performing,
    Moshe Kaplan

  3. yaron:

    hmmm, then what does the PM do?
    Actualy, writing the spec helps the PM understand the requirements.

    I think it might be better if the feature owner writes the ‘test cases’ for the spec.
    This way you get to see if he indeeds understands the requirements, and you get tests.

  4. ripper234:

    @Moshe – avoiding specs is preferable when possible, just like avoiding comments in code. However, for medium-large features that are done in one bulk, I think that writing a spec actually saves time. Not every feature can be partitioned to super small pieces. It should, however, not be a huge monolithic document that takes days to create.

    @yaron – A PM is the owner of the product direction, and he is responsible for formulating and prioritizing the features, and maintaining the higher level Product Vision. However, I believe that much of the PM’s work should indeed be delegated to feature owners, with the PM remaining as the professional authority and guidance. Asking the PM to define every nitty-gritty detail is very demanding, and doesn’t necessarily have positive ROI. Of course, a PM should be “big enough” and willing to pass some of the control to the feature owners for this model to work.