Newbie guide to Product Management
Sharing few basic principles that a new entrant into product management should keep in mind. These are basic learnings that you will have after a few years of working experience in a consumer product.
Rule 1: You are not the customer
This is common mistake that we all have made at some point of time in our product management journey. While building the product we get so engrossed in it, we tend to forget for whom we are building the product. We start treating ourselves as the customer.
Example: I was building Ola auto, one of the problem statement was — how do we enable our customers to book an Ola auto when both are standing insight (without customers going on the app). One of the suggestion was by sharing the customer phone number with our driver partners. It seems natural, I would have no problem sharing especially when it is directly getting entered into a trusted device. But if you look at the customer who is taking the ride, a good percentage is women customers. When I interviewed them, many said, NO. She said I don’t trust auto drivers.
Rule 2: Problem statement, not the solution
As a newbie you will rarely get a clean slate, most of the time you will be given a product which is in place and you are asked to improve it. Generally as newbie you experience the product and then sees some shortcomings (or are told so). You get on and start solving it. A rude shock is given in the first presentation, where stakeholders will ask why this, what is the problem statement and this is when you realise that you have not done enough soul searching.
As a product manager your primary objective is to discover the problem statement/ pain points of the users. Once you have done that correctly, your 80% job is done.
Example: You are asked to improve the login/sign-up experience of your app. Internally you know that your OTP service sucks, there are too many login options like social, phone number, email id etc. Now you are assigned this task, you build a beautiful detailed product document with all creative solutions. You are happy and go for the presentation. You start with changes that you will bring in. But then someone interrupts and asks, Is the login broken, why are we trying to change it? (You are wondering, what the heck yesterday only the same person said these are issues!!)
Rule 3: Product management is not democratic
As a newbie, you will get a lot of advice, a lot of pointers and a lot of gyaan. They all will become your lighthouse when you are building the backlog. This is where we go wrong.As a product manager you own the product, it is your vision and you are responsible for it. So better you build your north star vision of the product. Listen to all advice and gyaan. But build what you think is right (obviously backed by data, VoCs and business goals)
Rule 4: Spend some time everyday with your customers
Only way to not fall in Rule 1 trap is to listen to your customers. Read app store comments, read any NPS feedback that you are collecting, read customer research papers, talk to customers directly (ask management if you can talk to them, many a time different organisations have different policies around this. Also customer data is mostly encrypted at most places)
Example: I was building Ola Guardian where we were proactively predicting unsafe situations. When I launched the MVP, the first few basic signals, my false-positive rate was close to 99%. My routine was to look into all the alarms raised and go through customer voices and situations. We identified many negative cases. By the time we rolled this out, false-positive rate has fallen to 95% (just to compare, police line SOS calls has 99% false positive)
Rule 5: Data is your lifeline, instrument well
Product management needs a lot of problem statement proving, measuring the product performance and analysing the improvements. All this cannot be done without data. Data is generated by instrumentation that you build. No instrumentation, no data. So when you write your specification document, make sure it has instrumentation mentioned. To do the instrumentation right, think of all the corner cases that you are wary off along the happy path. Corner cases are where you will find most of the issues. Also follow a proper naming convention. This will help you in the long run.