Product Manager through the eyes of developers

Most of the articles and books on Product Owner / Product Manager are about how to identify the right product. But there is an equally important part of the work - how to make this product together with the team.

I asked two simple questions to my friends from different grocery IT companies:

• What do you value in a good PM?
• And, on the contrary, what irritates you most of all in the manner of doing business with PM?
  

The sample is not very big 20 people: developers, designers and testing specialists. Here is the final hit parade.

Positive sides.

1) Love the product. It is difficult to infect the surrounding ideas if it is not interesting to yourself. There is not enough professionalism, from now on for you this is a major hobby.

• You need to know everything about users, how they solve problems with or without your product.
• Know everything about the industry, competitors and related fields.
• Possess statistics and objective quantitative data.

2) Communication and relationships with the team. You are the main link between completely different people, often weakly representing what the other part of the team is doing.

• Discuss solutions with the team, consult, listen carefully. You do not need to be a prophet who knows everything and has already decided everything. Feel where you should consult or entrust the decision to another professional.
  
• Accessibility and openness to the team. It should not be a big problem to find you and discuss a difficult question.
  
• Different people need a different approach, each has their own favorite way to communicate. For someone, the ideal option is a conversation, and someone prefers a verified letter or comment in the task tracker. Learn how to combine different forms and look for an approach to different people.

3) Competent planning, the ability to coordinate various teams. Old and good skills of a classic Project Manager.

• Give the chance to be engaged in professionals in the own business, protect them from everything that is unusual for them, interferes or distracts. In return, you will get a return and very high productivity.
• Clear and competent description of the product and tasks. Although in agile the main method of transmitting information is a conversation, this does not at all cancel the current documentation. For you, most of the details seem obvious, but this is not the case for the rest. In addition, conversations tend to be forgotten after a couple of days.
• Understand the basics of the various team members, how they do the work and what they need for it. Shells need to be brought on time and the right caliber.

')

And now the main disadvantages.

Not surprisingly, this is a mirror image of positive qualities. But still, in my opinion, it is worthwhile to dwell on them in more detail.

1) Micromanagement, the most terrible disease of any leader.

• No manager has admitted that he suffers from this. On the other hand, this diagnosis is always obvious to others. Talk about this with different people in the team. You may learn a lot about yourself.
• You do not need to go into technical solutions, even if in the past you were a great developer, or prove to the designer that the button should be green and to the right. This is a sure way to break up the team or quarrel with individual participants.
• If your views diverge fundamentally, try not to work together, you will save everyone a lot of nerves and time.

2) Do not force the team to do unnecessary work.

• Unnecessary meetings, reports, status rallies. For the team is a waste of time. All this information can be obtained without distracting people from work.
• Get ready for the meetings. It seems to you that you can come to a meeting and improvise on the go. From the side it does not look so smooth. As a result - ill-conceived solutions, tasks that will then have to be redone. And to redo it not because something has changed in the surrounding world, but simply due to the fact that you were too lazy to think it over.
• Inattention and disrespect to the team. A new build, layout or something else has been made for you. And you did not even look. The team has the feeling that no one needs the result. Why next time try, who will appreciate?

3) Inability to say no. There will always be more ideas and ideas than you can do.

• An endless stream of different ideas, requests and requests. Uncontrolled changes to plans, an incomprehensible set of hundreds of different release features.
• No hack work, there must be a high professional level, below which no one else in the team can fall.
• No external hotkeys, unrealistic deadlines, etc. Protect your team from negative external influences.

Conclusion for PM'ov.

The result was a rather obvious checklist, but the most difficult thing is to follow these simple rules. Check yourself, do you pay enough attention to these things so that you can do better?

Conclusions for developers.

Leave your view on the work of PM in the comments. I think that this is the case when the comments will be much more interesting than the article.