.svg)
According to the Economist, Kirkland & Ellis, the world’s largest lawyers’ firm, has announced plans to spend half a billion in the coming years on internally built solutions.
The reason is easy to understand: progress in AI have shifted the cost-opportunity of buying an external tool vs building a customized solution.
But while we’re entering into what some start to call “service as a software” era, to represent how easy it is for companies to create customizable software, the risk for companies is to focus only on what technologies enables instead of the business cases it solves.
The innovation frameworks applied by SaaS companies are now a must for every other company to apply.
The customization of software solutions and the era of “service as a software”
Last week the Economist published “Fear of the SaaSpocalypse is tormenting techland". The central idea is that an industry that a few years ago looked unstoppable (software) is now threatened by AI. Companies are embracing “build versus buy” and are increasingly developing internal AI tools rather than buying third-party ones.
The logic makes sense. Traditionally, buying a third party software (think of a CRM) meant companies had to find the tool that met their specific needs (use cases). Time went into the research of the right vendor. Then once the tool was found, companies were faced with the configuration and integration phase. Good vendors allowed for flexibility of configuration. Great ones even offered “templates” for specific user case (remember Monday.com?). However, many features were not used and sometimes configuration was so hard and custom that made you wonder “shouldn’t we just build a tool ourselves?”.
Building internal means that companies can build exactly the tool they need and break free of the high costs per seat that make SaaS tools very expensive.
The flip of the coin: benefitting from others’ best practices
However, there are advantages related to using a solution that someone else develops for you. Using third parties software, users could outsource product innovation, which was a part of the package they licensed. It was for software companies to have entire teams dedicated to user experience and innovation.
Often companies could benefit from features that made their life easier even before they the need came.
A new feature built on someone else’s use case meant companies could use “group knowledge” and apply others’ best practice to their business. For example, I remember I liked Pipeline over the other CRMs because it nudged me in a way others didn’t.
Now, companies will have to rely more on their own abilities to develop their own use cases. This will make the need for intentional product innovation more visible.
The risks of unorganized launches
Teams tend to underestimate the hidden cost that goes into dedicating time to initiatives that don’t succeed. When everyone can launch a product in an afternoon, the cost is easy to dismiss.
Yet, one afternoon after another, the cost of a graveyard of failed pet projects is a huge hidden cost for companies (not to mention the governance risk, which is not a topic for now).
I've seen this pattern repeat with every tech wave (remember the times when everyone was launching a blockchain-based solution?).
How to know internally what to prioritize before the launch? Can teams know why certain things work why others don’t? And can they know it in advance?
The need for innovation frameworks
The need to minimise the failure and waste of new initiatives is what has led the tech industry to develop frameworks for innovation. These frameworks have made the tech industry successful.
Now the same frameworks need to be mastered by companies that are turning into software development companies but have traditionally never done innovation.
For a successful launch, these companies need to remember that the value of the new tools being launched is not in the tech, but rather in the business function they solve.
Credits: Photo by Per Lööv on Unsplash
.png)
.png)
.png)
