Tag Archives: Product Manager

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))

Ladder to Product Management

Engineers largely get into the job without any exposure to sales, operations or financial aspects of the business. In contrast, the role of product manager has its roots in marketing function. The switch in role from engineer to product manager is more of a shift in mindset, something that looks easy on face value but is tremendously difficult to achieve. Given an opportunity, it is wise to get some field experience prior to getting into the routine activities of the product manager. Here are few steps that I suggest that will such aspirants become a better product manager or step into the role of a product manager.

Ladder to Product Management

Ladder to Product Management

Business model: First step is the purpose of existence of any business. What is that is making me money? why are they paying choosing us, buying from and paying us? This brings in a major change in an individuals mindset specifically when he / she is moving from technology to a product management role. Look at your product from a buyer’s point of view rather than an engineer’s point of view, trust me, square looks quite circular when you bring in this change in angle.

Standards: Compliance, rules and regulations are very important. They govern the way business work, products are developed and services are delivered. Feel lucky if you don’t have any such guidance but if you have better master them as they are most important while writing specs or negotiating with customers.

Operations: Knowing about operations is as important as knowing the various practices of the religion one follows. What is to be and how is it to be done and why is to be done. Products developed by software are tested in lab under controlled environment, whereas on most occasions these products are deployed and used in hostile environment with lots of unknowns. Learn about operations as it helps in knowing what can be committed and what not, what should be on road-map and what not, and lastly how to develop and how not to.

Competition: Who else is there and how different are they? What is that they do better and what is it that are not doing good. What could have been done better while developing the product and are pitfalls that should be avoided. Competition helps us understand a larger picture of the product / domain we are in. It helps us understand the taste of customers in various market segments.

Customer exposure: Success of a product is measured by the Customer adaptation of the product. It is very important for a product manager to understand what their prospects and existing customers are expecting out of their product. A first hand customer experience is always preferred as often customer requirements gets diluted as they traverse down to product owners. Learning customer behavior, preferences, challenges and ecosystem helps product owner’s in authoring customer friendly specification and in taking right decisions in the course of the product development.


What’s your concern?

What keeps you concernsawake at night? what is one thing that keeps you on your toes?. The answer to this question is probably the core tenet of your profile and also your  organization’s expectation from you. It is good to know the answer to this question since it also helps in prioritizing your tasks at work. Here are some replies that I often to get to listen.

  1. too many bugs towards the tail end of the release
  2. long backlog list, I have too many features to add to the product
  3. competition, losing too many orders to them
  4. scope creeps
  5. over demanding stake holders
  6. Unreasonable customer demands
  7. opportunities  in market place
  8. too much interference from top management
  9. product road map
  10. …..many more

The answer to this question is important for you. Should this concern be your top focus? Is this concern taking away crucial hours from your planned strategic work, if so you are prone to spend significant amount of your time in coming days doing firefighting. Spend sometime, to begin with may be every week to get answer to this question. List down your top concerns and be sure you have strategic plan for concerns that are your priorities and permanent alternate solutions for concerns that are not part on top of your to-do / KRA list.