Seems like a silly question right? I have a problem, or maybe just an interest in something new, and I’m going to acquire a product to help with it. I’ll have a few conversations with my boss who owns the budget, convince them that this new piece of technology can help advance our cause and we’re off and running. The biggest shortfalls here are that budgets have been shrinking, we’ve had massive layoffs over the past few years, and with interest rates up, money stopped growing on trees. So how do we navigate this landscape when we want to get something done? The answer is carefully and thoughtfully.
Non-purchases
A quick childhood story to lay the foundation for how I think when making a purchase. My dad used to have conversations with his best friend around great non-purchases. How fun would it be to have a boat? Why shouldn’t I treat myself to an upgrade from the Toyota to the Lexus? That timeshare in Hawaii would be great for Christmas every year. In reality, it’s hard to step out of the moment and pull yourself back from some of the emotions we attach to purchases. When you look back in 6 or 12 months and you realize that you’re much better off for not taking action, it would mean you made a great non-purchase.
Types of purchases
So how does that relate to software? The way I look at it is you have a few main categories of purchase; Net New, Renewal or Replacement at similar functionality, and Change of Service Level (Upgrade or Downgrade). We’ll get into details of each but the main idea behind all purchases is that you need to understand the Business Value of the solution to understand whether the cost of the solution is worthwhile.
Net New
Let’s start with a Net New purchase. When I’m evaluating software that isn’t in a category or function that I currently have, the first thing I ask myself is why? Is there a solid reason behind why I need to purchase this and can I clearly articulate that reason? If I’m solving a problem or unlocking an opportunity, how do I put a price on that? Far too often vendors are the team that is helping build a business case, when in reality I should know my problem well enough to define these items without them. I know my environment better than they do and what my expectations are from a solution. If I can define that ahead of time, I know what I’m willing to pay for that solution. If I can’t find a solution within that price range, then I’ve justified a non-purchase. Just because they tout that their system can give me XYZ benefits, that doesn’t mean those features matter to me or that I should be paying for something I didn’t ask for. One of the most difficult things I’ve seen in the industry is a company trying to remove select line items from a contract when it’s up for renewal. That is because we’ve set a baseline of our expectations and it’s hard to backtrack later on. This makes it even more crucial to understand why you’re purchasing this software in the first place to make sure it’s solving precisely the problem you want it to solve.
Renewals
Speaking of renewals, our next category is understanding how we should be evaluating software at renewal time. This can be a bit tough because we’ve already implemented a solution to our problem but now we need to figure out whether we’re getting business value equal to or greater than the cost of the solution. This can potentially be at odds with the vendor because they’re likely tracking Net Dollar Retention or Net Annual Contract Value against their existing user base. If they aren’t growing existing accounts then their business could be in trouble, which means you have a bargaining chip much earlier in the cycle where they should have to prove their value to you. This actually works both ways, because if they are successfully doing this and are demonstrating value above and beyond what you are paying for it, you would likely be happy to invest more since you are getting the expected returns. On the other hand, if they are struggling to demonstrate value above and beyond the cost, it’s a good time to discuss potential replacements or a reduction in the contract value since it’s no longer a mutually beneficial relationship.
Change of service level (upgrading / downgrading)
Lastly, an intriguing situation is when you are looking to replace an existing solution while upgrading or downgrading your service. In the case of upgrading a service, you are likely going to be paying more than you currently are, so it’s worth considering what extra value the upgrade will bring. If a vendor proposes a 30% productivity increase, is that against not having a solution at all or against the current solution you have? Potentially that increase is only 15% which should affect what you’re willing to pay above and beyond what you currently are. On the other hand, if you are looking at cost savings by switching vendors, have you calculated the possible loss of functionality and benefits that the lower level of service will provide? Have you accounted for the switching of systems and time it will take for the team to become proficient with the new solution? There are many questions that you can ask, but the idea is that you are trying to determine whether you will be better off by moving or if your time will be better spent working on other projects.
Summary
All of these scenarios come back to the basic aspect that if the business value of the solution doesn’t cover the cost associated with it, then it’s okay to make a non-purchase. Inaction can sometimes be the best thing to do until you find something that is a much more comfortable fit to your expectations. Rushing into a decision and not evaluating it correctly can lead to a headache later when you either need to renegotiate a contract or replace a system that the team has already become familiar with. So next time you’re evaluating a solution to a problem, step back and ask yourself if you truly understand the cost of the problem and how much you’re willing to spend to solve it.
