A product adoption process is like an election but in a one-party state. Paradoxical, yes, but quite right in the sense that the single party could yet lose and everything could plunge into chaos.
While deploying a new software product into the ecosystem, organizations generally tend to believe that if everything goes according to plan up until go-live, success is guaranteed.
That’s partly because organizations assume that software products that have gained wide market acceptance will also naturally gain user acceptance inside their companies.
But, as more and more organizations seem to be discovering, that’s not the case. It’s just half the job.
Just six months after Salesforce’s IPO in 2005, the churn rate was pegged at a devastating 8% per month. Customers were leaving the CRM platform rapidly, unable to handle the platform and all the features.
And that’s when the company started realizing the importance of customer success and driving end user product adoption. Salesforce continues to focus on end user adoption as a critical component of its customer strategy.
Product adoption is as much about the process post go-live as it is about prior to deployment. It is as much about the end users as it is about the product itself. And that’s exactly why any company’s product adoption process needs to have a solid and dedicated strategy.
Now, the question is: how do you build that strategy? Let’s go about trying to answer that.
When Microsoft launched Office 365, there was universal adoption with 85% Fortune 500 companies having at least one offering running . Forrester analysts called the product the “most important in the company’s history.”
Yet, as of 2017, only 3% of all active Office 365 users utilize Yammer, 12% use OneDrive and Skype and just about 18% use SharePoint. There’s the difference between technology adoption and end user product adoption.
Digital product adoption is different from technology adoption. The paths that both processes undertake are fundamentally different.
Tech adoption in the B2B world is more or less still true to what Geoffrey Moore proposed in his widely cited book, ‘Crossing the Chasm.’ Improvising on Everett Rogers’ Diffusion of Innovations theory, Moore introduced an adoption gap between the early adopters and early majority segments of technology adopters. And he placed the onus on marketers to bridge that gap through targeted product positioning and marketing.
But that theory is about the broad market adoption of software products wherein each organization is treated as a single unit and deployment is equivalent to adoption.
But then, that’s not where the road ends. True product adoption doesn’t end with a sale or deployment, it starts there and ends when the real perceived value of the product is realized by all the end users.
The basic philosophy of product adoption, or end user adoption, starts with why an organization needs to deploy a new software product, probably replacing an older one, and ends with why an end user should adopt it and incorporate it in his/her day-to-day workflows.
Unfortunately, organizations generally tend to misinterpret the business drivers of new software products. They think that new products will actually drive results for the organization. That if they annually invest $500,000 in a product like Salesforce, it would help them make $5mn in annual sales, at the least. That a Salesforce Einstein will tell sales reps what to do and they’ll be able to close more deals faster.
Wrong. Doesn’t work that way.
Software products, no matter how advanced, are just enablers. They only enable employees to deliver more than they are currently doing. They only enable employees to deliver business results. At the end of the day, the real drivers of business results and metrics are still human resources, not IT assets.
That means success of any software product should be measured based on value realized by end users. And this value lies in how well these products enable and empower employees to deliver more. This value also lies in how well end users are able to leverage the tools to their benefit.
Failure in product adoption doesn’t necessarily mean that end users don’t use the application in question at all. They could all be using it everyday but users still wouldn’t have adopted the product until they are able to leverage it to their advantage and are able to deliver more than they ever could.
Product adoption processes can fail because of either of two reasons or even a combination of the two.
#1 there is a misalignment between the organization and employees in the perceived purpose of the software. The organization might consider it important to setup a new marketing automation but employees might think otherwise.
#2 there is a misalignment between the organization and employees in terms of the value perception of the product.
#3 despite there being an alignment in value perception, there could be a consumption gap leading to underutilized software products and thereby a failed product adoption process. That’s exactly what struck Salesforce right when the company was celebrating its IPO.
In his book ‘Consumption Avalanche,’ JB Wood calls it the “Consumption Gap.” Wood says that the consumption gap occurs because software products today are overloaded with features. And end users are unable to optimally use all features.
However, each feature has a value attached to it and aggregates to the perceived value of the product as a whole. From that perspective, adoption failure squarely depends on the perceived value at the beginning of the project. Low value application would have a low risk of failure and vice-versa.
It’s hard to categorize end users within an organization like Moore categorized buyers considering there would be so many different kinds of people. But, broadly, end users can be categorized into two types.
One, who are enthusiastic enough and willing to explore new technology integrating it into their daily workflows. The second category of people are those who just want to play safe and consider new products a risk. These employees generally have a perception that is not aligned with that of the organization.
The product adoption process chasm lies between these two groups of people. Organizations need to ensure that they are able to convince the latter about the value that the product can deliver and the value that they can realize.
Like we said in the beginning, a product adoption process is like an election in a single party state. It’s a win-win or a lose-lose. And elections require a lot of strategizing and micromanagement.
It’s the same with end user product adoption as well. It requires a lot of strategizing and micromanagement.
Strategizing to ensure that organizations don’t overstate or understate the perceived value of a product. Organizations must also ensure that there are proper change management procedures in order for employees to see the purpose of the implementation of a new software product in the company’s stack.
To the first category of employees, the product needs to be marketed so as to clearly define the objectives and expectations from the deployment. Just that so they are guided in the right direction of product usage.
The second category of employees, however, needs targeted messaging in order to persuade them to actively participate in the project. Incentivizing participation and adoption also helps in a lot of cases.
Alignment of purpose and value is what will drive the pre-deployment adoption process for organizations of all sizes.
A lot of organizations still like to use instructor-led training to guide users on how to go about using a new software application. Such training doesn’t have much merit but can be moved to the the pre-deployment phase just to create and spread awareness among employees.
A little like the spray and pray technique a lot of marketers still use!
Micromanagement comes in the post-deployment phases when organizations are battling to cross the chasm of end user product adoption. Or the time when companies are trying to address the consumption gap.
This is where you train and guide each end user individually in order that they are able to discover the software application that the organization wants for adoption to proceed seamlessly and smoothly.
That’s exactly what Whatfix is doing for companies trying to automate their in-app guidance, training and support.
Many a times, being a new application environment, end users don’t really understand how different functionalities work. In such a case, it is natural for them to switch back to their previous methods for the fear of a loss in productivity. Organizations need to guide these users through their workflows so as to ensure that end users understand individual features well and are able to easily retain the learning that they continuously gain and apply it at the same time.