paint-brush
1 year of Product Management laterby@tanuj_13762
2,163 reads
2,163 reads

1 year of Product Management later

by Tanuj BathlaAugust 11th, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

A little over a year ago I started my role as a <a href="https://hackernoon.com/tagged/product-manager" target="_blank">Product Manager</a> at a Fintech Startup, and to be honest I feel like this role has changed me as a person. Coming from a background in Operations and Finance, I had to learn a lot about things that I previously took for granted. I had to change both my mindset and my approach to problem solving. I also had to lose my ego, I’ll explain why. But mostly, I had to read a lot of blogs on how this Product <a href="https://hackernoon.com/tagged/management" target="_blank">Management</a> thing really works. What I found was that there was a lot of great content available.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - 1 year of Product Management later
Tanuj Bathla HackerNoon profile picture

A little over a year ago I started my role as a Product Manager at a Fintech Startup, and to be honest I feel like this role has changed me as a person. Coming from a background in Operations and Finance, I had to learn a lot about things that I previously took for granted. I had to change both my mindset and my approach to problem solving. I also had to lose my ego, I’ll explain why. But mostly, I had to read a lot of blogs on how this Product Management thing really works. What I found was that there was a lot of great content available.

So today, instead of talking about the ‘5 do’s and don’ts of being a good PM’ etc. I thought I’d share exactly what I observed and learned. Nothing more, nothing less. Fair warning, this not an article where I will talk about ‘looking at customer data’ or ‘tell you how to be a good manager ’ (I’m not that full of myself….yet).

  1. Don’t let the business team drive the Product Roadmap alone

https://gph.is/2w3jKcb

A roadmap that is proposed by a single individual or a few individuals will never work. This is because one person can never truly capture the realities of building a product. Not only can one individual’s opinion be biased towards a feature, but it could also be unrealistic. We found that the best way to build roadmaps is by getting everyone involved (designers, developers, marketing). Not only can we set more realistic expectations around product delivery, but by listening to the opinions of different stakeholders, we also build and plan for product releases in a manner that will benefit the long term growth of the company and not just get us a few quick wins.

2. Get rid of your bias

I cannot stress the importance of this point enough. If you’re a developer that’s moving to a PM role, you need to understand how the design team works, get into their mindset and understand where they come from. Try developing a deeper appreciation for the UX process and understand that making mockups is only one part of the job. The research that they conduct is another important aspect which feeds into building great products.

If you’ve come from a business background you really have your work cut out for you. Not only do you need to try and understand the UX process, but you also need to understand the technology that your platform is using. You’ll need to learn terms that you’ve probably never heard before, like design thinking or SCRUM (no, I’m not talking about rugby). But you also need to learn to say no. Sales and P&L are probably what you’re good at, but to build a great product, you need to learn to say no to several ad-hoc customer requests. Like my boss always says, ‘Don’t lose sight of the North Star, everything that we build should work towards it.’ So try avoiding distractions.

3. Don’t let that online article convince you that person ‘X’ has the best project management tools

When I first started working at FinFabrik, I was still sitting on my high horse (‘I had worked in Silicon Valley, so I thought I knew all the best tools’). I realised very quickly that my style of running operations and project management didn’t necessarily translate very well to this new company. Reasons

Different team size

Different work culture

Different work experience and industry background for my colleagues

Most importantly- different expectations

The point that I’m trying to drive home is that no two groups of people are ever the same. While you can carry forward a lot of your own principles and work ethic across companies, tools and software might not move across as seamlessly. Don’t trust every review and recommendation that you get, and don’t strive for absolute perfection with your project management tools. The opportunity cost of finding the right tool might be significantly higher than the benefit that it gives you.

4. Don’t get too comfortable with those giant headphones

Putting on a pair of giant headphones and ‘zoning out’ *ahem* might be an incredibly popular way of working, but as a Product Manager you shouldn’t get too comfortable with that setup. There is a reason why people say you need to have strong communication skills to be a good PM. You need to communicate a lot. No seriously, a lot. Sure, there will be long periods of time when you’re cleaning up your backlog, looking at feedback from customers or even creating a roadmap for your management to review. But this job also involves a great deal of the following

Internal team questioning commitments made to clients and pushing back on timelines

Clients pushing back on timelines recommended by your team and trying to bring forward delivery dates

Sales and marketing teams asking about updates on specific features so that they can sell better

So expect lots of looking over your shoulder to see whose available to talk, lots of google calendar scanning to see whose available to talk and lots of slack messaging to see whose available to talk.

To do this effectively you need to develop another critical skill, not being a nuisance or a distraction. REMEMBER, your job as a PM is to help identify a solution to the problem and then move out of the way.

5. Read everyday

https://gph.is/2vBSW3s

For new PM’s (and anyone that wants to grow as a professional) this is absolutely unavoidable. I’ve met very few people (0), who have been able to transition into this job without spending several hours researching. Either by taking courses on design thinking, reading books on agile methodologies or just the good old fashioned coffee chat to try and better understand the do’s and don’ts of this position. Before you do go out and enrich yourself I would give one piece of advice, like I said before, don’t try and copy paste everything you see or read as a solution for your company. Depending on the stage that your company is in, it’s possible that only a handful of those suggestions will be applicable to you.

6. Introspect before you retrospect

Reflect on the week that was, not just with your team but by yourself as well. I’m not saying that you shouldn’t grab a beer at 6pm on Friday and pat yourself on the back because of how hard you’ve worked all week, just take a little ‘me’ time before you do that.

I’m not pushing you to start a journal or anything (unless thats your thing), just take 15 minutes and follow the exact same steps that you would usually follow for your sprint retrospective. Ask yourself what you did well and how you could improve. 15 minutes in the week, I think we can give ourselves that much time.

In conclusion, I’d like to say that this has been one of the most enjoyable, yet challenging roles that I’ve ever taken up. Not only does this role involve a lot of thinking, but also puts you in the drivers seat to ensure timely execution of tasks. If you’ve got any fun stories or pointers for me, I’d love to hear them!