Don't buy software until you know what problem you're solving.

I've spent a meaningful part of my career evaluating, choosing, and implementing business technology — CRM systems, customer-support platforms, automation tools, and more recently, AI. I'm not going to name any of the companies I did that work for. The specifics aren't the point. The pattern is the point, and the pattern is this:

Most technology decisions start in the wrong place.

They start with a tool. Someone sees a demo, or hears about a platform, or gets an email from a vendor, and the conversation becomes "should we get this?" before anyone has clearly said "what problem are we trying to solve?"

I understand why it happens. Software demos are good. They're designed to be good. A well-run demo makes almost everything look easy, because the demo is showing you the best-case version of a workflow that, in your real business, will have exceptions, edge cases, and people who do things their own way. It's easy to walk out of a demo thinking, "Yes, this will fix it." It's harder to know whether "it" was actually the thing that needed fixing.

Feature lists aren't requirements

Here's something I've seen repeatedly. A team makes a list of features they want. They compare products by checking boxes. They pick the one with the most boxes checked. And then they implement it, and the underlying problem is still there — only now there's also a new system that everyone has to use.

Feature lists aren't business requirements. A feature list tells you what a product does. A requirement tells you what your business needs to be different. Those are not the same thing, and confusing them is one of the most expensive mistakes I've watched teams make.

The right sequence is the other way around. Understand the current workflow first. Not the idealized one — the real one, with all its mess. Then identify what actually needs to change. Then define what success would look like — concretely, not "better." Then, and only then, evaluate technology against that.

When you do it in that order, two things happen. First, you often discover that the problem doesn't require new technology at all. Second, when it does require technology, you're able to judge it against something real, instead of against a demo.

Replacing one bad process with software

There's a particular failure mode I want to name, because I've seen it more than once. A business has a process that isn't working well. They buy software to "fix" it. They put the same broken process inside the new software. Now they have an expensive bad process, with a monthly fee, and a login screen.

Technology doesn't fix a process. It executes a process. If the process is bad, the technology will execute the bad process faster, and now it's harder to change because there's a system wrapped around it.

This is why I keep coming back to understanding the workflow first. If you don't understand what's actually happening today, you can't tell whether the technology you're considering is going to improve it or just digitize it.

And then there's AI

I want to talk about AI specifically, because there's a lot of pressure around it right now, and a lot of that pressure pushes people toward the same mistake — only with more enthusiasm.

"We should use AI" is not a business problem. It's a technology looking for a use. And while there are genuinely good uses for AI, the good ones don't start with the technology. They start with actual work.

Good AI opportunities tend to share a few qualities. They involve something repetitive — something that happens over and over in roughly the same shape. They involve something slow — where a person is doing work that doesn't require a person's judgment, just their time. They involve something that's hard to scale — where doing more of it means hiring more people, and that's the bottleneck. They involve a lot of information — more than a person can comfortably hold or sort through. Or they involve a place where people spend unnecessary time on a task that a model can handle, freeing those people to do the part that actually needs them.

When you describe it that way, the AI question becomes a lot less magical and a lot more practical. It's not "what can AI do?" It's "is there work in this business that has those qualities?" Sometimes the answer is yes, and it's genuinely useful. Sometimes the answer is no, or not yet, and that's fine too. The worst reason to adopt AI is because you feel like you're falling behind. The best reason is because you've found a real piece of work it fits.

I've implemented AI in places where it made a clear difference, and I've watched teams get excited about AI in places where it didn't, because the underlying work wasn't actually repetitive, or the inputs weren't consistent, or the output still needed a person to review it carefully enough that the time savings disappeared. The technology was fine. The fit was wrong.

The question to ask first

So here's the practical version. Before you evaluate any tool — AI or otherwise — ask yourself a few questions.

What's the actual work that's happening today? Can you describe it step by step? What's wrong with it, specifically? What would be different if it were fixed? How would you know? Is the problem the tool, or the process the tool is supposed to support? And if you couldn't buy any new technology, what would you change about the process itself?

If you can answer those, you're in a position to evaluate technology well. If you can't, you're not — and any decision you make will be a guess dressed up as a plan.

Technology should solve a business problem. The business shouldn't have to invent a problem to justify the technology.

That sounds obvious when I write it out. But I've sat in enough rooms where the order was reversed that I think it's worth saying plainly. The tools are better than they've ever been. That's exactly why it's more important than ever to be clear about what you're solving — because the thing you're solving is the only part the tool can't figure out for you.