Recently I participated in an software process assessment for another group in our organization. What I realized afterwards was that much like the butterfly who flaps his wings in Africa causing a chain of events that results in a hurricane in the Caribbean basin, a problem in the the software process has cascading effects to the later aspects of the process. Get too many problems early in the cycle and you end up swamping your testers in an unending maelstrom. In this case, most of their problems originated around requirements; what was or was not in, and whether the were developed appropriately. Like most issues with any maturing software process, a lot of things conspired together to make this a nightmare, but I think the primary reason was lack of a strong (or in this case any; they burned through 2 in a year) Product Manager.

A Product Manager is I think the most important person in a software development organization as everything flows from them. Sure, if there was no developers, nothing would get written, but without product management, they have no marching orders to go on. Consider them the axle point on a cart wheel. They are connected to all areas of the product and without them the wheel falls off. Which you don’t really want.

So what are the roles and responsibilities of a product manager?

  • Central point of requirements knowledge: Product management is the final word on all things requirement related, and therefore must be actively involved in any discussion surrounding requirements, including
    • Gathering (external: what competitors are doing, analysts, etc) — product management should be the ones with the closest view of market trends, be the ones who meet with Gartner to get into the Magic Quadrant etc.
    • Gathering (internal: sales, consulting) — product management’s phone number/email should be the only point of contact into a product group that sales, sales engineers, internal consultants etc have. Under no circumstance should development or testing be contacted directly by the field regarding requirements. If they are, they should be instructed to redirect them to product management because as soon as they agree to some “tiny” requirement, suddenly the who project planning exercise is undermined and you have entered the glorious realm of feature creep
    • Release Specification — every project/release has certain requirements that must be implemented; these originate from product management
    • Development — at some point a developer who is tasked with implementing a feature is going to have a question similar in form to “Is it supposed to be like this, or like that?”. By definition, the only person with a large enough view of the world is product management, so only they can answer the question. If you omit product management from the requirements development phase you run the risk of spending a tonne of effort on coding only to find out “Thats not what I wanted”.
    • Verification — Part of the testing process is Requirements Verification. Test is going to want to ask product manager for each item in the release specification “Does this do what you wanted?”.
  • Product Direction/Positioning: Product management is responsible too for roadmapping and guiding the product along its life. They also are the ones who (should) know (or have a really good guess) of what the next curve is going to be and steer the product appropriately
  • Be the face of the product: A product management job is by default a “travel required” position. Product management will need to be at all the major industry shows and analyst conferences representing the product and being it’s biggest evangelist. They could also be involved in direct customer negotiations if the company is small (few, if any sales engineers who can do the product demos) or big enough (deals worth massive money and the potential sale wants high-level product involvement)
  • Vet the bug list: The product manager should always keep an eye on the sort of bugs that are coming in from both internal and external sources. Product management is ultimate authority on which bugs must be addressed in a product. If a tester feels strongly about a bug, but the development manager disagrees, the tester should be able to make their case to product management who could agree (and therefore the bug will be addressed) or disagree (obviously then the development manager’s original assessment was correct). This situation is most often going to occour either when a tester is new to the organization and does not know how bugs are weighted yet, or during final release crunch when decisions start to be made according to the distance to release versus quality (the latter being a rant scheduled for some time in the future). Even if a bug is not brought to their attention directly, the definitely need to keep an eye on the bugs that are differed as it could be that the development manager has accidentally annihilated a good deal of product value.

I’m not sure how much of time should be dedicated to each task, but I know that some people have developed specific percentages. I think that each of these items tend to operate at different points in the cycle, so assigning percentages is way too difficult. What I will say though is that realistically, the role of product manager is too important to do part time. A product manager should manage exactly one product, and if there is a number of products marketed together as a suite, then there should be person dedicated to managing the suite (with the product manages reporting to them).

A few traits I think good product managers have are

  • marketing experience: While marketing droids may be the bane of development, it helps greatly to have product management have marketing experience. This experience will assist them in asking the right questions correct (which is key; ask the right question the wrong way and you will get the wrong answer) and plan the product’s placement in the market.
  • masters at managing email: As you might guess by now, product managers get swamped with email. especially the good ones. They must be be able to deal with this barrage efficiently and effectively. Not doing so is one of those butterfly flaps.
  • credible in the eyes of their team: A product manager who is not credible in the eyes of their team will eventually be cut out of discussions they should be involved in. “I have a requirements question, but the Product Manager never seems to have a clue, so I will ask since they are smarter.” While the reasoning may be sound and the product manager has dropped the ball a couple times, cutting them out of the loop sends the project into dangerous waters. Likely without a life jacket.

One final bit. I mentioned earlier that a product needs strong product management. By strong, I mean no-nonsense in addition to credible. If sales continues to contact people inappropriately or development continues to make product decisions without product management input, it is up to the product manager to give them a lashing. One that has the full weight of management behind it.

I’ll try to wrap this up with an analogy. Imagine your organization as the Spanish Armada. Management plays the role of Admiral, and tells the armada where they are going (to the New World!). Product Management are the ones Captaining the individual Galleons, telling their crew where to point the ship (approximately south-south-west). If the person manning the wheel is uncertain they are still heading in the right direction, then they can ask the Captain who will correct course as necessary. If a merchant was to ask the wheel man to make a detour via the Canary Islands along the route directly, they would be keelhauled (any day you can work that into a sentence is a good one I think). So too should those who do not go to Product Management any time the product is being affected by something.