It might sound funny to say: "No software is the best software." But, after many years in the trenches, I am absolutely convinced of this. All too often in corporate America, a non-technical executive is fed up with a problem. And they go to their technology team (internal or external) asking how software can solve their problem. Their team, excited to help, quickly works on prototyping and developing.

Often skipping the question: is this actually a software problem?

The answer, quite often, is no.

I'll explain.

Almost always, we turn to software to speed up the work that humans are already doing. Or to do it more accurately. Often without asking, “Should a human be doing this at all?" Or another important question: "Can a human do this differently, in a way that would make it less difficult?" Of course, the answer truly is "no" in plenty of cases. But before you dive in, make sure you truly have a software problem.

Stop The Software Mad Dash

It isn’t uncommon for executives to rush headfirst into the mire of software and its capabilities. Often, a new tool, platform, or technology is seen as the golden ticket to the promised land of increased revenue and minimized expenses. Such a ticket doesn’t actually exist. That’s why it’s imperative executives take the time, energy, and effort required to diagnose a problem and create corresponding solutions.

I know it’s easy for me to say, but sometimes, slow and steady beats diving into the deep end with no floaties. Software’s capabilities are innumerable, and its impact is undeniable, but it’s not always the answer.

Executives, especially those without technical experience and expertise, are driven to embrace technology as a way to mitigate FOMO. They see a competitor with a sexy new platform and automatically think it’s time for an upgrade. Slow down, smell the roses. Ask yourself the question: “What problem am I actually trying to solve?”

Define paint points, analyze the processes needed to address those pain points, and maybe then a determination can be made if software is really the solution, or if there are other ways to go about this.

‍

‍

Avoid Software Strategy Pitfalls

Here’s the crux of the issue. How do you determine whether or not the software can really solve your business problem? There are plenty of pain points to be addressed. There are plenty of processes that need refining and streamlining. There are plenty of ways team member capabilities can be augmented and elevated. But the answer isn’t always software, no matter how many times software development organizations will tell you otherwise.

I’ve seen it plenty of times. An initial discussion will be set up with a potential client. We all hop on, the conversation begins, and it becomes clear from the outset that the problems being listed won’t be solved with a magical wave of a software wand. I get the AI craze has everyone running around with their hair on fire looking at ways to implement this nascent technology. I see question after question posed on LinkedIn about the next best thing that should be utilized to outpace the competition. And to be honest, I think we’ve taken a left turn when we should’ve gone right.

There seems to be a feeling that we’re in some software Cold War where organizations race against each other to use the newest tech. It may look that way, but plenty of organizations are taking their time, creating business-focused strategies, and then executing precisely when they mean to. Failing fast is only an option for organizations with the requisite safety net. Here’s a poignant quote from David Dozer, co-founder and CTO of Cadynce, which outlines the shortcomings of haphazard software adoption.

“Software can be leveraged as a tool to solve problems but only adds confusion when not implemented in the proper fashion…There are specific actions you can take in order to get the most out of your software investment.”

This goes back to the questions posed in the introduction of this article. “Should a human be doing this at all?” and "Can a human do this differently, in a way that would make it less difficult?"

Think of it this way. Is having an Excel sheet detailing potential clients, where they stand in the funnel, and other relevant information helpful? Yes. Is manually updating these client profiles the best way for a team member to spend their time? Probably not. But that doesn’t make it a software problem. It would seem like automation would be a helpful addition to this situation, but automating a bad system just leaves you with a fast, bad system. Not a good system. That’s an important distinction that executives must keep in mind when determining their software strategy. Some new platform or tool that sells rapid impact may leave a wake of destruction when the quality inevitably lags behind.

‍

‍

When Is A Business Problem A Software Problem?

There’s a litany of software options available to organizations, and that list gets longer every day. No matter the market, no matter the business problem, there’s a platform, tool, or piece of technology touting its impact.  And that’s why problem identification and intelligent strategy is vital. Here’s a quote that perfectly describes the mindset an executive must have when approaching software implementation.

“Understanding the business problems you are trying to solve is every bit as vital as the tech employed to tackle them. The key lies in finding that golden equilibrium between the objectives of a project and the technology deployed.”

Now, every organization is different, and every executive will have a different decision tree informing their steps along the way. But the starting point is the same. There’s a problem that needs solving. The key is to categorize the core attributes of the issue so that it can be addressed correctly.

Say you’re struggling with scalability. You’re trying to grow, and maybe even being successful in bringing in new business, but the operational side of things is faltering. Well, aren’t you in luck? There are a million different solutions at your fingertips just waiting for the go-ahead.

These broad strokes won’t be beneficial in determining a solution. In fact, it’s detrimental.

The issue isn’t “scalability”. It’s that your document workflow is painstaking. Or you have too many tools/platforms, hindering your team members’ ability to keep up with growing demands. Or your platform is outdated, and its capabilities don’t meet your organization’s needs. Specificity is the name of the game here. Those three issues all require different solutions. That is the shortcoming of just addressing “scalability” instead of addressing those three problems or the multitude of other hindrances that could exist. Without specificity, the road you travel will remain a muddy mess, not a paved highway.

‍

‍