5.5 things I’ve learned 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 Product Manager, 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

0.5 You will make mistakes