Situation : There is a section on our screen where you could see the people to whom you have paid. In the transaction term we call it beneficiary. Now this is served from a system called Contact & Beneficiary Module. I am the lead product manager who manages this system. We work closely with the chat vertical at our company  (which is an independent system) because chat forms an important step in the payment journey. The senior folks from the chat team are also part of the leadership group here at our company. Moreover, my manager had left the company recently and the senior leadership at chat team was asked to get involved with our team as well Now the chat team was proposing that we should decommission the Contact & Beneficiary Module as that is duplication of work and system. Since they also listen to transaction stream they would be able to serve the UI using their API

Task : I knew that beneficiary module was responsible for much more things than just serving the UI with the list of people to whom you have paid. So I was not in favour of the proposal. I strongly felt that this was not the way ahead and with the kind of roadmap we have there were things that could not be accomplished if the system got decommissioned.

Action : I spoke to the SVP tech and discussed the proposal at length. We discussed the pros and cons and basis that I created a presentation on some of the unique offerings that this system provided with and decommissioning it could lead to serious risk wrt business continuity. We got into a meeting with the chat team and our CEO and tried to evaluate the proposal. I stressed on the fact that this system plays a very important role in shaping up the UX part of the payment journey and why replacing it with chat would seriously impact the UX. Moreover this system does a bunch of work which then becomes an input for the chat system to render their UI. The key point here was to highlight that even the chat system depends upon input from the beneficiary system in general and the two systems complement each other. I highlighted how this system is helping in improving our referrals and fifth month retention. I had put down metrics that reinforced the need for this system to stay I further highlighted the fact that there were other systems like passbook in place which also had the data and could potentially serve the use case with incremental work but we don’t do that. Rather there is a specific purpose for each of the systems. Moreover, a lot of sweat and blood had gone into creating the beneficiary system in the last 1-1.5 years and there was a team of people across product & engineering who were dedicatedly working on it. There was no point in putting them in a state of uncertainty that could also lead to other implications. And even if we were to do this stuff using a Chat system, it would take considerable investment in terms of development effort & time.

Result: Finally, we were able to get alignment on this from our CEO and we decided to continue using the beneficiary system. On the other hand, it was important to get features delivered quickly so that we could show incremental value being added to the overall experience. For this I spoke to the engineering manager and the developers and we identified key items to be delivered in the next 2 months. All in all this system has evolved further and helps in acquiring new users through referrals and creating lockin ins by driving higher transactions. Today this system has played a vital role in improving the total number of referrals, avg txn per user, fifth month retention which are at an all time high.