3 things that a Product Manager should not do
Be a Product Manager is annoying sometimes. A lot of people think that exist some glamour in be the person behind the product decisions and this is what seduces the unsuspecting crowd to be a PM/PO. The point is: don’t exist just one person behind of a product, but a whole team. Soon, some PMs or POs insists on falling into the spotlight trap. I separated three things that a PM/PO should not do, that in my opinion, can make the relations between of PM/PO and company worse. Follow:
- Don’t try to build something that only you think is the right thing;
- Don’t forget to give credits;
- Do not expect the team to blindly execute your ideas.
Don’t try to build something that only you think is the right thing
It is normal that a PM collects all the opinions and critics about a product with people of many areas. People with different perspectives and expectations, that many times can have strong opinions because that problem affects them every day.
This position is very privileged because it is like you had eyes everywhere with access to different perceptions, with a panoramic view of the problems that users may be facing. A good PM can gather this information and use in favor of the product. However, if you can not handle it well, you will think that all this mass of information had originated from you. Soon, you become the owner of the truth and think that everything written in your User Story is a correct thing to do. And, at this point, you lose.
Probably you should work in a multidisciplinary team, composed by designers, front-ends, back-ends, QAs, BI, marketing etc… all them, in some way, handle with users. Although one of your responsibility like a PM/PO is to advocate for the users, they do that in your own specific way. The union of your powers should reflect the user needs and feedbacks. The good PM/PO helps the team deliver the right product to the users, and, many times these means deliver a solution that you don’t think is the ideal solution, but the team has 100% of certain that is a good thing. I know how you will feel about that… It is as if you are losing power, getting your ego hurt because you feel that you should be responsible for all the ideas in the product… but relax… don’t try to build something that only you think is the right.
Don’t forget to give credits
If you pay attention to the previous point, many things implemented in the product will not be your ideas. Don’t be sad about that, you are not the only responsible to give good ideas to the product, you are just the responsible for the product. This means that you are responsible to validate if an idea is good or bad and usually you don’t do that alone.
Designers, usually, have great ideas when they are prototyping and investigating some task. The stakeholders have some good (and bad) ideas too. The credits to these all good ideas need to be exposed and the idea owners need to receive these credits.
Another day one company director, that don’t know enough about product management, propose that we need to do an MVP to takeoff a doubt. He was extremely correct at the moment and I felt really bad because I did not give that idea before, which was the most obvious thing to do.
Giving credits for good ideas encourages the team. Usually, I always try to give credits to the team and try to encourage each one in the team to do the same. If all goes right, all will win. The good idea and the good execution is not a property of one person, but the team. This applies to the bad ideas/execution.
Don’t wait that your team blindly execute your ideas
One boring and the most important task of a PM/PO is put on the paper (pipefy, jira, trello, etc) all ideas in a format that team can read and execute without doubts. These texts are known as User Stories. This same ideas need to be presented in a good way to the C-Level, obviously, not a user story format. But, usually, we write these stories putting us on a client side, giving all details and requisites that the team need to execute.
A weak team executes these tasks strictly following what you wrote. A weak PM/PO don’t give contexts to the team about the problem or objective. Generally, before we write a user story, I do a document with contexts, telling why we will do that feature, showing to all members what the results we expect when that feature goes to production.
The PM/PO should not wait for the team execute your tasks without question, and the team needs to know every why about that task. This promotes complicity and makes the whole team united in a common goal. If the team know the contexts, every member can defend the idea with good arguments. I’m not saying here that the team needs to be convinced the whole time about each task. In an environment where the team is well-informed and understands the vision of the product and the company, the motivations behind the story will be clear from before it is written and prioritized. And that same team knows that the PM has gone through a giant process of finding out about the suggested solution.
Conclusion
These three points seem to be pretty obvious, but I see people breaking their heads every day because of them. Watch for symptoms. The team’s confidence in the PM says a lot of. The responsibility placed on the PM by the C-Level says a lot of. The way the PM handles these problems tells you how committed the PM/PO is to the team, to the company and the product.
