Why is buying software for private equity and venture capital such a pain?
For those of us that have had the misfortune of having to lead the process of buying PE and VC-related software…WE FEEL YOUR PAIN.
- “What if I get it wrong? Will I get fired?”
- “Are my co-workers judging me?”
- “Wait, I had no idea that there are workplace politics that touched this area…”
- “This should be somebody’s full-time job! It feels like some experience would go a long way in doing this!”
Unluckily, I’ve had the challenging task to navigate the ambiguous to-do of evaluating B2B software in a previous life. And I regularly interact with people that are going through this process, so, I’m here to tell you a few things that I now know, and which I wish I would have known, the first time I found myself on the other end of buying software for the private capital market.
- If you want the evaluation and the decision you make to go well in the long run, take your time. The goal of doing this “quickly” or “ASAP” is fraught with peril. Take the right amount of time. Think months/quarters, not days/weeks.
- Don’t expect the software to solve every problem or requirement you could possibly imagine.
- Be extremely clear about a handful of problems that you are setting out to solve by buying software. Understand why they are problems that need to be solved, why they are the most important problems to solve (vs some of the others you’ve decided are “less important”), what will happen if they go unsolved, and what the cost of doing nothing — or certain alternatives — will be.
- Engage various stakeholders that suffer from these problems. Similarly, avoid engaging too many of the stakeholders that are trying to solve every problem they can imagine, and — even worse — the ones that are imagining problems they don’t have simply because there is software out there somewhere that *may* be capable of solving those, too.
- Understand that a variety of stakeholders suffer from the same problems, but in different ways. A sales manager and VP of Investor Relations, for example, can both suffer from having disparate data sources and no source of truth. That said, for the sales manager, that pain point manifests in being able to provide leadership with reliable forecasts, while the pain point for the VP of IR suffers from not knowing where they stand with their LP relationships. Seems like that one pain point of disparate data could be solved with one solution, until you start taking these perspectives into consideration during a software demo. Some software has gorgeous demo forecasts but suffers from adoption because it is too difficult for sales reps to use. There is a chain of dependent dynamics inside of these problems. Do the best to understand the dynamics that you can, but don’t kill yourself trying to piece together every variable within this complicated equation.
- Form a committee to help the software-buying due diligence. Involve multiple internal stakeholders (and in some cases external ones too, ie LPs if appropriate) and be clear about the role(s) each will play. Be real about the personalities involved, your company’s culture, and the politics associated with each. Politics are everywhere and it’s okay; navigating them is manageable when they are out on the table. Here are some suggestions for things the committee should consider prior to embarking on this quest:
- What is the high-level process we’ll use to embark on this journey? Know that no matter the answer, this process is not linear; rough steps are good to frame, but just because you are in the process of getting vendor demos doesn’t mean you won’t go back to problem/requirement identification. The process diagram will look more like a toddler’s scribbling than it will a straight line. It’s normal and productive, but doing this upfront will help to scribble productively within the lines and will help avoid a messy process that is taken over by pushy software sales people.
- Who will be involved in each demo?
- Who will help to prioritize the problems we discover?
- Who will make decisions if the rest of the committee cannot?
- When does the committee think it is reasonable to have completed this full buying process? (Add a factor of 3-4x that answer to be more realistic and be thrilled with finishing ahead of schedule)
- Who should be involved with onboarding the new PE or VC software vendor when the decision is made?
- What is the definition of success for the buying committee and for the process overall?
- Know that the considerations for all of these questions will change as the buying process evolves. That is perfectly normal and okay; it is better to have considered them and to adapt than it is to not have considered them.
- RESEARCH. You’re already constantly doing this, so make it less paralyzing by at least considering what type of research, how much of it, and how it will be done. Focus on vendor reviews, and reputation, but mostly just research.
I’ll stop there; because there’s so much more to say, but that’s a lot to chew on. The good thing is that the conversation doesn’t have to end here. Watch our recent webinar with a panel of experts who have been through this process, and one whose job it is to help guide others through buying venture capital and private equity deal flow software.
———-
Jeff Williams, Chief Strategy Officer, Altvia – Jeff Williams started with Altvia in 2011, bringing with him deep technical understanding and industry experience as an Associate at a leading Fund-of-Funds, Greenspring Associates. Through his tenure, he has worked extensively internally leading various departments from product, development, and marketing and externally with clients to make the vision of Altvia come to life through the development and launch of products solving the issues facing GPs and LPs.Watch our recent webinar with a panel of experts who have been through
