Product Manager through the eyes of developers

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

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

• What do you value in a good PM?
• And conversely, what annoys you the most about PM’s way of doing things?
  

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

Positive sides.

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

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

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

• Discuss decisions with the team, advise, listen carefully. You don’t need to be a prophet who knows everything and has already decided everything. Feel where it is worth consulting or entrusting 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 issue.
  
• Different people need a different approach, everyone has their own favorite way of communication. For some, the ideal option is a conversation, while someone prefers a verified letter or comment in the task tracker. Know how to combine different forms and look for an approach to different people.

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

• Give professionals the opportunity to do their job, protect them from everything that is unusual for them, interferes or distracts. In return, you will get returns and very high productivity.
• A clear and competent description of the product and tasks. Although in agile the main way to transmit information is through conversation, this does not completely cancel the current documentation. For you, most of the details seem obvious, but this is far from the case for the rest. In addition, conversations tend to be forgotten after a couple of days.
• Understand the basics of the work of various team members, how they do the work and what they need for this. Shells need to be delivered on time and of the correct caliber.

And now the main disadvantages.

It is not surprising that 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 worst disease of any leader.

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

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

• Unnecessary meetings, reports, status rallies. For a team, this is a waste of time. All this information can be obtained without distracting people from work.
• Get ready for 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 decisions, tasks that will then have to be redone. And to redo it not because something has changed in the world around us, but simply because you were too lazy to think it over carefully.
• Inattention and disrespect for the team. They made a new build for you, a layout, or something else. And you didn’t even look. The team has the feeling that nobody needs the result. Why next time try, who will appreciate?

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

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

Conclusion for PMs.

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

Conclusions for developers.

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