Do this before you buy new software for your finance team
This article offers up five common software purchasing mistakes and a framework that you can use for evaluating software for your team. Whether you’re a veteran buyer that knows all of the solutions out there or new to the category, trying to navigate a crowded market, these insights will be useful the next time you go shopping.
Two approaches to choosing software
We recently caught up with Gusto’s Sean Flynn and Robinhood’s Nadia Asoyan, veteran finance leaders who have both scaled financial operations from zero to millions in revenue. Both advocate truly understanding the pain you’re trying to solve before kicking off the software vendor search.
Sean’s advice on building out your software stack:
“Sit in your problem for six months [before you start looking]. It’s not super comfortable but it gets you to a place where you can understand everything vendors do.”
Of course, sometimes you don’t have the luxury to sit on a problem and need to rely on experience instead. In Nadia’s case, she came from Square and joined Robinhood right as they were about to start a period of breathtaking growth. She was able to use her prior experience from Square to set processes up for scale.
“My choice for an accounting system at Robinhood was very unusual,” Nadia says. “We had a team of two people and we were using Oracle Cloud. But it made sense as a scalable solution, long-term."
"Robinhood was planning to go international, integrate with a lot of banks, and deal with big transactional volumes, so I knew it was a great solution to have.”
You can make mistakes without a middle ground
Starting with solutions means you know exactly what you’re getting before you dive into company pain-points. And you avoid making mistakes like these.
Mistakes that you can make with a pain-first approach
Mistake #1: The perfect solution that you’re looking for doesn’t actually exist (probably)
The pain-first approach is like drawing out a blueprint for your dream house before you go hunting for one on the market. It’s a lot of work that never pays off because you’re never going to find software that meets your exact expectations.
There are advantages to surveying the market first to see what’s available and understand features that you might want in your solution.
Mistake #2: You’re only considering vendors that everyone already uses
If you wanted to accept recurring payments in 2009, you were looking at a month of red tape, paperwork, and merchant bank accounts. In 2010, with Stripe, you could do it in under two days. But no one had heard of Stripe--their biggest problem back then was market awareness.
With the subscription economy (and FinTech) stronger than ever, getting a sense of new innovation before you start building out requirements could be a game-changer.
The solution-first approach, starting with vendor solutions, has its disadvantages too. It fails buyers that have a unique business approach, lots of historical data, or a large team that need specific workflows.
Mistakes you can make with a solution-first approach
Mistake #3: You’re buying for the buyer rather than the actual users
Many buyers prioritize what makes sense for the company rather than what makes sense for actual users.
In their paper Hard Choices About Software, Rosenthal and Salzman call this thinking strategically instead of operationally. Thinking strategically is essential, they explain, but hurts growth when it comes at the cost “substantive usability issues ignored." This could be the problem when the new solution solves everything in theory but falls apart during implementation.
If you’re buying for a team, it makes sense to truly understand what they need from the software before you buy a solution (and make sure to get a trial or opt-out clause).
Mistake #4: You buy software that you don't need yet (or might never need)
It’s easy to be biased towards a solution today.
Sean Flynn says: “In the subscription economy, there are so many incumbents out there who are saying, ‘here is your big problem’. You’re likely to believe them, especially if you’ve heard of the company before. But my advice is to make sure a problem really hurts before you assign a system to it.”
But this is where Sean and Nadia disagree. Nadia invested in Oracle Cloud anticipating problems. She knew that the pain of migrating data and moving the team over would be too much to overcome later on.
This is a tough mistake to avoid. A good rule of thumb, though: even when you know what the problem is going to be, you should still run a thorough vendor evaluation process to make sure that you're solving real problems.
Mistake #5: You fail to account for how the problem will change over time
Tools exist in an ecosystem. And you don’t want to choose software that fits one function and imbalances another.
Nadia says, “[Choosing software] all depends on the stage of your company and its growth trajectory. If your company is showing 10% growth year-on year, for example, maybe Oracle Cloud is not the best choice in the early days. But if you work for a hyper-growth company that’s going to be surpassing 100M in ARR in four to five years, you have to think differently.”
A three-step system that balances the pain-first and solution-first approaches
A framework that marries the best of both approaches equips the out-of-date buyer with market updates and the unique-use-case buyer with better talking points for internal conversations.
Step 1: Start with a lightweight vendor search
Step 2: Transform features into requirements
Step 3: Analyze requirements and process workflows with users
You’re ready to create your vendor shortlist!
Here are the three steps laid out in a handy Google doc for the next time you’re buying software.
Step 1: A lightweight vendor search
Treat the initial vendor search as a discovery opportunity. Look for how the market has changed. If there are new vendors available, what's different about their approach? How have the old leaders updated the playbook? Has the thinking about the problem progressed? Demos, case studies, and thought leaders are resources that can help. The key is to let go of the pressure of finding a solution that fits. This is reconnaissance.
It's also worth keeping an eye on how the problem changes over time. What software do companies like yours transition to when they grow? Nadia tells us Robinhood's growth trajectory was a true north star when she had a decision to make.
The reason to start with a lightweight search is to gather concrete talking points you can take to users.
Make a master list of features (or only new features if it applies) as you come across them. With step two, you turn these features into talking points.
Step 2: Transform features into requirements
Features don't make for good talking points because users don't think in features. They think in "jobs to be done." With this step, you're translating everything you've learned about the market into requirements. And aligning expectations with what’s out there during this research phase.
Here’s an example of why transforming a feature matters. If you looking into software for managing recurring payments for example, you’ll come across a feature called "Dunning." Without software, Dunning breaks down into three completely different requirements:
- Tracking failed payments.
- Automatically retrying a credit card in case of a payment failure.
- And following up with a customer over email in case of a hard decline.
Working with our AR example, after looking at vendors catering to different stages of the problem, you should have a rough list of requirements that looks like this:
Apart from providing great conversation starters, transforming features into requirements is a great way to identify unknown needs and solve the problem of missing out on features you didn’t know about.
Step 3: Analyze requirements and process with users
Putting together a rough list of requirements that are up-to-date with the latest vendor solutions can transform user interviews. The requirements give users a nice starting point when you ask them about their thoughts on the best way to do things.
The questions themselves don’t change too much:
- How are you solving for the process right now? What’s taking the most time and effort?
- Rate these requirements in order of priority. Which would you say are non-negotiable in a new software system? Which ones are not necessary now but will be in the future?
- How much data would you need to migrate to a new system?
Armed with rough requirements, team members aren’t starting from scratch when thinking about what process will work best for them.
More, they’re able to point to tangible outcomes better. And they’re able to prioritize features that actually exist when thinking about productivity.
A confident vendor shortlist
There are those partial to the solution-first approach, where you work inward from solutions in the market to pain-points in the company. And there are buyers who favor the opposite—working outward. They start with the pain they’re facing and document what they need from a solution first.
Both come with shortcomings. Starting with the pain doesn’t mean you pay less attention to vendors. Rather, it means you create a bias for yourself when you get down to buying. There’s an opportunity cost to going back to the drawing board and reconsidering pain-points.
Likewise, choosing the solution-first approach means that when you do get to your company you’re looking at it through the lens of what’s out there. And that can bias you against pain-points. You weigh them differently. Especially if you’ve found a product you like.
Following this three-step framework will help you run an efficient vendor search, and ensure that you fully understand team needs and market solutions.