The multiples hats of a PM role

There is a question I hear a lot from my family and friends that do not work in IT: What do you do exactly? Looking back at the many times my mom asked me this questions, for example, I need to say that I believe she has not a clue about what I work with. When I was working as a BI engineer the maximum I could see people understand was when I said that I developed systems that builds report. And now that I am a product manager, should be easier right? I wish! Now I think my mom believes I manage people, which is the only thing a PM does not do.

Photo by Minh Pham on Unsplash

In the past 3 to 4 years I have been reading lots of books regarding the PM role and about working with IT products. What I could say is that, all the good books agree on what the scope of being a PM is: we get things done. And looks like a good description for me.

As PM, we need to allow the developer team to do their job, removing any possible blockers and giving them as much information as possible. We also need to work with stakeholders to understand clearly what are their needs and issues that must be solved, at the same time we need to keep everyone focus, avoiding deviations on targeting the main goal.

Another thing that I see as a common task for PMs is to keep things simply. It is easy for developers to imagine a perfect solution with the perfect architecture for the system, at the same way it is easy for stakeholders to dream about a product with thousands functionalities and all the flexibility they want. But when building a product we need always to start with the simplest user case. We need to delivery simple things in order to understand the what needs to be improved, what does not work at all or what is already good enough. Also, priorities and requirements can change with time, and a constant review of priorities and scope of a product allows us to keep the right path on the product development. And, what is really important for companies, that helps to avoid the wast of money in a long development that does not achieve the goal.

Going back to “get things done”, many times a PM needs to assume tasks that could be said not to be part of the scope of the role. It can go from queries, reports for users, investigate business topics for stakeholders when they don’t have the time and it could become a blocker, have a development environment in your computer for executing recurrent tasks that are blocking the development team, and so on. This list can be long. But that also requires caution. If you work at a start up this behavior is highly appreciated, but if you work in a hierarchical company, with roles well defined, this can become an issues. In hierarchical and bureaucratic companies, even if there is no one taking care of something that is a blocker for you, you should not assume and work on this task, even if it was agreed. This can be seen as an offensive and bossy behavior, for example.

In other words, we need to keep the product’s project walking forward and with focus, adjusting the direction at every interaction, even if we need to assume the not owned tasks. Of course, that also needs to be done with attention. We should not allow “get things done” and “assume all not owned tasks” mottos to get into the way of our regular tasks and we always need tp keep high collaboration with other members of the team and of the company.

And do you wanna know what my mom says when people ask her what her daughter does? “She works with computers!”

Photo by Todd Quackenbush on Unsplash

Any thoughts on that?