Nubank is the largest fintech in Latin America with more than 20 million credit card customers and our core mission is to fight complexity to empower people. Credit Card was the first product built around billing cycles and along the way we had to couple financing products under the same infrastructure. Through this article we would like to cover one of the most challenging projects in Nubank: migrate the entire credit card architecture to a new credit card platform that unlocked the creation of more than 10 new credit products – ah, and in a heavily regulated environment. 

This migration was very strategic for the whole company and involved work from a great number of people from diverse areas: business, product, engineering, data, operations. We will talk about:

• Problem statement: customer, business and regulatory pain points
• Platform as a solution for the problems
• Building platform mindset inside the teams
• The mistakes and lessons learned on decision making process
• Working agreements and chartering
• Prioritization across multiple teams
• Execution tooling with examples of how we made it

Problem Statement

The project’s ultimate goal was to keep Nubank’s regulatory exposure to a minimum by providing and maintaining a stable, consistent (and eventually global) credit platform and allowing product teams to focus on the end user. We had four main pain points to solve:

1. Credit consistency and transparency for customers: at the beginning of Nubank, we had autonomous teams and services taking care of part of the customers’ lifecycle. Since Credit Card creation, we developed several modalities of credit such as revolving and financing plans, in which each one of them had its own business logic. We felt that it was important to have consistency and transparency on calculation logic across credit operations not only for credit card, but for the entire credit portfolio – “for the same input, guarantee same output”. This would help customers better understand charges on their bill and unlock future product opportunities.
2. Reduce our cost of funding and our third party dependencies: In 2018, Nubank received a license from the Central Bank to operate as a Financial Institution that allowed Nubank to issue credit operations and certificate of deposits (equivalent in Brazil) on its own. Doing so would enable us to reduce our costs by removing intermediate institutions from the credit operation. 
3. Increase in regulatory requirements: Central Bank requires several analytical reports regarding credit operations to monitor financial risks. Since we built the product on a billing cycle logic based on balances, we could not get the granularity required to report to the Central Bank.
4. High complexity to deliver similar products: every financing product shares a similar life cycle and when we thought about launching new financing products or even the same product in another country, we would need to create the same infrastructure and product rules for each one of them. This new credit platform allowed us to have a shared infrastructure for all credit card financing products decreasing the development time. Just to give you an example, we were able to offer financing options on Mexico using the same platform in a very short period of time by taking advantage of this platform.

Platform: a solution for our problems!

The best solution we found to solve all three pain points at once was to migrate the entire credit card architecture to a new credit platform and to operate correctly in-house.

A platform mindset means splitting the solution to a problem into a generic part which can be used by multiple products and a specific part which solves that particular product.

There were four different financing products (Voluntary, Mandatory Financing, Refinance and Agreements) with very different implementations and specific calculation rules, while billing and credit life cycle remained the same. We invested most of the time designing a new architecture with a clear and standard APIs definition for credit simulation and issuance in a way that we unblocked different products usage.

Decision-making Process

It is important to highlight that, although there was a lot of reverse engineering to keep the products working as similar as possible, in some cases, we also used the architectural change as an opportunity to bring relevant and positive impact in customer experience and business. 

Throughout the project we learned to build decision record documents to explain our rationale behind each approach we could take and to record the decision made, creating a proper environment to make those decisions. We kept four tenets in every decision:

• Time: the project should be released as soon as possible – We have many features to implement to get ready for the initial rollout launch phase, so we need to focus on the most important attributes and try to make it as simple as possible.
• Experience: A new solution cannot be worse than the current one in terms of experience. 
• Risk: The solution should be risk-aware, from a compliance and customer impact perspective – We should take measured risks and be aware of the impact on both business and customer sides.
• Scalability: The solution must be scalable. Although we want to deliver as soon as possible we need to take in mind the legacy we’re creating and be aware of leaving a better path that will enable future improvements.

Always take into account perspectives from different members and roles on the same challenge, including engineers, PMs and Business Analysts. Align together, make it clear the conflicts and trade-offs, and escalate as a team to get help from executives on decision making, rather than scaling to the management team with just one perspective separately. 

Prioritization and Execution

It was very challenging to change the architecture behind all credit operations and products and align the prioritization across more than 30 people (directly involved) distributed in 5 different teams. We describe the following methods used to get clarity and pace among the teams:

We relied on user story mapping as a tool to slice small deliverables to reduce risk and deliver value faster. For most of the products we dedicated a time to discuss the user journey in the legacy version and what would be the best user experience possible in the new one. Finally, we would break down those stories into small releases. 

Clear milestones were defined by having a clear delivery of value for Customer and Nubank as users on our story mapping.

It was also very important for us, as Product Managers, to deep dive into the execution in this project by joining and facilitating whiteboard sessions. There were some terrible sessions and also really great ones. We agreed that great whiteboard work around a specific problem you’re trying to solve has a clear objective, premises that everybody agrees and understands and a clear drawing. 

Since we had such a tight schedule and a lot of teams involved, we created a weekly walk-the-board meeting using:

• a reality check, an agile tool that helps us verify if the deliverables and the deadline were feasible to achieve.  It helped us by giving clarity and visibility about all the tasks, milestones, deadlines and dependencies across different teams; 
• Confidence check-in for each streamline by asking the team: “From 1 to 4 how confident you are to deliver the tasks for the next milestone?”. By doing so we were able to adapt our plans as soon as possible when necessary.

By the way, the board was very relevant to change plans in a timely manner

Even with a clear ultimate goal and definition of done, the prioritization was very challenging at the beginning due to new information discovered on a daily basis. One of the most important lessons learned was that instead of fighting against the new context gained, we were able to be more resilient and adaptable by being willing to change plans anticipated by the reality check tool and continue on the agile process as we received more and new infos. 

Great teams, great products

The team was composed of people from five different teams and we learned to commit in principle and some agreements, which included communication forums and ceremonies on teams, project and executive update levels. During the project, there were a lot of new people that came onboard and it was very important to not only keep them aligned on priorities but to make them feel comfortable by creating a safe space for them. 

Retrospectives, chartering sessions, demo meetings to show the progress made were allies on this project. And since we’re building products, we made a lot of mistakes but we kept celebrating learnings and reflecting about them as a team through post mortems.

We, Product Managers, cannot deliver anything without a great team. The main lesson here is to continuously invest in building a strong team. 

Key Takeaways:

1. Have a clear problem statement
2. Invest time in building a decision making process and its tenets
3. Discuss the architecture thinking about current use cases but mainly the potential solutions that it may unblock in the future
4. Use story mapping to share context and define small deliverables
5. Be involved in the whiteboard sessions and prioritize not only the product, but the teams

Authors: Lina Horiguchi and Jacqueline Asano
Reviewers: Lucas Cavalcanti