It was eight months before we shipped any features that solved a real problem.
It feels like an advantage to start with deep domain knowledge when building fund administration software. The FundCore team knows more about fund accounting, investor reporting, portfolio tracking, and compliance workflows because we spent years doing it. That background guided everything in our original build, resulting in a platform with 89 features including support for multiple currencies, advanced waterfall modeling, and automated audit trail creation.
Then we started speaking with GPs at emerging funds. Only one of those 89 features actually mattered to them: the ability to close a quarter in days versus weeks without sinking hours into manual reconciliation.
That’s what building in public looks like: owning the fact that the first thing you built is wrong.
The Danger of the Assumption Trap: Building from Experience vs. Conversation
We built the first version of FundCore based on what fund administrators would want, given the systems that they had. We included multi-entity consolidation for funds with parallel vehicles, automated management fee calculations with complex tiering rules, and 14 performance metrics, IRR, MOIC, DPI, TVPI, RVPI, calculated by fund, vintage and portfolio company.
Those weren’t guesses. Those were problems that we and others had struggled with in the fund administration context over the years. The one thing we assumed was true: emerging fund GPs had the same problems we were trying to solve that we had faced working for funds at other firms. We assumed wrong.
Our team spoke with 27 GPs from emerging fund managers with between $75M and $150M of assets under management during the first three months after we launched our platform. By the eighth conversation, the pattern became clear. The GPs at emerging funds don’t need more granular, sophisticated performance attribution or more powerful multi-currency consolidation. They want their time back.
One GP running a $95M buyout fund put it plainly: “I spend four days just matching the data between my accounting system, my portfolio tracker and my investor portal. Then I spend another three days putting together the reports I send to LPs and distribution notices for the cash to get to investors. By the time I get the quarter closed out, I’ve given back my entire work week for nothing other than I could have spent on finding the next deal. I don’t want more options, I want those seven days back.”
We heard that exact complaint, or a variation of it, from 23 of the 27. A week or more, up to 12, of the GPs’ time each quarter was dedicated to manually reconciling data and creating reports. Not value-generating activities like strategic planning or portfolio management, but the act of moving data between systems and ensuring it aligned. FundCore could have solved that problem. We just didn't make that our main selling point because we were too busy showing off how complicated the features were rather than telling people how much time they were saving.
The Pivot: Moving Away from a Feature-Filled Fund Administration Platform Towards Closing Their Quarter in Three Days
This forced us to start from scratch on this one. Rather than talking about how we have a feature packed fund admin platform, we started talking about how we help close your quarter in three days instead of two weeks.
So this meant rethinking what we highlight, what we show, etc. Yes, we have multi-currency, but that’s not the first five minutes of a demo. Automated quarter-end workflows are.
But to support this, we also had to build some capabilities that we didn’t have in our original 89 features. Because what GPs wanted wasn’t more performance data. It was:
- One click NAV pack generation: one click to generate their NAV pack (financials, investor capital accounts, portfolio valuations, performance) in a nicely formatted PDF for them to send over to their LPs. No need to spend hours putting all this stuff together by hand.
- Automated reconciliation dashboards: see that your investor capital accounts actually sum to your fund NAV, and that your portfolio valuations match your GL balances, and that your cash matches up to your bank statements. Don’t let these issues pop up during quarter-end; flagging them immediately instead of having them crop up on day three of quarter-end is far better.
- Pre-filled capital call and distribution notices: have a capital call or distribution notice ready to go for any investor with their individual amounts wired instructions and due dates pre-filled in from their investor profile.
- Quarter-end checklists that actually get checked off: a quarter-end close workflow that walks users through what needs to be done at quarter-end and validates it. If there are any LPs without portal access to their investor statements, it won’t let users check “investor reporting complete.”
None of this stuff was that complicated to build from an engineering standpoint. The challenge was more in figuring out what GPs actually want (answer: their time back).
But then our team built a demo that showed the quarter-end close process, rather than the usual feature walkthrough. Now, when prospects join us for their demo they get to see their quarter-end from start to finish, from entry of valuations through accrual of fees and calculations of NAV, distributions and investor reporting, in 90 minutes. And they always react, “That’s what we spend a week doing manually.”
That is worth so much more than 89 highly sophisticated features nobody is asking for.
The Difference Between Features That Look Good in a Demo vs Features That GPs Actually Use
As a result, one of the challenges when building fund administration software is figuring out which features are most important to include and which are not. Some features might look great during a demo or even show off your knowledge and expertise, but if users never actually end up using them during a day-to-day or if they end up never asking you about them or even knowing to ask you, then what is the point?
For example, having sophisticated waterfall modeling with scenario testing sounds good during a demo. It shows that you know your stuff and are technically able to deliver on all types of complicated waterfall structures, but most GPs at funds under $100MM have rather straightforward waterfalls as outlined in the partnership agreement. They don’t require modeling out hypothetical scenarios. They need the standard waterfall computed correctly each quarter, with no intervention.
Real-time performance dashboards with customizable metrics impress during demos. They are slick, and they seem modern and data-rich. But GPs don’t check the performance of their funds on a daily basis. They check it quarterly during board meetings and when LPs ask about it. They need a static quarterly performance report that automatically generates at quarter-end. They do not need real-time dashboards that need manual updates to their data.
The most important features are often invisible. For instance, automated data validation that prevents an incorrect capital call from being sent. Automated audit trails that record each transaction with a date, time and person responsible for it. Investor portal data restrictions that ensure LPs only see their capital accounts data, but not that of the entire fund.
These features may not generate exciting demo moments, but they keep the GPs from losing days cleaning up after operational errors. We learned this the hard way. Our initial roadmap for FundCore was focused on those features that would differentiate us from competitors in side-by-side demos. We focused on advanced analytics. On customizable reporting templates. On a white label investor portal.
We have been in contact with 27 GPs over the last few months. This has caused a major shift toward invisible reliability for the roadmap, including a focus on data validation, automated enforcement of workflows and prevention of operational errors before they happen. These new features may not look as impressive in a demo, but they deliver more value in production.
What We Would Do Differently If We Started From Scratch
We could do the FundCore build again with our current knowledge in mind, which would completely change our feature prioritization.
- Start with quarter-end close, and not fund setup. The original build order began with the fund setup features—entity creation, partnership term setup, onboarding of investors and recording of portfolio companies. Yes, these are important features. But they are not built every quarter of the fund’s life. We should have built out the quarterly close process first, so we were able to identify any workflow gaps earlier.
- Build for a team of two, not a dedicated account manager. Our initial feature set was focused on users who were dedicated fund account managers trained in both GAAP and ASC 820 valuation standards. Many emerging fund GPs are both the accountant and the portfolio manager and the person in charge of investor relations. Our platform should be built in a way that assumes the users need help as well as our tools.
- Optimize for time-to-value and not feature count. A GP evaluating fund administration solutions doesn’t want to know that the solution has 14 different performance metrics if they only ever use 3 of them. They want to know how much faster they will be able to close their next quarter. Every feature that doesn’t help in the quarter-end close should be deprioritized in the initial build.
- Develop for a mobile-first investor portal. The original investor portal we built was optimized for desktop. LPs check their capital accounts and download K-1s from their phones and tablets. Mobile experience should have been a primary design constraint from day one, and not an afterthought.
Instrument everything for usage analytics. The initial build had minimal analytics of which features were used versus which features existed. Building comprehensive usage tracking from the beginning would have shown the difference between what was built and what was used much earlier.
All of these lessons are obvious only in hindsight. But that’s the point of building in public.
The Ongoing Tension Between Completeness and Focus
There is a product development challenge that is particularly acute in fund administration software: the feature surface area is very large, but the core workflow is very narrow.
The feature surface area for a complete fund administration platform is quite large. Every fund administration platform has to handle capital calls, distributions, investments, expense management, fee calculations, portfolio valuations, investor reporting, document management, bank reconciliation, audit readiness, tax reporting, compliance tracking, and LP communications. For each of these, there are dozens of workflows and corner cases.
But the core workflow for most emerging fund GPs is actually very simple: make capital calls, keep track of portfolio company performance, close quarters, and communicate with LPs. All the other workflows happen, but less frequently.
This creates a product development tension. If you build for the feature surface area, you risk building a platform so complex that it buries the core workflow in features that most GPs will never use. But if you build only for the core workflow, you risk building a platform that works really well 80% of the time, but fails in 20% of situations.
The FundCore solution to this problem is to build for complete infrastructure with focused user interfaces. FundCore can handle sophisticated structures like multi-entity structures, parallel vehicles, and offshore feeder funds. But the default user interface is for a single fund entity with basic economics. FundCore is for the GPs who need that complexity. But they don’t have to interact with it if they don’t need it.
In product development, this is called progressive disclosure. You build for the core use case, but the complex functionality is there when you need it.
Is this solution perfect? Of course not. But imperfect and useful is better than perfect and unusable.
Frequently Asked Questions
How do you decide which features to build when industry needs vary so widely?
We prioritize features by talking with GPs directly about their time and needs, and not based on our own assumptions about what fund administrators need to do. We speak with target users every month. We also track how often users interact with various feature and capabilities. We prioritize features that save users time on frequent tasks and deprioritize features that aren’t used. What percent of planned features ever see the light of day?
According to usage data, roughly 35-40% of the features we delivered during the first eight months of our product life are consistently utilized by over 50% of our daily active users (DAU). Another 30% of features are leveraged, albeit less consistently, by smaller subsets of users who have a more complex need. The last 30% of features are almost never touched at all, and maybe never should have been built.
We found this to be typical with B2B software in general, but it was much worse for Fund administration software, which tends to have many users with a wide array of diverse needs depending on the fund’s size, strategy, LP base and so on.
How long does it take a GP to get value after they get on-boarded?
It varies based on how clean the data is, and the historical record of funds they are migrating on-board to the platform. Generally speaking, if a new GP comes in with clean data and wants to run simple processes, they can be set up and realize benefit within a couple of weeks or 2 to 3. For a GP to come in with complex legacy data and systems with many historical data points, it could easily take between 6 to 8 weeks of effort to migrate the data, and validate that the workflows are all set-up correctly.
Realistically though, a GP will really start to see the value at the first quarter-end close after they are onboarded on a new platform, as GPs will be forced to start running quarter close processes with new workflows instead of the legacy processes they have become used to running manually before.
Do GPs really prefer a simple tool, or a fancy one?
GPs in the earliest stages of their venture capital journey always tell me they want something really simple that just works, rather than something fancy that can do everything. However, they also want to be reassured that if there is some edge-case or complex workflow they need to use for the first time, the product will still be able to handle it.
The sweet spot is something that just does all the core work well, but if something comes up the product team and their workflows can easily figure it out. GPs want a simple tool, but they don’t want to learn something super complex or discover that the tool has a huge limitation at a time sensitive moment like quarter-end close or during an audit.
What do customers’ voices mean for the roadmap?
Our customers, the GPs, do a lot of product planning for us, but not necessarily the type of roadmap planning we typically do with product teams, as they are not product teams.
GPs tend to be experts at running a fund, not experts at designing an efficient platform with the best workflows. So they know what they want the outcome to be, but not the technical solution for how to achieve that. Therefore, we tend to listen for a commonality when we are speaking with many GPs in a given period, and if we hear the same workflow frustrations or desires from at least 8 GPs, we take that as a very strong signal to prioritize a new feature or workflow improvement to our roadmap. If only one person tells us they really need a particular capability, we will evaluate what that looks like to add it in. Sometimes it just won’t be the right fit with the rest of the platform.
Building an efficient and elegant fund-administration software company is not an easy task as a product team, as one always feels the tension between building a sophisticated feature that adds value, and something that adds complexity. Building the feature-rich product, or one that is simple but only does one thing, is not ideal, and finding the balance is a difficult process. But what is key is to talk to users, and learn from them constantly. Even the best product team members will not guess the perfect product, it requires talking to a user, learning from them, changing direction, and getting feedback again until it makes a lot of sense. Learn more about how we approach the product side of the FundCore fund operations software here.