During my summer internship at LendUp, I worked on the LendUp Card, a credit card that works for anyone. My main project throughout my internship was called “Transaction Synthesis,” and the goal was to provide more useful information about our users’ credit card transactions. Since I expressed an interest in product management (in addition to software engineering, my official internship role), my PM let me handle the entire project from the problem to designing and implementing the solution. This was the project that got my feet wet in the beautiful waters of product management, and I thank LendUp for helping me realize that product is my passion.
LendUp Card Services processes thousands of credit card transactions daily, and we had a few million transactions at the time. My task was to look at the current heap of data and try to extract as much useful information and insights as I could that would benefit users. FIS, the financial backend that actually processed the transactions, provided us with fairly minimal data about merchants; we only had the merchant name, city, and state. Sometimes this data would be unclear, so users could barely recognize the transaction or merchant, resulting in problems concerning fraudulent and unknown transactions. Clearly, this was somewhere we could provide a better, more transparent experience for our users, most of whom weren’t experts in credit. At the same time, there was a business need as we could more effectively analyze how our users were using our product, answering questions like where our users spend the most money.
I started out by evaluating what options we had, including some third-party turnkey solutions (like Yodlee and MX) and building out something in-house. Although the third-party APIs provided us with a solid amount of information given just our FIS data, there was a clear lack of quality (% coverage of all transactions was fairly low) combined with a high cost. After discussion with my PM, we elected to build an in-house solution.
The data I was given from FIS was a VISA merchant category code, name, city, and state. After planning out various schema changes and DB requirements, I wrote a speclet and developed a ticket roadmap in JIRA to organize the feature’s development process. Then, I developed a backend Python service which then populated a database table full of synthesized merchant data.
With tens of thousands of synthesized merchants and counting (I made a CRON job that would constantly process new transactions daily), this data could then be queried and made either business-facing or customer-facing.
After the development was nearly finalized, I wrote up some documentation to make sure future engineers would be able to effectively learn how the new feature worked.
Normally, querying our transaction table provided us with little to no insights about our customers’ transactions. The reason was that for transactions at merchants with multiple locations, different transactions showed as completely unique from each other. For example, every Walmart transaction would show its merchant name as “WALMART #” plus the unique store number, so our business analysts couldn’t (efficiently) see compare how many of our purchases were made at different retailers, for various SQL-related reasons. Many merchants also had unique order or user ID’s within each merchant name. After the new “synthesized transactions” table was reasonably populated, the same questions could be efficiently answered with rather simple queries. This allowed us to learn more about our users (including when, where, and how they make purchases) and with time, would eventually help us build a better (and secondarily, more profitable credit card product for them. I tried out some queries and got some cool insights about how our users were using their LendUp cards, which I could show to analysts as examples.
Apart from the business value of learning more about how our product was being used by actual users, my team and I also calculated the cost savings of this new tool/project. Since the alternative was either having zero additional information or paying a third party for it, we saw that the company would save about $1 million in just the next year — as the Card inevitably grows, this number would gradually increase year-over-year as well! It felt great to make a real impact by saving LendUp’s money in a meaningful way.
Presenting this information to our end users would also be useful, as they could benefit from seeing more details about their transactions. It definitely saves some time when it’s easier to immediately recognize a new purchase as a Netflix subscription or Uber ride, letting users focus less on the validity of their purchases and more on the rest of their life. Combining the power of our analysts and data scientists, we could eventually use our users’ purchase history to bring them insights on spending, which closely aligns with our mission of being a path towards better financial health. To this end, I worked with designers on our team to create mocks that would showcase a vision of a better way to view transactions in the LendUp Card mobile app.
Of course, I had to use one of my (and maybe even our users’) favorite restaurants as an example transaction.
As my first “PM” project, I had to figure out how to collaborate with engineers, designers, and analysts to solve a given problem. This was an eye-opening jack-of-all-trades experience that I really enjoyed, as it made me realize that I could combine my design, technical, and business skills in a meaningful way. I found that my passion lied not in software engineering, but in product design, development, and management. I realized that I loved the product process of finding out user needs and pain points, targeting which problems to solve, and rapidly growing a new product.