While I rarely held the title of Product Manager, I spent most of my career as one. During my stints as part of Business Solutions Group in Banks, my role usually was to design solutions for the concepts raised by product or operations teams. I still took it upon myself to launch various initiatives on my own, throughout my career. In simple words I was the solutions guy who didn’t wait for someone else to identify the problems to work on them. When I look back, these initiatives were the best part of my job, specially when I see some of them have become industry standards now. In this post I am trying to look back and analyse, what worked for me. Hopefully this will help people who are working on Product roles or aspire to become one.
Spend considerable time with your users: Spending as little time as possible at my desk was one of the key features of my work-day. I would rarely be sitting at my desk, instead I would go to operations floor and spend time with teams there. I would sit with them, talk to them, watch them work and observe their day. One obvious benefit of this was knowing my users and his work-day. What my users appreciates and what irritates them. This also helped me empathize with my users. When a user would complain about some problem in the system I would take it seriously instead of trivialize it because I would know how much it affected her/his daily routine.
Another benefit of this was that I became the go-to person for them whenever they faced any issues. They trusted me and saw me as their representative inside the IT team.
The result of this was that with time I managed to automate most of their operational activities. The reconciliation system that I worked on with the help of our direct banking operations team is being sold internationally by that vendor and controls almost 85% of Indian market.
Talk to customer service team and study customer complaints: I was not only responsible for building solutions for operations team but also direct banking channels products used by bank customers. The first thing I did after joining bank was to find out the customer service head and set-up with a meeting with his team. I made sure they knew me and found me approachable. With-in months I managed to train them enough to address most of the customer complaints at their level itself.
The biggest advantage I got out of this was, whenever they got a tricky customer complaint, I was usually getting copied on them. I would try to analyse the complaint and sometimes these complaints resulted into redesigning our CX or a new feature.
I got the idea of introducing most of the debit card related support functions via net-banking through this. Now every bank is doing it because it is the most obvious thing to do. Sometimes obvious things are hardest to get attention though.
Spend time with your vendor/development team: If I was spending 30% of my work-day at my desk, rest of the time I was distributing between my operations teams and vendors/tech team. I would sit with my vendor, ask them questions about how a particular setting affected the system behavior. Sometimes, if I got a chance, I would even sit with them analyzing the code. This last part usually would happen on holidays, when I would call them to office with promise of drinks and pizza afterwards.
This made me aware of what the systems we were using were capable of and the speed of introducing any change in the system. If you have worked for any large organization, you would know that introducing any change in core systems is frowned up on, specially for smaller impact items. Hence my objective used to be to get thing done with zero to minimum changes in the core systems/processes. Knowing the systems capabilities and good equation with vendor teams helped.
When we decided to launch mobile payments in partnership with mChek way back in 2006/07, I could do it with zero code changes in our core systems. By the way this solution was designed for basic phones and I used mobile device as a factor of authentication.
Testing: During my early days one of my key responsibilities was testing and I used to hate it. I used to think that have I graduated from IIT to do this but with time I understood how important it was for my learning and growth as a product person. Testing gave me the opportunity to be the user. It would help me play around with the system to explore the capabilities of the system. It also helped me plug any process changes that need to be introduced or any user training required before we launch the product/feature more efficiently.
Once I understood the benefits of it I started spending time on our test systems voluntarily also. When my bank decided to have separated dedicated team for testing and also worked on testing automation, I insisted on my team still participating in the testing process. There is no better way to learn and experience actual user interaction.
Once when I was in a senior position in my organization and didn’t have to do testing myself, I decided to test the launch of new version of mobile app. I downloaded the app, log-in was with mobile number and OTP. OTP was being automatically read by the app, so no input from user. Yet I got error “Invalid OTP”. I tried again and this time it went through. I tried to probe further and noticed that the OTP in first attempt was 0431. I understood, what the problem was. I got the development team to check the field classification and got it changed accordingly. This was such a trivial and accidental discovery, with potentially huge impact. It also made me realize that even after 12 years, testing can throw these kind of surprises.
Be friends with Security, Risk and Audit guys: This is specially important because I was building products for one the most highly regulated industry prone to frauds resulting into real financial losses. This made me take regulatory aspects into account while designing a solution. This also made me appreciate and keep in mind fraud trends and how to control them at design level itself.
Things like KYC-AML, PCI-DSS and their impact on your product/feature are very important in your journey. There were projects where we had to factor regulatory reporting as key aspect of design process.
When I was working on GreenPIN project, this came in very handy. Things like you can/should not send a PIN over SMS, a card PIN should always be inputted on an encrypted key pad, J & K customers could not receive SMS etc were important aspects.
Be curious and keep experimenting and analyzing: Always analyze the data that is available. Data will tell you how your customer is interacting with your product/feature. Which features are loved by your customers and which are ignored. Data can often show you very interesting positive/negative ways your product/feature is being used and you may have to take some actions accordingly.
Get access to that test system and keep experimenting. Play around with parameters and observe how it affects the behavior.
Once I was observing data of one of innovative products launched by our bank and I observed that few of our customers were accessing that feature everyday doing a part of the action and leave it halfway. On further investigation I realized that they were trying to game the system into gaining unfair rewards. I immediately initiated a change in the system to plug this gap.
I am sure many of you would have already known most of these and were doing these things. Some of you probably knew and didn’t do, for them I have thrown examples of how exactly these things have helped me in actually real life situations. Hopefully people who want to become product managers or become proactive solutions guys may find this useful.
Gaurav Tiwari's Blog 