5.5 things I’ve learnt as a Product Manager
Nine months is not a long time to be Product Manager. It’s long enough to have a baby, long enough to grow a couple of tender house plants, or even get a Masters degree — but somehow not quite long enough to master the length and breadth of a Product Manager’s scope of work.
It’s been quite a rollercoaster, but here are 5.5 key things I’ve learned so far.
1. Nobody knows what you do.
To most people, you’re the person who makes notes and checks the Trello board and err… wait, what else do you do?
You may coordinate teams, plan sprints, watch metrics and a million other things. But if it were up to “perceived-work-done” alone, you’d barely deserve a salary.
It’s okay, nobody owes you anything. As a PM, your motivation and appreciation will have to, alas, be internal.
You learn that as long as the right feature gets pushed and the product is moving in the direction of growth, you’re good to go. You’re the invisible lubricant that keeps the engine running. Every i dotted, every t crossed. You’re the product ninja. Silently, efficiently making your way through the work and the charts (oh, the endless stream of charts).
2. Every conflict/error made/disaster probably started as a tiny seed of miscommunication.
Every instance of conflict represents an opportunity to communicate that was missed earlier on. Maybe different teams are competing to get their respective features pushed ahead or a new deadline appeared that was not discussed in the product roadmap.
Whatever it is, it just means you didn’t manage to get everyone on the same page. That’s definitely on you, but it’s also on your team. You must assist your team in fostering relationships where people speak frankly, but we’re all adults here, so it’s also up to the team to take part in those relationships.
3. Do your best to get out of the way.
It can be challenging to stop yourself from becoming a bottleneck for communication while making sure everyone is on the same page. How do you not become the blocker while still trying to filter/manage the torrents of information going to each team?
I don’t really have an answer for this, and I feel that your response will always change based on the situation; but basically it feels like trial and error. This is a skill that I’m definitely still taking some time to fine-tune.
4. Processes work but only if you keep things fluid.
Processes. Some people are all for it, some people are all against it. There are so many schools of thought you might as well give up. But don’t. Because for the person who doesn’t give up, you will find that there is a nice niche somewhere in the middle.
What I’ve found is that a general structure really allows the team to work in-and-around the core skeleton of processes — this enables freedom. Coupled with clear goals, the team has a direction to head in; and then how they want to get there is up to team consensus.
On the other hand, once you are dogmatic about your processes, you become a slave to them. You give up agility and room for creative problem solving. In short, it means you lose.
5. There are no shortcuts in development, design and product building.
Nope.
Your client will say:
“Give me this silver-bullet feature ASAP. We need it now. The business justification compels us to do so. We’ll just do it on the fly, we just need to go!”
Yes, many things can be done on the fly. But building a useful and worthwhile feature requires at the very least a little planning and alignment. Whatever time you save in not planning at all, you are bound to burn later in fixing and troubleshooting.
Realistically, we rarely need anything NOW-now (unless your site has crashed, or if it’s a super easy fix).
Because what can be delivered right-this-instant-we-need-to-deploy-as-soon-as-you-finish-reading-this-sentence will be nothing short of useless.
What it really means is, you will have not only built a poorly thought-out feature that doesn’t quite fulfil it’s intended goals, but you will have also burned up the effort of your team, as well as the time and money spent to do it.
0.5 You will make mistakes.
Because the nature of startup is to learn by doing.
Some days you’ll be killing it:
Other days… not so much:
But it’s all good, because it just means that everyday you learn a little bit more about being a Product Manager.
So, these are my learnings so far.
If you liked this article, send me a ❤.
Thanks for reading! 🙋
— —
This article has also been published at Tech in Asia: https://www.techinasia.com/talk/things-ive-learned-product-manager
