Private Equity Portfolio Monitoring Tool
Created the future vision for a private equity portfolio monitoring tool
A leading financial technology company engaged Moment to create a future vision for its flagship product: a digital portfolio monitoring tool for private equity firms. Unlike general investors, who can publicly view the financial information of their investments, private equity firms have to collect financial information directly from the entities in which they invest. Our client’s product was meant to streamline that process by systematically analyzing financial information from private equity firms’ investments, and displaying all this information as a “single source of truth” for a firm’s analysts and executives.
Our client had three key business goals for the future of this product:
Increase adoption among executives and other key decision-makers at private equity firms (also known as “front-office users”)
Expand its client base by making the product adaptable to more client scenarios
Reduce costs by minimizing the time needed to configure the product for each client
I didn’t know much about private equity at the start of this project, so I had to quickly get up to speed on the inner workings of an extremely complex industry as well as the current state of our client’s product. My teammate and I began by interviewing 20 key stakeholders to learn about the current state of the product and the private equity industry in general. Those interviews helped us create a high-level user journey onto which we mapped out the product’s pain points. We then held an issue prioritization workshop with our client and arrived at a set of key problems we agreed needed to be solved.
1. Disorienting product architecture
The product’s architecture was based around functionality instead of content, so users were forced to navigate to the same investment vehicle in different sections of the site depending on the task they wanted to complete. For example, if users wanted to edit an investment, they would have to go to a different section than if they wanted to create a data visualization for an investment. Functionality-based product architecture meant that users couldn’t easily take multiple actions on an investment from a single screen, and they were often disoriented and unaware of their location in the product.
2. Limited investment categories
The product’s original structure only allowed for two categories of investment vehicles. However, private equity firms often have complex investment structures with more than two levels and multiple paths of ownership. This meant that clients often had to use complex workarounds to simulate their investment hierarchies.
These complex workarounds led to many other problems:
The implementation team had to create unique custom-built setups that cost them time and money
Clients often had to wait for many months until they could use the product
Front-office users couldn’t understand the manual workarounds, so they couldn’t access the information they needed by themselves
Product managers were stressed out and overworked because they had to routinely pull data for front-office users
Product managers often created data visualizations that were incorrect or broken because investment structures were confusingly labeled or set up
3. Static data visualizations
All of the product’s data visualization were static and hard-coded, so users couldn’t easily manipulate them if they wanted to see different views of the same data. Whenever an executive wanted to see a different visualization of an investment’s data, a product manager had to create an entirely new visualization from scratch. As a result, product managers were often frustrated and drained by the need for repetitive work.
Because we were still relative newcomers to the private equity world, we wanted to tap into our client’s deep knowledge of the private equity world and the users of their product. To do so, we led our client through directed sketching exercises based on a variety of user scenarios that we created. We left these sessions with a huge amount of sketches that we used to develop the initial direction for our first round of concepts.
In collaboration with our client’s new lead designer, we continued to iterate on low-fidelity, wireframe concepts that we tested with the client product team. Based on each round of testing results, we revised our designs and then re-tested with the client team again. After several rounds of testing and iterating, we arrived at a set of targeted solutions to the product’s core pain points.
1. Simplified product architecture
To simplify the product architecture, we reorganized the navigation around content instead of functionality by introducing filterable “Finder” pages for each investment category. “Finder” pages display grids of investments, their key financial metrics, and pre-set data visualizations. If users wanted to view a subset of investments, they could filter the “Finder” pages by data items (performance metrics) or attributes. To see more details about a given investment, users could then navigate deeper to an investment’s detail page. Or, for a wider look at the investments in a firm’s portfolio, users could filter the “Global Finder” page, which would show every investment in every category.
Reorganizing the information architecture around investment categories — instead of product functionality — makes the product much friendlier towards non-expert, front-office users, the key demographic our client wanted to reach.
2. More investment categories and improved grouping functionality
To break away from the product’s limited two-tier investment hierarchy, we proposed letting users create custom investment vehicles and assign them certain data items and attributes by default. Custom preset investment categories would make the process of creating new individual investments much faster, and would allow firms to more accurately represent the relationships between their investments.
More accurate investment categories also make it possible to group investments in smarter ways. We proposed letting users create groups of investments by saving a set of data and attribute filters on any “Finder” page. These dynamic groups would get automatically updated as platform managers create new investments that match the filter criteria. For more discrete control, users could also manually select a group of investments and save them as a group.
By introducing custom investment categories and dynamic grouping, we gave the product the flexibility it needed to accommodate more complex investment structures, scale with fewer problems, and minimize complex and potentially error-prone manual workarounds that frustrate product managers and shut out non-expert users.
3. Dynamic data visualizations
To allow for dynamic data visualizations, we proposed keeping platform managers in charge of creating data visualizations, but allowing any other user to populate and manipulate them through filtering. For example, a platform manager may decide that the “Finder” page for companies should display IRR and MOIC visualizations. If a user wanted to see either of those statistics for a subset of companies, they could use the data and attribute filters on the “Finder” page to narrow down the companies displayed, and the data visualizations below would reflect that filtered set of companies.
By letting platform managers pre-set data visualizations that non-expert users could easily manipulate, we aimed to reduce platform managers’ workloads, increase usage from executives and front-office employees, and keep important data management in the hands of power users.
In addition to the challenge of rethinking an entire product’s architecture, this project presented additional challenges that forced our team to think on our feet and strategically target our efforts.
For a project with a fairly large scope, we had a small team: just myself and another designer. Together, we had to create all designs, documentation, and communication artifacts, while working directly with our client.
Huge aspirations and limited time
With a timeline of only three months, and a desire to fundamentally rethink the platform, we had to strategically choose not only which problems we were going to solve, but how we were going to solve them.
In order to deliver a vision that made it easy for future client designers to build upon, we decided to focus on which actions could be launched from each area of the product, but not to design the actual flows themselves. This allowed us to specify all the functionality this system could provide with the caveat that everything should be tested and reprioritized as our client’s design team built upon our foundation.
Limited access to users
Our client’s short timeline and few recruiting resources also meant that we had limited access to the product’s end users, and little time to gather valuable user insights to inform our designs.
So in order to obtain the insights we would normally get from users, we turned to client proxies to validate our concepts, testing with members of the Sales and Implementation teams who worked as closely with the product as many of the end users did. This let us quickly validate our concepts and iterate on our initial solutions.
Creating an infinitely flexible system
The biggest challenge of this project was designing a system that could do anything for anyone. Each private equity client uses vastly different investment structures, each of which our product had to accommodate.
To create a system that was customizable, but still had enough standardization to support complex investment hierarchies, we had to think about how customization would work on multiple levels – from product, to client, to individual.