Turning a feature request into a flexible backend.
2024 · Fannie Mae · 4 Months · Lead Associate - UX Designer
One-minute recap
Listen while you scroll · 1:02
Overview
Doing just enough discovery to realize that there's opportunity to set up future success while getting value now.
01
02
03
04
05
Every project at Fannie Mae needs to do a bit more than the original request. Fannie Mae suffered from a vicious cycle of churn and tech debt, and a culture that adapted around it instead of tackling it. So each project since I joined is an attempt to bring more value per project, but also jar loose the rigid culture throughout the teams.
BUBD is a mechanism to adjust pricing of loans very minutely to entice banks to transfer the loans to Fannie Mae. One of the revenue steams is to package these loans into more attractive pools of loans that are resold to the broader market.
The issue that was brought to the Product side is that the internal business people could only price these loans very broadly. Only the general categories like 30-year or 15-year loans. If one loan was from New York versus Texas, there was no way to tell the system to differentiate those two.
In the past, the team would have done the most minimal effort to get that feature into the system. Never assessing if there was a bigger opportunity, or if the company would even see any return on investing into a feature.
Forcing our teams to connect solutions back to users' pain points and wants.So first my role was to stop this cycle and introduce more robust methods to vet these requests. We embarked on discovery that cut across all the disciplines: product, design, and technology. We used a combination of journey mapping (also called "event storming" at Fannie Mae) and user interviews to identify more root issues and where it fit into the overall business processes.
From there, we assessed the technology we had at hand. You can imagine there were hurdles there. The main heart of the pricing platform is a monolithic mess of tech debt, but also owned by another team. Any attempt to change that monolith would often result in timelines that stretched into months if not years.
One of the final screens for the product.So why? Let's explore all the different why's.
What's exciting about these APIs is that they can be used generically by any other product or team. One being a "product identification" system, now any business unit can build their catalog of products via this system and send it to any niche pricing system.
This also finally allowed the team to sunset existing third-party software that also took months to update.
Ultimately, it was also faster to develop with more modern tech stack that wasn't hindered by legacy decisions.
For Fannie Mae, this was faster. Often even the front-end UI at Fannie Mae has tech debt. Because the core of the features are now API calls, we could select the easiest temporary home for admin users to use and configure.
If tomorrow Fannie Mae suddenly trashes its tech stack, the team can quickly stand-up the functionality in any front end environment.
Documenting all the possible ways of executing the plan by working with engineers to really understand how all the systems connect together.In short, by bringing some fundamental operating models to Fannie Mae, we are slowly breaking old cultural norms and still bring value to the business while actually going faster. The original request was estimated to save Fannie Mae $20 million per year with just one loan dimension.
With the new system, Fannie Mae can price to any of the hundreds of dimensions of a loan. The modularity of the API features also means whatever comes in the future, the business team can easily add and modify anything without needing an engineering team.
Even better, this capability didn't incur more tech or product debt. It actually converts a significant part of the process chain into a more modular and flexible tech stack. So it simultaneously unlocks tens of millions of dollars in revenue while reducing millions of recurring backend costs.
