Overview:

Problem: Launch a loan servicing product in partnership with a bank lender.

Team: CFO, VP of Legal, VP of Engineering, Head of Risk, Senior Designer, three Back-end Engineers, one Front-end Engineer

Role: Product Manager

Timeline: 3 months

Understand the Problem:

Possible Finance is a mission-driven financial technology company that provides affordable, small-dollar, credit-building loans.

After launching a successful lending product in several states, Possible sought to reach additional customers through expanding to additional states. The company began a partnership with a federally chartered bank, which would act as a servicer in new states for loans provided through the Possible app. Working with a bank partner would subject the lending product to federal lending laws rather than state lending laws, allowing for faster launches. The partnership required overhauling the mobile app and integrating multiple back-end systems with the partner.

This case study describes the B2C product management work that I led for the partnership.

Kick-off:

My first goal was to understand internal work requirements and the needs of the bank partner. The bank provided a checklist and test script to validate before launch. Using this checklist and test script as a starting point, I held a kick-off meeting with team of engineers I was managing for the project. Based on a collaborative discussion, I created a product requirements document that compiled a detailed description of each internal and external requirement, open questions, and an estimated timeline. The work was grouped into 12 categories, outlined in the Product Requirements section below. I used the product brief as a living document, keeping it updated as questions were answered and I gained more resolution on the details of individual aspects of the project and timeline.

I held a second kick-off meeting with the internal team and the bank team to go over details, refine requirements, and align on the timeline. I kept the internal team updated daily using Slack and the product brief, and communicated with the partner team a few times per week using email. The internal team worked in two week sprints, with daily standup meetings in the morning and backlog refinement meetings as needed. I also led sprint planning meetings, sprint reviews, and sprint retrospectives every two weeks.

Assumptions:

Because this partnership product was similar to the existing loan product which had a strong product-market fit, many basic assumptions were already validated. The additional assumptions I sought to validate for this new launch are listed below:

1. Customers will repay their loans at similar (profitable) rates in the nine new states compared to the existing eight states.

2. Customers will trust a small-dollar lending product where the loan provider and the loan servicer are different entities.

3. The number of people on the waitlist for each state roughly corresponds to the size of the customer base for that state.

Product Requirements:

I held a meeting with our legal and risk teams to discuss the order of state launches. We decided to initially launch in nine states. In order to minimize regulatory risk, I was advised to follow the pricing model designated by each state's financial regulatory body, as well as provide notice that we would be doing business in their state. This meant that while some tasks, such as banking payment integration, would apply to all nine states, other tasks would be specific to each state and would require individual validation, such as loan agreement generation and interest calculations. Working with the internal squad, I divided the requirements into groups and wrote tickets for each task (there were about 100 tasks and subtasks for the project).

The high-level task groupings are below:

1. Privacy policy and legal text on website

2. iOS and Android store descriptions

3. Onboarding flow (mobile app, individual for each state)

4. Application flow (mobile app, individual for each state)

5. Loan acceptance/checkout flow (mobile app, individual for each state)

6. Dashboard (mobile app)

7. Loan interest calculations (back-end, individual for each state)

8. Data reporting (back-end)

9. Financial reporting (back-end)

10. Loan agreement documents (back-end, individual for each state)

11. Banking payment (ACH) integration (back-end)

12. Debit payment (interchange) integration (back-end)

Task Prioritization:

State priority:

To determine the order to which states to prioritize, I assigned states into groups of Simple, Medium, and Complicated based on the complexity of their interest pricing models. A pricing model for a Simple state would be a flat interest rate of 15% of principal, for example, while Complicated state would a more complex rate structure that changed depending on the amount of loan, for example: 15% of the first $100.00 of the loan, 14% of the second $100.00, 13% percent of the third $100.00, 12% of the fourth $100.00, and 11% of the fifth $100.00.

The Simple states all had the same pricing structure (though the interest rates were different), so I decided that it made sense to focus on them in order of potential customer base, which I determined by the number of people on the waitlist for each state, pulled from data aggregated in an application called Amplitude. Next I decided to focus on the most popular medium complexity states, and finally on the Complicated state, Michigan, which had the most complex pricing model. 

The result was a ordered list of all nine states that accounted for the popularity and complexity of each state.

Task Prioritization:

To prioritize the tickets, I planned a series of checkpoints that would allow us to launch each state in the most efficient way. These checkpoints were informed by a bottleneck on back-end resources and ambiguous wait times for launch approval from state-level regulators. I used Lean principles for these goals, doing work only as it became necessary.

1. Internally launch and validate states in order of priority so they are ready for public launch when I receive legal approval

   1. Validate mobile app flows, payment and disbursement transactions, and document creation

2. Update legal text, privacy policies, and app store descriptions

3. Publicly launch each state when as each is approved

4. Deploy reporting architecture as needed

I determined that it would be most effective to complete payment infrastructure first, which required setting up new interchange accounts under the bank's name, creating infrastructure to transact with those accounts, and integrating directly with the bank's ACH infrastructure via their SFTP server. Once transaction infrastructure was built, we would work on the states in order of launch priority. 

Leading up to the launch of the first state, we would update the website and app store descriptions, and manually generate reports for the bank based on their requirements, only building automated reporting infrastructure as volume increased and more complex reports became necessary. Additionally, each state was built behind a feature flag so that it could be released independently (or rolledback, if necessary).

Scrum Framework and Sprints:

When the bank partnership began, the engineer and product teams were using a kanban framework. After building consensus, I led the transition to Scrum so that we could complete projects with more agility, accountability, and efficiency.

After the transition, work was completed in two week sprints using a modified Scrum framework. I acted as product manager and product owner, conducted backlog refinement (or 'grooming'), led daily standups, and held sprint planning and sprint review meetings every two weeks.

Rollout Plan:

I held a series of discussions with the finance, data science, and engineering teams to form a rollout plan. I presented an initial plan, took feedback, and finally built consensus around the following final plan that would get each state to a position where it could be handed to the data science team for them to build a risk model. The plan was divided into five phases:

Results and Retrospective:

There were very few hang-ups over the course of the project and we ended up being prepared to launch in multiple states even before we had a response from state regulators. As the regulators approved each new state, we followed phases 1-3 of the rollout plan, and eventually moved to phase 4 once about 2/3 of the states were approved for launch.

In the first quarter after launching, the new states accounted for roughly 8% of total company revenue, a number that continued to increase as the data team refined the risk models and advertising spend was increased to bring in more customers.

The model I developed for launching these partnership states was formalized and has since been used to launch additional partnership states. Overall, the launch was successful and I am proud of the project and my contribution to the goals of the company.

Case study links: