Truth is a battle of perceptions. People only see what they’re prepared to confront. It’s not what you look at that matters, but what you see.
“Revenge” (TV Series)
In the previous article I talked about the evolution of user interface integration technology. In the early days we (the creators of Inventys Fusion) classified this technology as “enterprise mashup”.
Customer care contact centers were popular targets of this “mashup” technology, since their agents often had to grapple with over a dozen legacy applications in order to service callers’ requests. We then moved to back-office use cases — and there were plenty of these — in banks, insurance companies, airlines, telcos, etc. Back-office use cases did not often require “single-view” mashup screens. These use cases were mostly workflow related — automating the typical software driven labour that I have talked about in previous articles.
The use of Fusion and other similar products to automate software driven labour tasks fits correctly with the nuanced definition of automation that I stated in a previous article. From here on we will use the term “UI Automation” refer to the automation of software driven labour activities by screen integration technologies.
It was in 2009, based on consistent successes we had in back office automations, that I felt that we need to take this solution to established BPOs (business process outsourcing companies). We decided to explore this solution concept with various India based BPOs. On arriving in India and showcasing the solution to a few establishments in Bangalore and Delhi, we realised that a key characteristic of BPOs was that their agents accessed their clients’ apps via a technology called Citrix. The apps don’t actually run on the local PC, you only get to see a copy of the screen — transmitted as pixels — but you get to interact with that app via mouse and keyboard connected to your PC. Very roughly speaking it has the same effect as being on a Zoom call and watching someone else’s screen being shared and then later taking control of that screen from your side.
None of the UI Automation products were geared for this. We did previously solve the Citrix integration issue in 2006 but that required an “agent” software to be deployed on the Citrix server. The installation of the agent requires the owner of the Citrix installation to cooperate. But in the case of BPOs, in those days, it was unthinkable that their clients would ever permit a foreign software component capable of intercepting Windows messages. So the necessity to overcome this issue caused us to invent an “agentless” Citrix adapter.
It was this agentless Citrix integration that singularly changed the adoption rate of UI Automation among BPOs.
The BPOs by themselves were already working on every possible way to make their lives more efficient and automated. Almost every BPO that I had visited in those days had reasonable investments in operational excellence initiatives. They had built various kinds of macros and software tools to help the agents optimise their work. However, the emergence of a commercial software tool that could integrate with a wide range of screen types and even “drill through” Citrix was a welcome improvement and thus began the rise in adoption of this technology.
Of course, there were other types of scenarios such as captive shared services and local back offices that did not require Citrix. Other companies that did not have agentless Citrix automation focussed their efforts on those use cases.
Inventys Fusion was received well by the BPOs that we presented to in India. Almost all of them were multi-national corporations with significant India-based BPO operations. We did not encounter too many objections, barring a few exceptions. I was amazed at the speed with which my prospects picked up on the technology, its use cases, and benefits. Even at CxO level presentations, I often did not even have to speak a second sentence to reinforce the message. I remember watching in glee during my product presentations, when the tech leads and CIOs would simply take over and start discussing among themselves on how and where they were going to apply this product. The only thing that remained in the sales process was that they needed to verify that our product could indeed do what we claimed it would. Since it was then a ‘disruptive’ technology and their own in-house endeavours had mixed results, they just wanted a formal verification that the product could indeed orchestrate UI screens.
Our agentless-Citrix adapter was the game-changer. Apart from our product and technology, the main reason for our success was the support and keen involvement of Denise Ireland, a senior BPO executive who was so impressed with the technology that she decided to work full-time as reseller and later as an investor. It was an eighteen month spree led by Denise that got almost every top BPO present in India to engage with us. At that time, the term “RPA” had not yet been created. But I can say this without a doubt that this screen-integration technology became a hit only after the BPO industry’s India operations centers picked up on using our product for “process automation”. Without their active interest, this technology would have remained relegated to a few in-house voice contact centers and in-house banking back-offices.
So, according to me, had it not been for Denise Ireland’s pivotal role in pitching this solution to the right people in the BPO industry, leading them to use the product in various process automation scenarios, this technology would never have seen the kind of adoption and usage that it subsequently enjoyed in the shared services and BPO sector.
Those of you who are still drawing your livelihood from RPA should thank her for it.
For those who follow Star Trek, this spree at the Indian BPO centers can be likened to the first warp flight of Zefram Cochrane. The warp signature from that first flight was picked up by a Vulcan ship, leading to “First Contact”. (You need to be a Trekie to understand this paragraph. Or perhaps do some intense Internet searches for Star Trek history.)
The “warp signature” of our successes in BPO-level process automation reached other shores and eager clients explored local vendors with similar offerings — the only problem there was that they didn’t have agentless-Citrix application adapters.
Even as we were increasing our footprint in the BPO industry, I remembered our origins (process integration) and realised that this technology is actually a BPO-killer rather than a BPO-supporter. Around 2010, I embarked on a fund raising mission for Inventys, to help us grow the company. Our product was in version 3.x and we had found a series of clients who were ready to pay good money if we were able to implement UI Automations in their respective BPOs. I recall a phone conference call with a group of successful-entrepreneurs-turned-investors. One of the gentlemen in the call was introduced as the “father of Indian BPOs” or something to that effect. I forget his name but I recall the epithet. Upon hearing the features of Inventys Fusion, and our initial successes with BPOs, this person very bluntly told me on the call that BPO is not my target market and that I should have taken this technology to the United States, to clients of these Indian BPOs. So, even the “father of Indian BPO” believed at that time (around 2010), that this technology will upset the BPO industry. He did not put his money on us, but at least he had the intellectual honesty to admit that such a technology could hurt the empire that he had pioneered.
A quick detour: as alluded in a previous article, BPOs have tried to move up the value chain — they have created verticalised platforms for various organisational functions such as finance and accounting, human resource management, fraud management, insurance management etc. They have also attempted to move into non-transactional processes such as knowledge process outsourcing, and legal process outsourcing. I will explain my opinion about these in a separate article.
The purpose of this article is to chronicle our journey as we attempted to increase the adoption of this technology. The most important adoption that we wished to achieve was with potential clients. The other kind of recognition that we desired was with potential institutional investors. I will discuss both these endeavours here.
Our efforts to promote UI Automation among the BPOs operating in India proved to be extremely successful. Despite the father-of-Indian-BPO‘s reluctance to participate in our success, all his “children” — from the mighty Top-5 to the mid-tier companies — welcomed our technology and expended much effort to determine all possible scenarios in which our product could be used. Some of these companies were global multinational IT powerhouses, and they were not doing us any favour by initiating these projects. We were subject to various rigorous global evaluations. They did extensive searches in all geographies to see if they could find competitors who could match our product’s capabilities. We earned every cent that we made in those deals. But it was an absolute pleasure dealing with people who knew their business, and also knew technology well enough to challenge us as well as to support us.
In contrast to our success with India-based BPOs, the adoption story with non-BPOs in our home ASEAN region was very unimpressive.
There are many who believe that Asia is the next destination for economic boom and success. Many are moving to Asia in the hope of catching a slice of that success. Perhaps there is some truth to that sentiment at some macro level. However, the one thing that I am very certain about is that enterprise technology buyer behaviour in ASEAN and APAC countries is orders of magnitude poorer than that of United States, and Western Europe. The economic success of America is often attributed to the spirit of venture of its people. Many books have been written about the legendary risk-taking financiers of the industrial revolution. To this day, the United States continues to be the nerve center of venture financing and high-tech startups. Much credit has been given to venture financiers for providing fuel and a fair chance to people with good ideas and ability to execute. However, an equally important and, in my opinion, extremely essential factor is the availability of buyers who are willing to purchase and try out the products and concepts that are put forth by entrepreneurs. You cannot venture finance a startup to success unless there are enough buyers willing to use the products of innovative startups.
That brings to fore the concepts of buyer behaviour and product market fit in the context of enterprise software sales.
I don’t think these two topics are two sides of the same coin; instead, I believe they are like two strands of strings that are pleated together to form a rope on which hangs the success of a commercial product. It is a misconception that buyer behaviour is a factor in determining product market fit. A common, but erroneous line of reasoning is that a market comprises of buyers and sellers; ‘product market fit’ is a measure of whether a product has sufficient utility and cost-effectiveness to entice buyers to buy the product; buyer behaviour determines whether the buyer will buy the product; therefore buyer behaviour determines the product market fit for any given product. This is not true, especially for enterprise buyer markets. The utility and benefit of a product are independent of whether or not a potential buyer perceives those qualities.
First, let us explore buyer behaviour. Buying for personal needs and desires is very different from buying for organisational requirements. For an individual making purchases to satisfy their own wants, it is but natural to assume that they may not be an expert in a wide range of topics such as cameras, lenses, mobile phones, computer design, sunglasses, home construction, financial markets. But they may wish to purchase things that are related to all of the above mentioned topics. Therefore vendors of such products and services need to assemble significant marketing strategies help laypersons understand and appreciate the various wares that they hope to sell.
On the other hand, organisational purchases are made by people who are supposed to be qualified and experienced in being able to assess their organisation’s requirements, scan the market for suitable solutions, evaluate them, and make justifiable purchase decisions. This ability is a function of the size of the organisation. Smaller organisations will have limited workers who will have a limited range of aspects that they can professionally evaluate. For example, a ten-person textile manufacturing business may not have a suitably qualified person to evaluate the best accounting software for their business. In such situations they will have to rely on the “industry norm” for businesses of their size and take a decision. But a regional telecom company or a bank with several tens of thousands of employees will employ highly specialised teams to manage various aspects of the company. During the process of selecting, for example, an appropriate enterprise resource planning (ERP) system in such organisations, it is expected that the designated team has sufficient skills to survey the market and make very detailed evaluations about every candidate solution.
Buyer behaviour for innovation is different from buyer behaviour for status quo maintenance, or business as usual (BAU) activities. That is, for example, the process of survey and selection to upgrade a server in a bank’s data center is a BAU activity. The data center’s managers have much experience in evaluating hardware and negotiating a good deal from the sellers. However, buyer behaviour for things that are not incremental or BAU requires a different class of thinking and execution. For example, imagine if a cloud infrastructure vendor meets the bank’s IT and proposes that future hardware increments can be achieved through their Infrastructure-as-a-Service — no need to buy new hardware; it would be available as if “on tap”. There was a time when an organisation with a traditional data center would balk at such a proposal. It would be seen as ridiculous and sacrilegious to even contemplate that an organisation like a bank would ever allow its systems to be deployed on a cloud infrastructure.
I will discuss product-market-fit later in this article. But I posit that even if there is product-market-fitness for a product, its adoption is actually a function of buyer behaviour. It is this buyer behaviour that is the basis of the theory of technology adoption curve, as expounded by Geoffrey Moore in his book “Crossing the Chasm”.
Moore’s technology adoption curve is roughly shaped as a bell curve, except for a “chasm” that breaks the continuity of the curve. Technology adopters are categorised as innovators, early adopters, early majority, late majority and laggards. The buyers and consumers of enterprise software technologies are supposed to be trained and experienced professionals – trained in various software technologies; and experienced in the application of these technologies within one or more domains. Usually they are part of an IT department, or a Technology & Operations department, or some similar organisational structure lead by a CIO (chief information officer) or CTO (chief technology officer), or a similar rank.
There may be various forces at play within each organisation. A significant portion of these forces are based on the prevailing work culture, which in turn is driven by business conditions and economy on the outside, and by leadership and value systems within the organisation. While all these factors may play a role in buyer behaviour for a new product, and thus chart the course of its adoption, I feel that there is another vital but simple underlying factor that plays a very important role in buyer behaviour.
Take a look at the human IQ (intelligence quotient) distribution, which coincidently is also a bell curve.
Now, let us flip it horizontally on the mean and overlay this on the Moore technology adoption curve. What do you see?
My interpretation is that people with higher IQ are able to quickly grasp innovative concepts and benefit from early adoption of new techniques. Yes, you need to filter out a lot more “noise” in the early stages, but that’s their job and they are good at it. Innovators and early adopters can be found in every type of organisation. For example, when we pitched Inventys Fusion to telco contact centers in 2006 we spoke to three regional telcos — equally mighty, with good customer base, revenues, and sizeable IT teams. With one telco, we were quickly called in for a meeting with various IT leaders; within a month one of the IT leaders spotted an ongoing project where our solution could be used, and called us in for further discussions. That lead to a contact center operational efficiency project with wide coverage and high management visibility. With the other two telcos we spent months in meetings and discussions with pensive looking senior managers who were unable to decide even after a superbly successful proof-of-concept evaluation. We even explained how another respectable player in their industry is getting value from our solution. One might think that there are other factors involved in decision making; such as budgets, vendor reputation, trust, personal issues, etc. I can counter each of these with examples from my experience. We have had successful projects with customers where the leader was going through much personal and professional issues. Despite these, he was able to take rational decisions in the interest of the organisation and steer the project to success. Then on the other hand, in the case of a top global logistics company there was sufficient trust and reputation. I had known their regional IT leaders for over a decade and had bailed them out of embarrassment during my BEA Systems days. Despite having concluded a UI Automation proof of concept successfully, that same leadership team simply could not take a next step to initiate a full purchase.
To pioneer a new technology into a large company requires its leaders to have a certain conviction and courage. For this, they need to be above par in competence and intelligence.
While we may think that software technology practitioners and decision makers in client organisations are progressive, agile, innovative, and solution driven, the reality is that many of them are victims of a common counter-productive human afflictions called “technology bigotry”, and “dogma”. Dogmatic thinking correlates with the reluctant late adopters and laggards in the Moore distribution. I remember a confrontation from my Inventys days. We were in the final stages of evaluation of Fusion for use in a large Australian telco’s contact centre. One of the senior architects who was evaluating our technology confronted me during a session and very flatly assured that he “… will not let this technology (UI Automation) see the light of day” in his company because it would dilute their SOA (service oriented architecture) and other traditional integration initiatives. We had the last laugh there — Fusion was selected and subsequently deployed for several years in their contact center.
Organisations will have a few selfish and bigoted individuals who will set up roadblocks and hide behind concepts such as “architecture validation” and “security” to prevent the adoption of certain new technologies. In almost all cases, the real reason for their objection can be easily traced to the new technology posing a threat, either directly to their status in the organisation, or to something that is dear to them, such as an ongoing project. The only solution to this issue is for the senior management to be alert and watch out for naive objections disguised as “security” and “architecture” issues. The dreaded S-word (security) generally scares everyone and is a common tool used by these bigots in conversations with their seniors who do not know enough about system security.
A case where we didn’t get to have the last laugh was at a very large bank in Singapore. One of the CTOs of the bank (they seem to have a few), outright rejected UI Automation as it was a threat to their micro-services and API driven “smart initiatives”. This was in 2013. Today that very bank has several dozens of staff and contractors feverishly working on UI Automation projects! Low IQ laggards based on my interpretation of the Moore adoption curve.
It would be meaningful at this point to scroll up and read the quote snippet that I have placed under the article title.
Buyer behaviour in enterprise purchases is dependent on the people who have been placed in positions of responsibility in the buying process. Moore’s adoption curve prepares us to realise the fact that disruptive innovation startups need to be very selective and focused on the types of initial prospects and customers that they choose to spend time with. The biggest and worst competition for a new innovative product is dogma, incompetence, and preference for status quo among prospective customers.
Marketing initiatives and campaigns can alleviate this issue to a large extent. Through marketing efforts, sellers aim to:
- explain the value of the product/service,
- get reputable people or bodies in the prospects’ industries to speak about the benefits of the product,
- generate “thought leadership”, and
- create circumstances where decision makers in prospective customer organisations will face peer- or community-pressure if they are not seen to be doing something with the seller or the new technology.
The success of the above actions results in solid lead generation that can be converted to sales via dedicated relationship management.
Large enterprise software products cannot be sold simply by setting up an online purchase Web page and credit card payment facilities. There are certain genres of products such as Web conferencing (Zoom, Webex, etc), and team communications and project management (Slack, Atlassian, etc) that can begin their existence in a prospect organisation as a result of someone downloading, installing, and in some cases even making a small payment via a corporate credit card.
Buyer behaviour can be influenced to a great extent by a well executed marketing strategy. In order for startups and young companies to be able to create disruptive products that require substantial shifts in buyer behaviour, there will eventually be a need for big investment towards marketing efforts. The corpus of funds for such activities is usually obtained from venture investments in equity of the company.
Institutional investors have a favourite phrase that they use often during initial evaluation of prospective startups. It is called “product-market-fit”. The idea is that eager entrepreneurs keep creating products that they think will have a market. However this may not be a valid assumption. Unless there is a fitment between the needs of the market (the potential consumers) and the capabilities of the product, it is logical to conclude that there will be no sale. So the advice given to startups is to test the market with what is called a “minimum viable product”, and to keep improving based on feedback. A very good idea indeed.
But enterprise software technology adoption, as we have seen before, is driven by an adoption-cycle Bell curve that — according to me — correlates with the IQ of the buyer population. That is, the smarter people will quickly foresee and extrapolate the capabilities of the product and find ways to use it in the organisation. Those who are behind in the IQ queue will wait for a greater force to be applied on them to knock them out of their restful inertia. That greater force is usually applied via top class marketing.
Therefore companies are forced to take the perilous path of Moore’s adoption curve and seek innovators and early adopters as their initial customers. The difficulty for companies with disruptive enterprise software technologies targeting medium and large enterprises is that in order to create the “bandwagon effect” they need to bring in external investments to implement a market strategy. Regardless of the type of marketing — digital, guerrilla, social — a certain minimum expenditure is required in order to market enterprise solutions to CIOs, Directors, Vice Presidents, COOs, CFOs, and CEOs of corporations.
In order to convince an institutional investor, the entrepreneur has to demonstrate “product-market fit”. The question therefore is: how can you demonstrate product-market fit using a population that lives in the thin end of a Bell curve?
Then there are droppings of wisdom from certain investors, who like think that they are bearing the modern VC-world’s equivalent of the “White Man’s Burden”. They exhort that startups should not even attempt to disrupt technologies that are the bastion of big players. The journey of UI Automation from what we had created in the early 2000s to now, being called RPA, with one of the vendors going IPO in 2020 is clear evidence that it is possible to disrupt conventional technologies of large enterprises.
Product-market-fit cannot be determined by the inaction of laggards and bandwagon riders. Disruptive enterprise technologies are seldom if ever driven by the potential clients of those innovations. The entrepreneur has to lead the charge and navigate through -3 sigma to -2sigma, and through the treacherous chasm from -2sigma to sigma.
For disruptive technologies, there is no option but to follow the adoption curve. In order to prove to potential investors that there is product market fit, the entrepreneur has to find suitable “innovators” and “early adopters”. This is where geography plays a role. The United States continues to be the best geography for new enterprise technologies. As mentioned at the beginning of the article, while it is true that the US has highly skilled and competent venture financiers, the real heroes are the innovative and early-adopter customers. There is a disproportionately high concentration of these types of companies in the US and Western Europe. This, perhaps is driven by the fact that the US and Europe still attract a high proportion of global top talent.
Based on our experience with selling Inventys Fusion, we figured out that even though we were pitching an application integration alternative, the buyer, typically the IT department of large organisations, was riddled with dogma and inertia, thus making the selling process extremely painful. We quickly found that Business Operations, the people who were actually affected by delays and errors due to software driven labour, were more focused on a solution, and proving the value of UI Automation was a much more straightforward and logical process.
UI Automation’s “market-fit” existed even in the early 1990s. The available building-block technologies at that time were not mature enough for someone to build out an off-the-shelf product that could orchestrate heterogeneous UI screens. This led to the next best option of deploying low-wage workers to perform workflow tasks manually and thus the BPO industry. But then in the early 2000s, when sufficient building blocks became available, a couple of startups worked on productising this technology. The older generation “screen scraping” technology earned so much disrepute (due to frequent inconsistency and errors) in the 1990s, that proverbially it “went underground”. Those of us who pioneered UI integration and automation in the 2000s had at least one page or slide in our marketing material to explain why our product was not a screen scraper!
While our BPO adoption was great, my final goal had always been to take the product to the BPO’s clients and not to simply keep selling to the BPOs themselves. To overcome the “chasm” of adoption, we needed to get external funds for market creation and marketing strategy implementation. Since Inventys was based in the APAC region, with zero presence in the US, we faced a twin challenge. First, there were not enough smart and innovative prospects (other than the BPOs) that we could engage with in this region. Second, the quality of venture financiers in the APAC region for disruptive enterprise software was very poor. For example, around 2008, we had one gentleman from the India office of a famous US based VC who told me that there is no future for our kind of technology because webMethods and TIBCO had cornered software integration and there would be no chance for us. On another occasion, when we had applied for a grant to fund the development of a new “Studio / IDE” for our Inventys Fusion product, an “expert” evaluator’s judgment was that Microsoft already provided Visual Studio, which was a good enough tool, and hence there is no need to build another studio tool!
Such comments are so ridiculous that they are not even in the zone of possible clarification and meaningful discussion. I had read that even the Google founders and people like Mark Benioff had faced a series of infamous rejections from VCs. So I did not feel too disappointed, and instead we pressed on to build more features and focused on customer acquisition rather than VC acquisition.
We had crossed the chasm with the adoption of Inventys Fusion among the India-based global BPOs. But my view was that this technology actually made BPOs irrelevant and redundant. I felt that our purpose was to return business processes back to their owners’ locations, automated through our product and not requiring human interventions from BPOs and SSOs. But the technology leaders in these India-based BPOs were far superior than their counterparts in the BPOs’ clients; and we found more success with the BPOs than with the owners of business processes.
These experiences led me to accept an acquisition offer for Inventys in 2012. I resigned to the fate of having to partner with BPOs and help them automate processes of others. They had the infrastructure and the deep reach into client industries, which was difficult to attain for a startup without adequate funding. In order to serve these BPOs I needed a sizable team that could concurrently implement automations at various BPO sites. The acquirer of Inventys had the local presence and staff strength, and at that time it looked like acquisition was best option to maintain our trajectory with BPOs.
In a land far far away, the turning point for UI Automation happened when a UK-based competitor teamed up with a, then young, technology research firm to coin the phrase “robotic process automation”, RPA, to describe the ability of UI Automation products to automate business workflows using the screens of legacy enterprise applications. What this did was to create an artificial “category” that could be independently taken to the market. Our own strategy, on the other hand, had been to augment conventional application integration with UI Automation, thereby opening the gate to automation of business processes; and thus eliminate software-driven-labour. Our effort did not make much progress with the folks in the centre of the the IQ bell curve.
Much as I detest that term: RPA, I must appreciate the brilliance of the people who took the UI Automation concept and put a wrapper around it and named it RPA. Due to our frustrations with selling directly to IT departments, we had moved our focus to business operations and were more successful in selling “process automation” to these buyers than “application integration” to IT department buyers. The product was exactly the same and the target client companies were also the same. But a change in target buyer profile meant that the market messaging had to change. This is where I think the RPA metaphor really succeeded. It helped the non-techie business operations people to understand the value of the technology.
