october 2018, november 2020 - august 2021
full time @ BondLink, a startup in Boston at the intersection of finance, civil, and government tech
The problem is twofold. Firstly, issuers don't really have the opportunity to look at their outstanding debt holistically, but other participants in the market can. It's not an equal distribution of information. Secondly, an enormous pain point is that issuers’ data is everywhere, therefore it's hard to find, hard to rectify discrepancies, and hard to trust.
Empowering issuers with a better understanding of their financial portfolio will drive more effective Investor relations because everything associated with their debt portfolio is accessible in one platform.
The only goal of debt paint is to corral all the data and put it in one neat place where they can see it all aggregated and know it’s accurate.
The municipal bond industry is convoluted, with antiquated processes and methods, resulting in inefficiency worth an estimated ~$3 billion in annual waste. This cost burden falls on the issuers, which in turn falls on the issuers' communities and constituencies via underfunded infrastructure and/or higher taxes for citizens.
An intuitive product suite with features and functionality that streamlines the process of muni bond issuance, and provides standalone value to the primary participants in that process.
Sell-side participants, primarily issuers and secondarily financial advisors.
Debt Database is a tool to give clarity into an issuer's outstanding debt profile. It shows the historical data of an issuer's bond sales. What the issuer uses the tool for is up to them--forecasting, analysis, issuance planning, etc.
Traditionally, issuers don't have access to all the historical data of their own outstanding debt. They have to piece things together from multiple sources, often causing conflicts. Equipping issuers with more information only helps them make better decisions for their citizens.
A financial advisor’s (FA) most important job is to help issuers structure issuances. There is no standardized way of analyzing an issuer's outstanding debt, causing colossal time sucks and inefficiencies.
It put us in a great position to be that source of truth for data. It also provides standalone value to other participants in the municipal bond market, leading to potential partnerships.
Debt Database was the first product I heard about coming to BondLink in 2018. At the time, we didn't have the necessary pieces in place on the engineering or business sides to make it happen. By 2020, we had the engineering resources and secured a partnership with Intercontinental Exchange® (ICE) that opened the door to all the data we needed to power the visualizations.
Designing Debt Database was a greenfield situation--a brand new product, not only to BondLink, but also for the industry.
Infrastructure wise, this product would live inside the Issuer Portal.
We had calls with multiple different industry participants: issuers, financial advisors, product managers at financial companies, and more. We learned a lot of valuable things. At this point, we called the tool "debt paint."
Some issuers called this process debt paint because they would color code their different issuances and lay them all out in some sort of way, as if you threw colors of paint at the wall. And it turns out, the process of finding and analyzing outstanding debt could end up being just as haphazard as throwing paint.
We learned that some issuers did it completely analog with post-it notes. They would get different color post-its for each separate issuance and spread them across a board in different structures. Now imagine if you found out that some of the information was incorrect, you would have to rewrite all those notes!
The anatomy of a bond issuance is complicated. Yes, the main player is the issuer, however, there are many players involved in the process from program or project inception to issuance day (and beyond). Not only is it complicated to the outside eye, but it’s even an arduous process to those internal stakeholders.
There are multiple platforms that have bits and pieces of data, but not quite the whole picture. On top of that, there are discrepancies among each data source. And on top of that, sometimes issuers engage in private debt issuances that aren’t logged into public databases. When there are inconsistencies or missing data in the tool, it renders the entire tool useless.
The only platform with accurate data is Intercontinental Exchange® (ICE), and we signed a partnership with them in 2020.
Again, there was no standardization, so issuers and FAs approached debt management in many different ways manually and/or with software programs.
Manual methods included whiteboards, paper, sticky notes (seriously) and spreadsheet programs like Excel, Sheets, or Access Database. The manual methods always produced an overview, or a snapshot of issuer debt on which to base future decisions. Financial advisors were the ones who put together this sort of summary of the issuer's outstanding debt. The summaries shared these qualities:
The following examples are from various governments' public files.
I did comparative analysis with some muni and non-muni programs that were similar. Familiarity and comfort is important to our users. It was important to understand the products in the industry to understand muni participants' expectations, so I know how to introduce modernity, where to maintain convention, and what to chuck completely.
After analyzing and synthesizing what we learned from talking to stakeholders and industry participants and looking at the industry products, we (product and design) came up with the prioritization of features.
As a user, I need to be able to...
As a user, I would like to be able to...
Figuring out how to structure the product was one of the most intensive parts of the whole project. We had many calls with our CEO, Colin McNaught, and our Director of Issuer Success, Tom Paolicelli, who were both prior issuers for different municipalities and states. They gave me the perfect metaphor, legos.
Thinking of each piece as a lego clicked for me. It helped me find the prime visualization: column charts. If each bond was a lego, we could stack them vertically and horizontally to show different things.
We looked back on our comparative analysis. The product with the most sensible and utilized structure was DBC Debt Manager. The way to look into debt was from a program/project > series > issuance.
Once we understood that flow, we had to see how that convention and standard made sense for us. We wanted the top level to be the overall debt outstanding. From there, we went through a few iterations to land on the right structure and information we wanted to give to our issuers.
Here is where we started the process of sketching and mocking up wireframes.
In the beginning, we experimented with showing all the outstanding debt for an issuer over time (x-axis), organized by series. The designs here were not at all pixel perfect, very rough and conceptual.
Iteration 0 includes all the designs that were a single page.
Issuers range from what we call tier 1 (e.g., State of California, ~4 bond series or issuances per year) to tier 5 (e.g., small town issuer who issues every 4 years). We had to make sure there was enough room for dozens and dozens of series. Also, big, pretty charts with ample white space, WCAG approved text size, and accompanying historical data were not so common among other products.
In this iteration, the legend cards acted as buttons to render the respective historical data below in the table.
It became clear that we were going to have to consider how to deal with multiple issuances for numerous reasons.
We also decided have the legend be static, without interactivity. Only the filters at the top of the page could dynamically render content. Whatever the chart was showing, then, so too would the bottom table. The chart showed an issuer's outstanding debt, and so would the table.
Restricting the product to just one permutation of legos would've created a missed opportunity. We spoke to more professionals in the industry who confirmed that multi-level analysis, drilling down from the top, was valuable.
At this stage, we renamed the previous view "series" and added "yearly" and "monthly" views. We also added the term "debt distribution" into the mix, which was unnecessary. The nomenclature would change in coming iterations.
Yearly view would show the distribution of debt over time year over year, each year being a single figure broken down into two legos: the principal and the interest.
Monthly view would take a single year and zoom into it. From that view, you could see the distribution of debt month by month, and which series were being paid during those months.
This view was the same as yearly, just with the added data points of series within each year. The treatment and functionality of the series view went through some exploration. In this iteration, the original state would be blank, provoking user control. The idea was to allow the user to choose which series to analyze. We learned this was not very helpful, at least in this treatment.
We went through some rounds of feedback and learned the bars on the yearly chart should be around the same size, just with different proportions. Issuers aim to have steady levels of debt year over year. If there is a colossal overspend or deficit, then someone made a big mistake during the budget creation.
We added the third data point, the background labeled "highest level debt service" to help show the issuer where they were at in terms of future debt. In the table, we added a column that gave the delta in dollars between the year figure and that data point.
When a user hovered over a bar, a tooltip with the number values would appear. At this point, we were still pre-engineering feedback, so we came up with an extended tooltip that would show more information in a progressive disclosure manner behind an expand link.
Our feedback rounds also showed us that almost all monthly views would have two months of activity, as most issuers pay bonds semi-annually in January and July.
The difference in view and structure meant a different details table, too. In the fashion of matching chart to table, the table would be structured around month of payment as well. In each cell, the bond being paid or payment toward a bond would be detailed.
Callable bonds are bonds that have a maturity date in the future, but have an option in the contract to be repaid in full (called) by the issuer early. The second table was meant to show any callable bonds upcoming. We later learned that the call frequency and time table was much more complex, and we would have to remove the table.
Because the main purpose of the product was to empower issuers by putting the information in their hands, we explored other views that were more "experimental" or unusual, such as a "monthly average" view, where the semi-annual payments were broken down equally in an accounting fashion. The feedback was wishy washy, some thought it could be helpful, while others vehemently opposed. Ultimately we decided against it, as there was no feedback that said it actually was helpful.
The series view was pretty secure in visual execution and organization, but not in functionality. We explored using a modal to choose which series to show.
After the first and second passes with feedback from different stakeholders, it was time to make the prototype. Our team uses Axure, but this project we tried out Figma. In the prototype, we nailed down the navigation and the data management part of the product to hit all the feature reqs. At this point, we had the ICE® API and could talk to their database with all issuer debt data.
This prototype was the last design gathering feedback before we started to build. We worked with engineering to get to implementation phase--front end helped us find alternatives where there were performance or logistic issues with the design, and back end whacked the weeds of the data to hook everything up.
We took 9 of our customers and enrolled them in the beta for user research and product testing. The sessions were run by our Director of Product and were less usability testing and more contextual inquiry. Because each issuer is unique and has unique needs, a set of tasks wouldn't work as well as a freeform session. The participants used the product as they normally would, giving feedback as they went. Our director took notes as they worked and gauged their satisfaction levels, finishing each session with a "magic lamp" question. If they could change, add, or get rid of anything, what would it be?
The sessions helped massively and laid the groundwork for the Discovery phase of Debt Database 2.0.
After the prototype, we finished the backend data management piece that complements/manages the debt profile visualizations. As of 2021, this is the structure. It lives as an independent product within our other product Issuer Portal.
We are currently in the Debt Database Post MVP 2.0 Define and Develop phases.
