Non-Human Collaborators in an Enterprise SaaS System
It is time to change the SaaS paradigm
tl;dr Sass-type software services have become the norm, but they are based on outdated paradigms. We need to start developing software in a way that better promotes collaboration between human and non-human actors.
My main focus over the past 15 years has been helping small companies grow their business in Japan. The problem of “simple” product distribution is passé. Look no further than the amazing capabilities offered by Amazon. However, complex or sophisticated products are a different beast. You can sell bicycles or coffee over Amazon, but not sophisticated services for analyzing a microbiome. While helping small companies distribute their complex products, I have participated in the whole range of approaches and have come to the realization that we need a new paradigm for working with enterprise software systems that allows all the various actors, both human and non-human, to collaborate better.
Several years ago, we launched a “low cost market presence” service for Western companies looking to enter the Japanese market. The premise of the service was that we could offer 80% of what a consultant can do, but at 1/10th the price. We were delighted to discover that when we put this concept to the test, it was an immediate hit. We instantly signed up a number of new clients who appreciated our value proposition. Our idea worked! However, a few years into the project we hit a snag. The problem: humans. Tried as we may, we were unable to strictly adhere to the services we designed, which was essential if we wanted to stay on budget. When we offered options A and B, our clients would insist that we give them C. Whether we obliged or not (and in most cases we did), just having the discussions about the options kept us from doing the actual work. We kept drifting more and more towards acting like consultants. We were not able to keep our costs down as planned. The promise of “1/10th of the price” was not being realized, and the business became untenable. We had to find a solution!
We weighed a number of options, but our decision was drastic: we made an about turn. Instead of having people offer the services, we decided that we would just automate everything. After all, thought I, the services were based on a solid model, so switching to software would be a piece of cake. We noticed that when we talked to our clients, they would feel compelled to ask for more, but when they had to interact with a system, they simply accepted the options provided to them and were nonetheless satisfied. With the emerging promise of AI, we believed that software could succeed in allowing us to achieve our vision where people could not. At least, that was the idea. Sadly, we were not able to put our ideas into practice. We still felt we were on the right track, but something was still missing.
We tried offering human-based services, and we tried offering software-based services. Each approach had its benefits, but each one failed. Yet, we were not willing to give up. Our concepts and our deep knowledge of international product distribution were still valid, there was still an enormous need in the market, and we still wanted to use software automation to help small Western companies distribute their complex products in Japan. The problem was in the implementation. It turns out that the optimal solution seems to be somewhere in the middle: not just humans and not just software, but a careful amalgam of both.
To better grasp the problem, let’s take a look at how today’s software is built. For the most part, it is produced similarly to factory-made products. It goes through a design process, gets assembled, packaged, then released to the public for consumption. Once released, there are many differences between how software is managed and maintained compared to products, but that is fodder for another post.
The traditional software system is a “thing” that is developed by its developers, and used by its users. These groups are distinct. They are not part of the same team, but rather they are two sides of a coin, with an abundantly clear separation between them. Oftentimes the two are in conflict. To handle any difficulties with using this “thing”, a support team will be thrown into the mix. The job of the support team is to help communicate the use of the software to the users (what the software can and cannot do), and to help them work through bugs, edge cases, or other unforeseen problems.
There is a better way, but it requires a paradigm shift. It requires doing away with the idea of users using software, and instead moving towards the idea of collaboration. The system is no longer just some thing to be (ab)used, something that forces humans to act more and more like machines. Just creating slicker interfaces will not solve the problem. We need to flip the script, and start to build systems more as extensions of ourselves, rather than us as extensions of them. We can’t just put lipstick on the interface, the change has to come from the core. By changing the paradigm of enterprise SaaS software, we can embrace both humanity and technology. SaaS systems need to promote better collaboration between human and non-human actors.
This is a bold claim, and I have a lot of ‘splainin to do. I plan on doing so in my upcoming posts. Hope to have you back! 👋
Feature image by Gerd Altmann from Pixabay.