Monday, July 28, 2008

Understanding the Technology Adoption Life Cycle


Audience analysis does not always yield the desired result of understanding the exact needs of the audience. Such an analysis is very helpful when you develop content for a new product that introduces a new technology. As the technology becomes well-known and the product comes up with enhanced versions, it is necessary to understand more about the changing needs of the audience. Technology Adoption Life Cycle plays a prominent role in such a situation. A technical writer must understand the nuances of the technology adoption life cycle to cater to the needs of the audience effectively.
The technology adoption lifecycle is a sociological model, originally developed by Joe M. Bohlen and George M. Beal in 1957 at Iowa State College. Its purpose was to track the purchase patterns of hybrid seed corn by farmers. Approximately six years later, Everett Rogers broadened the use of this model in his book, Diffusion of Innovations. In the book, Crossing the Chasm, Geoffrey Moore proposes a variation of the original lifecycle. He suggests that for discontinuous or disruptive innovations, there is a gap or chasm between the first two adopter groups (innovators/early adopters), and the early majority. (Source: Wikipedia.com)
Broadly speaking, documentation managers must position information development to match the needs of the technology adoption life cycle. Likewise, funding for information development must focus on the needs of the majority market. Technical writers must understand the participants in the Technology Adoption Life Cycle before getting into the documentation tasks.
In the technology adoption life cycle, customers can be classified into these categories:
  • Innovators are technical experts who need little information to begin with. In most cases, innovators help in the development of the product and assist in documenting use cases and improving functional specifications. You can gather information from the product developers and organize it to meet the needs of the innovators without simplifying the content to a great extent.
  • Early adopters require a subset of information products as they are more likely to learn things by experimentation. Most of the times, they have access to the product developers and product developers see them as seasoned technical professionals. Early adopters use the inputs of the product developers to understand how they need to implement in their environment.
  • The Chasm – Moore points out that most companies find it difficult to cross this chasm as they focus too much on the innovators and early adopters. They fail to cater to the needs of the majority of customers and their solutions are not so successful.
  • Early majority customers are better known as pragmatists demanding good service, information, and training to try the product. As Moore points out, they rely more on the whole product that comes bundled with more information, better training resources and adequate technical support. They prefer elaborate procedures with clear instructions and are reluctant to accept vague information.
  • Late majority customers are skeptical about new products and resent complex new technologies to a considerable extent. They need quick and easy answers to their questions about using the product. They need simple yet clear procedures to implement their tasks. They are disinclined to get in touch with the customer service because they assume that the support personnel are not aware of their business needs and concerns. Most of these customers ask for job aids, wizards, performance support, and maintenance support aids.

While innovators and early adopters help in the introduction and development of product, it is only the early and late majority customers who drive the growth of revenue for the product. The customers in these groups encompass the largest customer base. Technical writers should understand where the product stands along the bell curve and tune their documentation to suit the needs of the corresponding customers.

Ref:

Managing your Documentation Projects - JoAnn T.Hackos

Wikipedia.com