Chapter 5 – Understanding the Technology Adoption Life Cycle (TALC)

Introduction

As a sociological model, the technology adoption life cycle (TALC) describes the adoption/acceptance of a new product, according to demographic and psychological characteristics of a group (Hackos, 2007). 

The adoption/acceptance over time is represented by a bell curve model, as utilized by Everett M. Rogers in his work in 1995.  The model is broken down into five categories, which act as groups of indicators: innovators, early adopters, early majority, late majority, and laggards.  By analyzing this model, a company can determine the best strategy for each phase of a product’s life (Chasm Institute, n.d.). 

Implementation of the TALC: An Outside Perspective from Katrina

First, let’s take a look at the model.

Markets that develop along the TALC and the types of customers that dominate them (figure courtesy of Chasm Institute).

For a better understanding of how this model relates to customers and understanding their needs, think of it this way.

The greatest benefit that the TALC provides is that it allows businesses to gain perspectives on the needs of its user communities.  It also gives businesses the ability to make critical decisions regarding the level of support offered for project managers.  But the question then becomes, “To what extent can a firm influence the evolution of the innovation?”  Well, that depends on a variety of factors, including technological uncertainty.

A real-world example of this comes from Automated Teller Machines, or ATMs.  Because this concept falls in to the Early Market phase, customers at this point realize that while the technology of an ATM may be new, it has potential to break barriers in terms of driving marketing.  For example, various business strategies have been adopted by banks at different stages of ATM evolution, based on customer needs.  All sorts of customers, such as cardholders vs. non-cardholders, have been analyzed to determine what tasks customers are comfortable performing on an ATM. 

However, as we’ve noticed in recent years with the introduction of online banking, ATM usage has decreased.  When modeled on Rogers’ bell curve, the stagnant ATM usage provides businesses with the concept of limitations; that is, the physical limitations of what services an ATM can provide for the user is being reached.

What this model proves is that corporations can make better, well-informed business decisions supported by quantitative data, to not only serve their clients, but themselves as well.

A Tale of Two Products and the TALC: An Inside Perspective from Joe

Chapter 5, Understanding the Technology Adoption Life Cycle, hit home for me, as it clearly explained the issues that I’m experiencing with my job, the company that I work for, and our applications as we work toward meeting the needs of our customers in the context of the Technology Adoption Life Cycle (TALC).

The company that I work for produces two different software applications. The first is an ecommerce platform that’s new and sexy, uses the latest technology, and grabs the majority of the company’s development resources. The second is an order fulfillment application that is older, a little ugly, runs on outdated technology, and does not require much upkeep from developers.

In terms of Rogers’ TALC bell curve, the ecommerce platform is stuck in the initial stages of the adoption life cycle as we struggle to move beyond meeting the needs of the innovators and early adopters. As Hackos states, “In most cases, innovator and early adopter customers are integrally involved in helping a company develop the product in the first place” (125). Without the guidance, suggestions, and gentle nudges that our first set of customers have given us, the product would not be nearly as functional or feature-rich as it is currently. However, as the ecommerce product grows, stabilizes, and matures, so does the necessity that our product moves beyond these initial stages, across Moore’s chasm, and into the profitable land of the majority.

At the moment, the product is experiencing what could be considered “growing pains”.  As our user base and their expectations change, so should our business strategies. The majority markets want a stable product that’s bug free, easy to use and well-documented. These types of customers do not want to experiment with settings in order to find something that meets their needs. Instead, they expect the product to suit their use cases right out of the box. Furthermore, the majority users require user manuals and other training media that allows them to do the configuration of the application themselves, without the need for a hired implementation consultant or programmer. When we were serving just the innovators and early adopters, a rag-tag team of software developers and a business analyst were the only resources needed to make the customer happy. However, now that the company is attempting to satisfy the majority, we are faced with hiring more quality assurance testers, technical writers and training specialists whose single focus is on meeting the needs of the majority users.

The company’s order fulfillment application, on the other hand, is on the far right of the TALC curve – the laggards. Like mainframes and other hold outs, our order fulfillment application gets the job done – albeit in a not-so-pretty way. Because the application relies on technology platforms that are outdated (and is incompatible with the latest operating systems and database servers), we can only market it toward laggards who haven’t yet upgraded and don’t plan to upgrade in the next several years. These are customers who are happy to maintain an aging system – moreover, because the application is so mature, the documentation and resources are available to ensure that supporting such an ancient system is easy.

Put into the context of the TALC, it’s easy to understand the direction that the company’s applications are headed and the diverse needs of each user group. However, as we are currently experiencing, getting across Moore’s chasm is anything but simple.