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.
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.
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.
.png)
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.
I am not suggesting we go back to pen and paper, slowly and inefficiently completing tasks that provide minimal impact. Technology is everywhere, and its impact on business can’t be understated. My point is that seamlessness and accessibility are the make-or-break factors. This is what idealists forget.
The best kind of software is one that you don’t realize exists. One where you think only about doing the required task, not figuring out how to do that task. Where every step of the journey is painless, rewarding, and efficient.
How many times have you tried interacting with a newly implemented AI Chatbot, wading through all the useless messages, hoping to just get in contact with a human that will actually be helpful? That chatbot was a “solution” that likely wasn’t cheap to create and implement, yet it failed to do its job. Let’s say this “solution” was used in the hopes of alleviating the responsibilities of certain team members and increasing the efficiency of handling user complaints. And yet, the nature of such a jolting interaction just leads to dissatisfaction and users abandoning the process entirely. It’s not the golden ticket the team behind the project would’ve been hoping for.
This is why I say that no software is the best software. There are plenty of “solutions”. The trick lies in determining how that solution aligns with your needs and solves your problems. Struggling with your document workflow, which is affecting your scalability? Analyze the process, diagnose weaknesses, and then utilize a platform/tool that streamlines and refines that process. That is a business problem solved through the intelligent usage of software. The steps to get there are as important as the solution itself. The strategy used to find the solution, the specificity of the problem’s attributes and characteristics, can be applied to every business problem where software can be utilized.
This is what I’m constantly reminding everyone of at thinkbridge. It’s not about having the latest and greatest (although that can help). It’s about how you use the resources at your disposal and the strategy that informs those choices. Everyone wants to be an innovator, so afflicted by FOMO that they’ll jump at the opportunity to use any new tool or technology. But innovating just for the sake of it leads to overly complex systems that fail to solve real problems. So, before striving to be the next big thing, determine what your true problems are as a business, analyze possible software solutions, and only then make the decision to implement something new. Everything should be purposeful. I’ll leave you with this quote from Corey Phelps, a strategy professor at McGill University. It illustrates the importance of executives having the right mindset when it comes to problem-solving that easily applies to those looking to utilize software solutions.
“There’s this belief that because we do it so frequently – and especially for senior leaders, they have a lot of experience, they solve problems for a living – and as such, we would expect them to be quite good at it. And I think what we find is that they’re not. They don’t solve problems well because they fall prey to basically the foibles of being a human being – they fall prey to the cognitive biases and the pitfalls of problem-solving…And especially, I would say it happens in organizations because in organizations, when you layer on these time pressures, and you layer on these concerns about efficiency and productivity, it creates enormous, I would say, incentive to say, ‘I don’t have time to carefully define and analyze the problem. I got to get a solution. I got to implement it as quickly as possible.’…And we can then say, ‘Oh, this looks a lot like the problem I faced before, that solution that worked there is going to easily work here.’ And we try that solution, and it fails, and it fails largely because if we dug a little bit deeper, the two problems actually aren’t much alike at all in terms of their underlying causes.”
.svg){kind=small}
.webp)
