You reap what you sow, specially as a Product Manager
As a Product Manager joining an organisation, you may fall straight into project management mode: the team is probably feeling they have too many competing priorities and need someone to organise and prioritise the work.
So if you are any good at it, project managing whatever developments are ongoing can be a safe haven for a newly hired Product Manager such as yourself: it is an area where you can add value quickly and win the confidence of the team.
At the same time, the rest of the organisation will be feeling that they need more visibility on when things are coming out, so you will timidly start to produce a roadmap together with the CEO and/or the CTO, based on a number of inputs (mostly internal at this point).
Everybody will be happy with your work: you've come in and cleaned house, you've started building and sharing a roadmap and communicating what is ongoing. Feels like progress!
Meanwhile, without realising it, you will probably have done yourself and the company a huge disservice.
Wait... What?! Why??
They say that actions speak louder than words and, specially in companies without much product culture or experience, by taking on project management as your primary duty you will be relaying precisely the message that project management is what you do.
But you are a Product Manager, and your job is not about building things: is about ensuring the right things are built. Project Management might be part of your job at times and something you will no doubt need to help out with, but it shouldn't be your main job.
If you start by project managing and become indispensable in that arena, you will have a hard time freeing time to work your way through to the other end of the spectrum of your responsibilities: researching and understanding customers' needs, coming up with solutions together with the team, validating the usefulness of what you build, and using all of that to help inform and evolve the company's purpose and longer term vision.
At the end of the day, as a Product Manager you should judge yourself (and sooner or later your CEO will too) by how successful your company is thanks to the products you manage.
If what your team builds is not what the customers want, if it doesn't sell, no one will care about how well you project managed the whole thing, or how much the team loves you because you prioritise their tasks and spec them out beautifully. On the contrary: they will eventually wonder (and rightfully so) why did you build those things in the first place.
I speak from experience: in CARTO I took over Product in a very delicate moment and, for the first 6 months, I was on pure execution mode: pretty much all I did was to execute on someone else's roadmap. When I eventually looked up, we had built and fixed and improved loads of things: but were those the right things? The things that would really move the needle? Most of them probably weren't, if I'm totally honest. And although I hadn't really chosen those things, I was still held responsible for the outcomes (or lack thereof).
James Clear, the author of "Atomic Habits", argues in this interview that pretty much everything that happens to you is a "lag measure" (a reflection, let's say) of your habits: how fit your are is a reflection of your eating, sleeping and exercising habits over time; if you make enough money, how much money you save is a reflection of your spending and financial habits; how clean your desk is after a while is a reflection of your organisational habits, etc. And these habits have a compounding effect over time, for better or worse.
So, as a Product Manager, you should think about that eventual "lag measure" you want to accomplish and commit as soon as possible to keeping the habits that will contribute to it. Ask yourself questions like these:
Over time, what will have more impact?
- Being part of every single development discussion or reading and answering customer support emails (so that you see first hand what problems they are suffering)?
- Attending every stand-up meeting or attending more sales calls (so you can understand use-cases and gauge reactions to features and demos)?
- Making every single product decision for the developers and designers or spending more time explaining what outcome you are trying to achieve and why (so that they can take those decisions themselves)?
Something worth considering, wouldn't you agree?
I wrote a similar article to this one a while ago from the perspective of a VP of engineering or engineering manager. You can read it here if you are interested.