The Chasm Life Cycle and the Implications for Information Developers

Home/Publications/Best Practices Newsletter/1999 – Best Practices Newsletter/The Chasm Life Cycle and the Implications for Information Developers


December 1999

The Chasm Life Cycle and the Implications for Information Developers

CIDMIconNewsletter Katherine Brennan Murphy

We devoted the last day of the Best Practices conference to Geoffrey Moore’s Crossing the Chasm and how we might apply this product-marketing model to information development. JoAnn Hackos gave us an overview of the Technology Adoption Life Cycle (TALC). Then Diane Davis of Synopsys reviewed her efforts to introduce the Chasm model to her organization. Wayne Hodgins rounded out the morning session by discussing the Chasm model’s impact on business processes at Autodesk. In the afternoon, participants divided into Life Cycle teams and brainstormed the implications of the model on content, staff and productivity, and organization. The accompanying table shows the results of the brainstorm sessions.

The workshop’s purpose-energize Center members and conference attendees to find ways to apply the Chasm model to your organizations. Here is the Call for Action:

Reuse the materials presented at the conference to train your staff on the Chasm model. Identify how the model can help you decide on documentation trade-offs.

Meet with your peers in Marketing to discuss the Chasm model. Is Marketing already applying the model? If so, ask to be included in Chasm discussions. If not, explain how the Chasm model is already helping you set goals for information development. Ask Marketing to help you identify where your customers and products might be along the TALC.

Share your progress, successes, and challenges with the other CIDM members through the listserv.

Help us gain from your experiences to expand and refine the Chasm model for information development.

Periodically, we will collect your information and publish an updated table in Best Practices and on the Web site. Make the commitment to include the Chasm in your planning for the new year. CIDMIconNewsletter


Buyer Characteristics

Content Implications


Organizational Implications

  • Technology enthusiasts-“nerds,” “techies,” “propeller heads”
  • Eager to learn on their own
  • Want access to others like them
  • Forgiving of flaws, including horrible documentation and no training
  • Money for only one copy
  • Bare bones
  • Highly technical
  • Focused on single, known users
  • Developer to developer
  • No need for standards-“cowboy docs”
  • Understand customer needs
  • Like working with engineers
  • Can stop at “good enough”
  • Bare bones staff with senior writer/editor skills
  • No need for standards-“cowboy docs”
  • ID must be aligned with product positioning and marketing
  • Must provide clear picture of target customer and overall, long-term product and corporate strategy
  • Need to focus on technology transfer
Early Adopters
  • Technology visionaries who can see the potential of new technologies to solve their business problems even if the discontinuous innovation disrupts their workplace and productivity
  • Searching for significant breakthroughs
  • Demanding and hard to please
  • Will fund basic R&D but want the end product to be a perfect fit for them
  • Focus on the technology rather than the tasks
  • Documents must be accurate but can have content/style/format flaws
  • Technical white papers provide the context and stress the benefits of the technology
  • Develop user profiles
  • Develop a demo to show how the product impacts the customer
  • Learn to prioritize topics
  • Need excellent project management and optimization skills
  • Good enough is good enough
  • Localization may be required
  • Okay to provide many versions; post new ones on the Web to keep up with product development
  • Anticipate lots of changes
  • Proactive partnering with Marketing and R&D to deal with rapid change
  • ID must sell the need for information
  • Pursue partnering up and across the organization
  • Marketing must set and communicate expectations and strategy
  • ID must sell others on incremental releases (appeal to business sense)
  • Interested in incremental, measurable, predictable progress
  • Cautious about risk taking
  • Do not trust visionaries
  • Need full services, including information and training, to reduce risk
  • Want you to know their business needs
  • Unwilling to fund “special solutions”
  • Where possible, use standard business terms (especially in the index)
  • Provide transition/context to move users from current usage/practice to new
  • Begin to develop hand holding strategies, such as wizards
  • Reduce technical content; provide essential, usable detail on tasks, on-the-job applications
  • If possible, use single sourcing to customize examples by niche
  • Provide CBT (self-paced training)
  • Give users confirmation when they do things right
  • Provide efficient error recovery
  • Staff must be able to use the product well
  • Need to see all user feedback
  • Get involved early in product development; negotiate increased/continuous access to domain experts
  • Avoid writers who are technology innovators at heart
  • Use staff trained in audience contact/usability testing
  • Fund higher staffing levels to move from technical to goal- and task-oriented documentation
  • Add quality control/review steps to prevent user distrust
  • Documentation and training must work together
  • Collect success stories/case studies from trainers and field engineers to develop niche examples
  • Connect to your support center to see worldwide feedback
  • Increase the budget for documentation and training even when the R&D budget is being reduced
  • Marketing must make product/positioning information available to present unified messages to customers
  • Get input from usability testing and customer studies to improve the documentation
  • Prefer tradition to discontinuous innovation
  • Like pre-assembled packages that are easy to learn and use
  • See themselves as “not really technical”
  • Reference others in their industry
  • Want the lowest cost with the most standard features
  • Write exclusively from a user perspective; decrease technical and conceptual information
  • Make document/product as intuitive and automated as possible
  • Move farther into customized documentation
  • Focus documentation to reduce productivity hits
  • If possible, completely integrate “documentation” into the product; no training required
  • Provide paper documentation; avoid introducing new media along with new technology
  • Be able to think like the customer; integrate real user tasks; redo reusability with new user population
  • Don’t overemphasize product flaws; give better advice on using the product effectively and efficiently
  • Require good interpersonal communication skills
  • Find staff who accept incremental changes
  • Use staff that is business focused; understand the history of the company and the product
  • See the product from a new perspective
  • Provide a complete, beautiful solution for the customer that is as low cost as possible; perhaps a slim subset document with the most important tasks by industry
  • Funding often a problem because “why spend money on existing product?” Therefore, need to create business-based cost justifications
  • Partner with customer support to get data about FAQs and costs
  • Lead other groups toward standardization/process redesign to reduce costs, increase niche customization, and improve time to market
  • Partner with R&D over incremental product changes to focus on usability impact items
  • Partner with manufacturing to reduce costs associated with information products
  • If you are moving sales to resellers, understand their inventory needs