In my last post reflecting on the year that went by, I shared that I got a new role of Data Product Manager in Citi. Well, it’s almost 4 months for me in this role and I thought of writing another post reflecting on my learnings and experience of first 90 days.
So I thought of breaking down this post and share 7 initial impressions, in the form of learnings. A point to note is that these are based on completely personal experience, subjective opinions derived from being in a Product Management role in a Banking & Financial Services company. Hence, these impressions and learnings that I accrued from my role could vary! So now let’s get into it the meat of the substance.
Execution is the key skill of a product manager!
When I stepped into the product management role, I was given the responsibility to execute the projects (which were already mid-way) by previous Product Manager in my role. While I was gathering all the contextual knowledge and executing the tasks, I was growing quite restless to start working on something new! Any new feature or a capability would have satiated me. But that didn’t happen.
In hindsight, it was kinda good. I wouldn’t have learned a key skill of execution (am still learning). Frankly speaking, if my manager would have asked me to come up with a new feature or a capability right when I had joined, I might have failed. Because you need a lot of time to understand the processes, the company’s ecosystem, your stakeholders, the pain-points. So patience and learning the art of execution is the key! You get to understand the nuts and bolts of the ecosystem, how to manage the expectations of the stakeholders, what’s on priority and what’s not, etc.
So for me personally, execution means putting one’s head down and focus on getting shit done in the first 3 months (atleast)! Dream about launching your own feature later, when you understand the 3 Ps: Product, People and Processes.
Remove roadblocks, and help move people
The execution point above is a great segway into the topic of removing roadblocks, and mobilizing teams to work on your project – something that I learnt on the very first day in my product management role.
One of my responsibilities is to be a bridge between a specific data team (responsible for building and maintaining a clean, consistent data pipeline) and several other downstream – upstream teams. As a bridge, I help in highlighting any existing issues, tracking the fix, deliverables and removing all possible roadblocks that all other teams might face – preemptively!
Some of my other projects require a close collaboration with engineering, sales, digital marketing, tracking & measurement teams, etc. The goal is common – to ship a feature or a capability. However, working with so many teams, requires a lot more than the skill of managing people. As a Product Manager, I don’t directly manage, nobody reports to me (yet), and still I have to influence without authority! That means helping, and enabling teams to work towards your goal, a common goal. This is a skill that I got to learn from day 1 and will continue to learn forever.
Projects, estimations and forecasts
Let me share a fact, that I learnt the hard way. As a Product Manager, my feature proposal will only be picked up if it shows an increase in company’s top-line, and if the cost of building it is lower than the revenue it can bring in. *This might not be true for every company, though!
Right after a few weeks into my role, when the call for proposals came, I had to start building a hypothesis for my feature, based on which I showed revenue projections and forecasts. It was a pretty interesting task, because it’s an open ground. It’s all upto me, what hypothesis I frame and what estimations I take to build a revenue forecast. If I bloat my numbers too much, nobody would digest and my proposal would be shelved or put in backlog. If I underestimate, some other Product Manager’s feature which shows better revenue forecast would be picked up. I will soon write another blog discussing my strategy and revenue forecasts.
Even if the proposal is pretty good, there are several variables like company priorities, leadership goals and vision, available funds (or the lack of), etc., which could determine whether the proposal gets picked up or not.
I am sure I will become a much better salesman, when I master the art of getting my feature picked up!
*BTW: I submitted a couple of feature proposals with solid projections, but they weren’t picked up. I learnt that I need to bring several teams onboard and get their buy-in before pitching to the leadership. Revenue and cost of development matters only so much, after all! Will try in the next round and will keep you folks posted!
Networking
All my learnings above are impacted by a simple (yet extremely difficult) technique of having a good network in the company.
Whether it’s executing your projects, helping and enabling teams, or getting buy-ins of key folks – everything requires you to have a good network within the company.
As a Product Manager, you might work with completely diverse teams. I learnt that it helps to be proactive, even though I felt awkward (several times) to ask for a meeting in-person. For me, a cup of coffee and a good chat with a person whom I had only met in calls (that too audio only) changed things completely in subsequent calls. The person was way more receptive and helpful, and got me the resources I requested.
Independent decision making
I can’t recall how many times I have been put in spot by my engineering teams to take a decision on the way ahead or on deciding an approach among multiple options (each with its own pros & cons).
In my previous role, I could go to my manager to lead any difficult conversation or guidance regarding a particular decision. Now, things are different! My manager is there to enable me, help me build contacts, or help me give an exposure in spotting opportunities. But now I am accountable and responsible for any & every decision. That’s a lot of responsibility, especially if your features impact top-line revenue!
How much ever scary it looks, the power to take independent decisions is a great enabler as well. Even if the decision doesn’t turn out to be the way as I intended it to be, as long as I can justify using a rational process of thinking and making decisions, it’s okay!
Communication
One of the most important responsibility of a Product Manager is to communicate. As a Product Manager, I need to communicate with my team, stakeholders, and leadership. The style of communication should be over, often and crystal clear!
It never harms to over communicate, do it more often and most importantly, being crystal clear removes any possibility of ambiguity which can cause a lot of harm potentially.
Being organized, structured, and prepared
This is pretty much a very generic, yet an important learning for me as I go forward in the journey of Product Management.
I have learnt (and still learning) that the more I am organized, structured, and prepared, the less overwhelmed I would be. There are multiple situations in a day, when I could be asked to pull out a strategy deck, have a call with the stakeholder or just explain an intricate detail of a feature to a team member. When such situation arises at any point in a day, it really helps to be organized, structured and prepared.
If you have read all the way until here, thank you! I am assuming that you could resonate with my learning as well. I am definitely in a long uphill journey of learning the art of Product Management. So if you have more tips and guru mantra, please do share with me.
Do check out the other posts that I have written related to software engineering and data science. Please consider subscribing to my blog and feel absolutely free to reach out. I am also mentoring in the areas of Data Science, Career and Life in Singapore. You can book an appointment to talk to me.
