• http://www.flickr.com/photos/thenationalguard/
  • http://www.flickr.com/photos/riebart/
  • http://www.flickr.com/photos/ell-r-brown/

One continuing area of contention that I come across almost daily is where Product Management and Development overlap. In this second article on the topic, I’d like to put some more definition around how the two groups work together to make decisions and provide direction.

Some organizations have Product Management and Development (or Delivery, or Creation, or whatever your organization happens to call it) reporting in through the same structure, where most have them separated. Either way, people tend to get confused about who should be defining or deciding what as it relates to the creation of your product. Product Managers can get far too involved in defining the solution to the n’th degree to the extent that they might take decisions out of the expert’s hands and ultimately hurt the product timeline or quality as a result. Alternatively Development can get too involved with product definition to the detriment of the product itself in allowing the technology to define the product.

By defining roles based on one simple concept, Web, Application, Print, Creative, or even Architectural Product Management and Development can easily understand their roles and be the experts they need to be:

Product defines “what”, Development defines “how”

What does “what” mean?

What “what” means is this: As Product Managers, we’re responsible for Product Definition. A little simple, and vastly understating what goes into it, but – this is the core of Product Management. So taking this core competency, we’re responsible for defining “what” a product should be. “What” means what it does, what it looks like, what it will be used for, who it will be used by, etc. (see my earlier post on Where Product Management meets Product Delivery).

How is “how” different?

Here’s how “how” makes it’s mark… “How” means how it works, what technologies are used, which principles are selected, and how the pieces fit together to create the end product defined by “what”.

And never the twain shall meet?

This definition has been immensely helpful everywhere I’ve implemented it – both Product and Development folks have appreciated a clearer line of responsibility and the simplicity with which it can be understood. But this is not meant to stifle input from one team or the other – Collaboration is the name of the game and this principle merely reflects lines of responsibility, not lines of communication. Many a Product Manager has saved weeks or months of time and vast quantities of money with great suggestions on how something should be done, and products have been saved from damnation by perceptive Developers sharing thoughts on what something should do. So please – don’t use this principle to stifle communication… embrace it as a responsibility separator and everyone will be happier and your products healthier!

Loading Facebook Comments ...

Leave a Reply