Product Manager: Sophomore Year
Last year I wrote a short essay summarizing my first 365 days as a Product Manager. One more year has passed, and it is time to share more insights or learned lessons.
Important notice: It is only about my experience, so some things may not apply to what other PMs are experiencing. Product Management is a vast discipline with different responsibilities across different companies and industries.
Identity crisis
The more I read books or consume other content about Product Management, the more I ask myself, "Am I even a real Product Manager?" Sometimes I feel like a Jira backlog administrator, and sometimes like a Project manager who needs to go through and respond to dozens of emails daily and micro-manage to make everything work.
There were a few moments when I wanted to switch back to Business Analysis, where I felt safer knowing which tools to use and what I could achieve with them. PM is responsible for everything but usually without any means of power. And the sense of powerlessness is devastating. You see multiple success stories around you and push more, but the outcome remains unchanged. So you start questioning your abilities which affect mental health.
But the truth is that you can't build a solid house on sand. You can die heroically doing that but what for? The reasons may be lying outside, and I should not blame myself. Maybe. I know what I am capable of.
People (often don't) know what they are doing
I have naive assumptions that I am surrounded by professionals who know what and why they are doing. Mainly, I have never questioned higher management. I could argue with some decisions but never disagree with a general direction. I thought that the smartest guys in a room with dozens of years of experience and university degrees I only could dream of, knowing what they were doing. In reality, it is not always the case.
That also applies to some peers from whom you expect to resolve some dependencies. If your team has an external dependency, you must put extra effort into managing this. It is not only about a schedule but also what and how it will be delivered (if delivered at all). And also, only some people care about mid or long-term consequences.
I'm not too fond of the escalation. I want peers to align with each other, commit and follow and respect the commitment. Unfortunately, that is not often the case for various reasons: incompetence, lack of responsibility, and "hidden agenda."
Look outside and share what you see
When you are developing an internal platform, you focus needs of a department or an entire organization. At some point, when we were at a crossroads, I understood that we were unlikely the ones who solely fought a similar problem. We cannot look into other internal platforms, but we can research how open-source and commercial solutions are trying to resolve the same issues.
So I started revising any available materials: user and technical documentation, release notes, webinars, etc. I was particular about how they approached the functionality we already have and how they designed solutions we only plan to implement. Then I did a summary and presented it to the team. There were a lot of insights during those sessions. It was not about attempts to "re-use" someone's design but more about questioning our past decisions and discussing future ones. That gives additional perspective on many things we have taken for granted.
Also, comparing our internal platform with market solutions has triggered revisiting the entire product vision. Ok, this is what those guys are providing - who are we compared with them? We are not competing with them, but the comparison can encourage the team. Something we did better (from our perspective), something we need to learn from them. But we can be proud of what we build, which has some potential to contend in the market.
Validate Architecture design
If I provided enough input with business, functional, and non-functional requirements, I would expect tech guys would design the right architecture without my interference. But now I am sure a PM needs to participate or at least validate an outcome of the architecture design process.
I am not talking about doing tech design instead of architects. I don't have expertise in tech design, but now I have enough general knowledge and courage to ask straightforward questions about every aspect of it. Ask questions and challenge them against the business needs that solution will cover.
Product vision clash
Product management is not only about producing your own vision but about adapting and nurturing others' vision as your own, from my perspective. PM's vision is not existing in a vacuum, as stakeholders ( especially C and V-level roles) are guiding and impacting it.
In Year One, I mentioned taking responsibility for a previous product vision and pushing it further. But at some point, you come up with your own vision, which may not match the management stakeholder's view. And here you whether agree and adopt that vision or continue pursuing your vision, but somewhere else.
Afterword
And again, I am sharing the negative mostly. It is not all bad. Positive stuff results in all other articles, posts, workshops I am doing, and the feedback I get. That keeps me going. Let's see what this year will bring.
Take care,
Ilya