Developers Don’t Need To Know The Product

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.

4 comments

  1. Morgan

    Every company goes through this. Product people are great because they’re ignorant. They learn from the developers and they become more familiar. They talk to the customers, trying to understand wants and needs. This is how things should be.

    After about 3 months, the product people become familiar and start understanding things. They become good at their jobs, and they become able to predict what developers might say. They have some technical experience, and their expectations are well-founded.

    The only way I’ve found to combat this is to be honest, strong-willed, and process-driven. This also assumes that you have a process that produces division of labor. Here’s how we solved it:

    Product created requirement tickets. They produce definitions of need. They can make suggestions about how to solve problems, but it’s up to the developers to produce work tickets against those requirement tickets (we use tasks and sub-tasks in JIRA to produce this division).

    Requirement Tickets are estimated in Story Points (due to complexity) and Work tickets are estimated in hours, due to effort required. This produces both a complexity velocity and a point accuracy metric.

    If a requirement ticket says “do something” instead of “this is the problem” it’s immediately apparent. If Product creates a work ticket, they’ve overstepped their bounds.

    Remember, Product is a team of your peers, not your managers. If you let them, they’ll tell you what to do, but ultimately, it’s your choice.

    • In Moyes We Trust (@benkross)

      Hey Morgan,

      Thanks for the well crafted response. We’re glad that John’s post was able to elicit a reaction. I’d be curious to chat further about it with you. The last company i spent time with had a major disconnect between Product and Dev. BTW, I noticed your affinity for Node.Js, would you be interested in an intro to Nodejitsu? I am an advisor to them and the CEO is a friend.

      Cheers,
      Ben
      CoFounder
      ben@projectsherpa.com

  2. John

    I agree with the general division of labor – Product shouldn’t dictate how the work is done, and Development shouldn’t dictate the requirements. There might be restrictions due to business/technical limitations, but that’s hashed out as part of the review process.

    You’re saying that Product is supposed to pick up some technical knowledge over time; does the reverse hold for Development at your company?

    • Morgan

      You’re asking if the developers are expected to pick up some product knowledge as time goes on? I think the term “expected” is what’s throwing me off. The connection between product and engineering is ill-defined, which causes much of the tension. I tried to define it through process, and had fair success. I know that I like to know as much as possible about the “why” of a task so that I can make a decision founded in knowledge, but nobody has ever told me that becoming familiar with company need is part of my job. Yet, for anyone to ignore that seems to be a poor choice.

Leave a Reply