Skip to content

Product Manager: Year One

Cover

One year has passed since I was promoted to a Product Manager position: first six months as an Associate (a Junior grade), and then I stepped in as a fully-fledged Product Manager. And that was a drastic shift that made me revisit some aspects of my work and added a new dimension to my view on product development.

In this essay, I want to summarize my experience with the insights I collected throughout the year. Some of them might be obvious to a more experienced audience. But for me, some were revelations, and some were hugely underestimated initially. It is a good exercise to conduct such a personal retrospective, and others can benefit from that as well.

Lack of resources is permanent - live with that

During the meetings with senior management, some Product Managers from other teams always complained about needing more people to complete their goals. It is a big problem that cannot be resolved immediately. But at some point, that becomes irritating. Lacking human resources should not become a constant excuse for missing business objectives.

I was also among the complainers at first. Then I realized a better strategy to focus on what you can achieve with the current amount of people in the team. Some objectives require a lot of people involved to get the right things done at the right time. But some of the objectives also can be decomposed and addressed with a current team capacity. Also, a business need can be handled in many ways, not always with hundreds of dev hours or story points spent on new features. You need some space to think out of the box and have the trust of the senior stakeholders in you and your team to find the right solution within current constraints.

I asked myself, "What should we not do or stop doing to achieve something?" instead of "What should we do?". Do more with less. That is my motto right now. I know what I would do with more developers in my teams. But I have a strategy in case of decreasing the team's capacity even more.

"Lights-on" work is a real threat to product development

Support activities and tech debt can bite off a large piece of a team's capacity and defocus them from new product functionality. You can't avoid this, unfortunately. The best way to mitigate this is to forecast how much that might take in future iterations. But this is a challenging task. You can handle tech debt by splitting some fixed amount of dedicated efforts for each development sprint or having a full sprint once in a quartal. The support is much more challenging to handle, especially if you have legacy service with few people knowing how to work with it. And if you are an infrastructure team (that is my case). It is impossible to foresee the number of bugs, feature requests, and questions from other teams and customers. Each with the highest priority, of course. That can block the development of new features and break all the plans you committed before.

The only way I found is to become ruthless in filtering "urgent" support items to complete. No more Mr. Nice Guy. You must become a gateway that needs to be passed so a team will take a support item, not from the queue. I am that guy who will stand against your request, even if it is crucial until you prove it is a real priority. Of course, you can go upstairs and push it through via higher management, but I will fight till the end to protect my team's backlog.

Of course, I expected that pressure. But the real tension here is what surprised me.

Hell of constant replanning

Planning is a huge topic I would like to cover in separate essays. For now, I constantly revised a year's roadmap and quarter plans. There are dozens of reasons why that happens, but in the end, I get nothing but frustration.

Being without mentorship sucks

My quick promotion to a standalone Product Manager happened before my mentor left the organization I am working in. So I stepped into his role and found myself in a vacuum. There is no senior product manager to manage me, and next-level VP management is a bit away from my day-to-day activities. They could help me with my questions. I am not questioning their good attitude. They have a broader view, and diving into a low-level of details is complicated: either because of lacking knowledge in my domain or having a more technical than product-oriented background.

That does not mean I am alone and no one wants or can help me. The organization's product management process is well-defined but can't answer all the questions. Asking other PMs gives little as we are acting in a more isolated way and not aware of each other specifics.

Recently, Q&A sessions were introduced where I can fire my more-or-less stupid questions and get helpful responses from different audiences: POs, BAs, operational managers, etc. However, I would like a parental figure to sit down with me and say: "Hey, son, stop doing this stupid shit. Here is what I'd suggest…".

It may be for the best. In another year, I will let you know.

Afterword

Those are not all insights I have gotten during my first year in a Product Manager's shoes. And not all of them are as negative as I described above. It just appeared when I started writing this piece that the most pessimistic things appeared on the plate. I have gained much experience and still need additional time to analyze some things. I will be glad to share that with you here.

Take care,

Ilya

Baby Vectors by Vecteezy