You know the feeling. Someone (usually a department leader or a salesperson) comes to you with a problem and immediately follows it with a solution: “We need new software for this.”
And then begins the cycle: demos, trials, pilots, implementation, integration, training, and usually—two years later—you’re paying for software that nobody’s really using because it didn’t actually solve the problem the way everyone thought it would.
Before you say yes to the next software purchase, I want you to ask one question. Just one. It’ll save you a ton of time and money.
The question is: “Does this problem require new software, or does it require a process change?” Most problems don’t actually require new software. They require changing how you work.
Here’s an example. A team complains that they’re losing track of customer conversations. The immediate instinct is to buy a new CRM or communication platform. But the actual problem might be that nobody’s trained on the current system, there’s no standard process for logging information, and people are working around the tool instead of working with it
You can buy new software. It won’t fix that. You’ll just have new software that also isn’t being used properly. The smarter path: understand the underlying problem. Is it actually a capability gap, or is it a process gap? Those are solved very differently.
Here’s the framework:
Step 1: Describe the problem in detail. Not “We need better visibility.” But: “Our team can’t find customer communication history, so we’re asking customers to repeat information, and it’s making our service worse.”
Step 2: Dig into why. Is it because the current system doesn’t have the capability? Or is it because people don’t know how to use it, don’t have a standard process, or are actively avoiding it?
Step 3: Be honest about what would actually fix it. Sometimes it’s software. Sometimes it’s training. Sometimes it’s a documented process. Sometimes it’s changing how you’re doing something fundamental.
Step 4: Only then decide if you need new software.
The companies that have the cleanest operations and the best team morale aren’t necessarily the ones with the most software. They’re the ones who were strategic about software purchases and rigorous about process design.
New software often feels like the answer because it’s something you do—you buy something, implement it, and you can point to it and say “We solved that.” Process change is slower and less obvious. Nobody sends you a trophy for redesigning your workflow.
But process changes actually stick. Software purchases without underlying process design often fail.
So before the next software conversation starts, ask yourself and your team: “Is this a software problem or a process problem?” You might be shocked at how often the answer is “We just need to start using what we have differently.”
That doesn’t mean you never buy new software. It means you buy the right software for the right reasons, after you understand the actual problem.
