The product manager role is the closest somebody can get to a “swisscard”: a multi resource tool that navigates ambiguity, enabling whatever is needed at any moment. They are enablers. That is, they usually find themselves doing lots of different things at different times. Despite how fancy the role may sounds, succesful PMs remain down to earth in their day-to-day work.
Of course, their responsability is huge. They are the ultimate responsibles for the success or failure of their products. And such a challenge could not be tackled alone. To make it even more challenging, PMs usually lack formal authority – they are not the boss. The also cannot build the product themselves, nor wait to be told what to do.
As a consequence, succesful PMs need to be a natural connector, a broker within the organization that build bridges between teams and roles, between business, engineering and design, to deliver the results the company needs. How to do that? They need to build informal authority through empathy and communicacion – being creative on the ways to align, motivate and inspire their teams. It is more about softskills than it is about talent.
As per background, PMs come from any walks of life and they don’t stick to a the “typical profile” (a comination of business and technical savvy). On the flip side, bad PMs do have some common boicot traits, embodied as the Jargon Jockey (Don’t know what Scrum means?), the Steve Jobs Acolyte (Let’s sit and Think Different), The Hero Product Manager (I could solve any problem myself, but I lack resources), the Product Martyr (my life sucks, but I still keep saying yes to every demand) and The Nostalgic Engineer (I used to write incredible code). Nobody is safe from developing them. Product management can be a brutal trigger for insecurity, and insecurity can bring out the worst in us.
A closing question for our speaker: the broad -and ambiguos- scope of a PMs day-to-day job makes prioritization a essential skill. In that regards, I assume that a big part of the success it is saying no – discarding or pushing back requirements that may arise. So, how can a PM remain a enabler, while saying no to requirements that he doesn’t believe as relevant?
