Category Archives: Leadership

Product Management by Committee

One of the key issues that plagues a delivery team is having no Product Manager to guide the team. However, something that is more troublesome is having multiple Product Managers for a single product. This is what is sometimes referred to as “Product Management by Committee”. I am reminded of a scenario where a boat in a race had 5 people managing it and 4 people actually rowing.

Did you say “Oh, Come on..!! it can’t be that bad” ?

I personally feel that if you want to set a team up for failure, this is one of the things that you could definitely do.

Let us take a closer look at what the problems could be, with having multiple product managers.

Same goal, different priorities: Each PM tries to push his Agenda. Many times, each PM might have the same overall goal, but different priorities. They don’t want to contradict / confront each other. Often, they end up talking to some key resources in the team and pushing their items / enhancements without letting the other PMs know.

Collective knowledge or Collective confusion? There is a possibility that each PM has a different understanding to a scenario in the Product domain. For example, 2 PMs might have varying understanding of how an Insurance claim is to be handled when a car being driven by a person less than 25 years of age gets into an accident at a roundabout with a car driven by a drunk person. In such a scenario, the team would be chasing a moving target if they have to listen to both PMs.

Personality clash: PMs come in all shapes and sizes. Some are more technically oriented than others, some more forceful, some more knowledgeable and some more articulative. When you have a mix of such people providing directions, the team would be torn apart and staring straight at failure.


When Ted, my colleague took up the role of the Scrum Master for one such Agile team, this was one of the things that he identified as a failure factor. He set up a meeting with all 4 Product Managers and told them that henceforth the team would be happy to take inputs from all of them, however, all decisions and directions only from one of them. The PM committee now had to decide who that would be. They nominated Dave ( one of the key stakeholders within the PM committee) to be that person for the duration of the current release. This meant that

  • Dave would set priorities for the team and define the Acceptance criteria for each story.
  • Dave would resolve any conflict of ideas within the PM committee and provide direction to the Delivery team.
  • The Delivery team is not faced with various personalities with different agendas providing conflicting requirements. The team and PM have an opportunity to understand each other well and compliment each other for a successful delivery.

The team is now slowly increasing their iteration velocity, meeting most iteration commitments, gaining the trust of senior management and is able to enjoy their work. I believe this change has been the major factor in causing this turnaround.

Let us know what you think…


(Pic: Thanks to Remix Monkeys (A new creative look and Style on Urban Dance))

When the Product Manager is no longer really a Product Manager

When a new game changing feature is introduced, a Product Manager Owner – true to one’s role, does not draw lines limiting responsibilities, owns all the aspects of the feature from operations to user experience to go-to-market. The Owner comes up with the metrics that needs to be measured, works closely with all the departments like the master of an orchestra to ensure that the feature delights the customer and meets business objectives. This will usually take several iterations, pivots based on learning from experiments and sometimes operational changes for the product to gather critical mass and reach a cruising altitude. What happens next usually is that this Product Owner sub-consciously transitions into Product Manager – continuing to manage every nitty-gritty of the feature in a typical run-the-business sort of operation; nothing wrong – perfectly fine. This sub-conscious operation leads to most often playing the roles of Program Manager or an Engineering Manager or an Operations Manager. Organizations can often fail to take cognizance of such a situation and any such protracted scenario can lead to:

  • Professional staffing ignored: Product Manager operating in roles which require specialized skill-set to maximize efficiency can reduce overall efficiency. For example a skilled project manager brings his expertise in efficient resource utilization and a product manager really may not be able to concentrate on that aspect they way it should be done.
  • Reduced strategic thinking: The Product Manager is bogged down by issues that needs to be solved to run the business that he stops thinking strategically from a product’s road map perspective. A product stagnates. Crossing the chasm after a long period gets tougher and interventions become painful.
  • A rock-star Product Manager does not remain one

What should be done ideally?

  • A product manager (ideally the director of product management) should identify when the product’s/feature’s gestation period ends and requires product management not to hang-on to things which are not typically functions of product management. This requires structural changes in the organization and establishment of matrix structures to function effectively
  • The product manager should define process and the corresponding operational metrics required for healthy functioning of the feature and help in setting up specialized teams for the purpose before abdicating some roles which he used to play


There is another school of thought that Product Managers have to be jack of all trades. Definitely, yes. It is needed during gestation period and perhaps during formative years of the product.