exampler.com/testing-com > Writings > Reviews > Maguire Marketing Books

Testing Foundations
Consulting in Software Testing
Brian Marick

Services

Writings

Tools

Agile Testing

Crossing the Chasm and
Inside the Tornado

by Geoffrey A. Moore
(Chasm: HarperBusiness, 1991, ISBN 0-88730-717-5)
(Tornado: HarperBusiness, 1995, ISBN 0-88730-765-5)
reviewed by Brian Marick on October 16, 1996
Buy Chasm from fatbrain.com technical bookstore
Buy Tornado

From the preface of Crossing the Chasm:
"Our [high-tech] marketing ventures, despite normally promising starts, drift off course in puzzling ways, eventually causing unexpected and unnerving gaps in sales revenues, and sooner or later leading management to undertake some desperate remedy... The point of greatest peril in the development of a high-tech market lies in making the transition from an early market dominated by a few visionary customers to a mainstream market dominated by a large block of customers who are predominantly pragmatists in orientation. The gap between these two markets, heretofore ignored, is in fact so significant as to warrant being called a chasm, and crossing this chasm must be the primary focus of any long-term high-tech marketing plan. A successful crossing is how high-tech fortunes are made; failure in the attempt is how they are lost."


Back in my callow youth as a software developer, I knew only two things about marketing people:

  1. They produced random, incoherent changes to the schedule and feature set, justified by hand waving about "the market window". That made me feel annoyed.
  2. They had to wear more expensive clothes at work, while getting paid less money to buy them with. That made me feel smug.

Other than that, they were irrelevant to my life. Except that they weren't, not really. Until I started my own company, I never worked at a place that made a profit. And that was due to the fact that both marketing and development were clueless about marketing. (In the absence of strong marketing, development confidently steps in and makes a hash of things.) We all should have read these books.

Moore's basic thesis works off this picture:

The area of each segment corresponds roughly to the number of people who fit its profile.

The technology enthusiasts are the sort of people who jigger the microwave so they can cook their hands to "see what it feels like". (I know someone who did that. He said it feels weird.) Visionaries are less oriented to exploration, more to exploitation. They are people who see breakthrough potential in some technology and are willing to brave hell and high water to realize that potential. From the vendor's point of view, the nice thing about both groups is that they're not too bothered by the fact that the product doesn't work. They're willing to make it work.

Pragmatists want a product that works. They are not interested in debugging it. They want to be able to hire people who've used it. They want to find books about it in the bookstore. If there's customization that's needed, they want to find third parties who can do it. Better yet, they want to buy third-party packages written for people just like them. In short, they don't just want a product. They want a 100% solution to their business problem. If they get the 80% that delighted the visionary, they feel cheated, and they tell their pragmatist friends.

Conservatives buy products because they really have no choice. They want products that are cheap and do their job as unobtrusively as possible. They are not reassured by the existence of books about the product, because it implies the product isn't simple enough to use.

Skeptics are not going to buy, though they may talk other people out of buying.

Technology adoption is supposed to go from left to right. The technology enthusiasts fiddle with a technology to discover if it's real. If it is, they tell the visionaries. The visionaries then will pass the good word on to the pragmatists. When you're the market leader among the pragmatists, you're finally making the money you promised in your business plan. You also have enough volume and experience that your products are cheap enough and undemanding enough for the conservatives. The skeptics can remain in their cabins in the woods.

The problem dealt with in Crossing the Chasm is that the visionaries aren't in fact good references for the pragmatists. They provide tales of heroics - not stories of smooth, predictable adoption. Pragmatists want references from other pragmatists. (Think about it: if your goal in life, like mine, is to do as little lawn work as possible while avoiding the censure of your neighbors, who do you ask for advice? The person who's out there every weekend tending their gorgeous lawn, or the person you never see?) Pragmatists want a safe buy from the market leader - but there isn't one yet. Crossing the Chasm is about getting the first toehold in the pragmatist market.

Inside the Tornado talks about expanding out of that first niche, about the tornado that results when the pragmatists decide (all at once) it's time to anoint a market leader, and about the transition from hypergrowth to a normal market where basically everyone who wants one has got one.

These books provide a model of the product lifecycle. Like any model, it's oversimplified and draws clear boundaries where reality is perhaps fuzzier. (Moore acknowledges this.) It is perhaps a bit schematic and all-encompassing - but, in essence, it rings true to me. It changes the groundrules of debate. The question used to be "why wouldn't the product enjoy a smooth growth path and whose fault is it if it doesn't?" The question is now "why would this product be exempt from Moore's model and what do we do if it's not?"


Had I read the preceding fifteen years ago, I would have been only mildly interested, even if told that both books are good reads (aside from unavoidable amounts of marketing jargon). What might have impelled me to read the books is the message that a product goes through a life cycle, and that different types of development are appropriate for different stages. I saw around me all sorts of inappropriate and inefficient development that - I now realize - were due to working as if we were in a different stage in the product's life. So how do these books help with development? Here's my take. I've drawn it from the two books, but any nonsensical statements should be considered mine, not Moore's. A similar discussion could be had for product testing and documentation.

Technology enthusiasts present no development problems. You develop the product so that it appeals to you. For example, you don't need documentation, and your audience will be able to live without it. Inconsistency of interface isn't a problem for you, and it won't be for them. Nirvana.

Visionaries tend to work via custom projects. They are basically funding development of the product so that it matches their needs. Development must perform a careful balancing act here. The visionary will not care if every line of code you write is completely useless to anyone else in the world. In fact, because visionaries are in a hurry, they absolutely do not want you to waste time on work that's unnecessary (to them). But you, together with marketing, must identify what can later be productized and develop it carefully enough that you don't end up having to throw it away. It's also easy to lose control of the product's core infrastructure. If you do, you may never be able to achieve the robustness and generality that the pragmatists will later require, not without a complete rewrite - which you probably won't be able to afford in the chasm between the early market and the mainstream market.

Pragmatists want a "whole product". A product in isolation will probably not solve a pragmatist's business problem. It must be supplemented by services and auxiliary products, typically provided by other companies. For a developer, that means increased architectural attention to interfaces with the outside world. It probably means a lot more porting and configuration testing. It becomes important to be helpful to technical writers, trainers, and customer support people, as they provide important pieces of the whole product.

Except in rare cases, pragmatists are reached one niche market at a time. For example, PeopleSoft wanted to be a client/server software company, but they began by concentrating on Human Resources systems, because that was a niche less risky for their customers, one for which they could provide a whole product solution, and one where the competition was weak. Each niche will require some customization or extension of your carefully nurtured core product. As before, don't destroy it as you customize it.

You are still in a stage where important product ideas will come from development - who else knows the product's capabilities so well? - so it is important that you learn the niche market. You are no longer a C++ programmer; you're a C++ programmer who knows something about how veterinarians run their business.

In preparation for moving from a niche to the mainstream market, begin designing out user-visible complexity. Make installation easier. Try to eliminate the need for training. Make the product easier to use. When the tornado hits, the pragmatists will tend to quickly anoint one vendor as the market leader. When positioning your product for that role, the featurefulness important to visionaries and niches is less important than adoptability. The mass market is less tolerant than niches, because it has more choice.

Conservatives, in particular, will not tolerate complexity. They want simplicity and low prices. Your base product has now become a commodity. It has a stable and loyal market that won't pay enough to support a large development effort. Development is now tightly focused:

By this time, development has changed quite a bit since the visionary days. Developers who love breaking new ground with technology may well find this development stultifying. Developers who want a steady, predictable job will find it appealing - and will likely do a better job. One of Moore's contributions is that different stages in a product's life require different skills and personality types. That applies to development as well as to marketing and company management.


These books will help you with the following tasks

(Note: I exclude marketing tasks as being outside the scope of these reviews.)

Architectural Design
These two books discuss how the focus of the product changes over its life cycle. Ideally, the architectural design would support those changes.
Documentation Planning
Different types of users will appreciate different types of documentation, so the document set should change over the life cycle.
User Interface Design
At different stages of the prototypical life cycle, the user interface moves from relatively unimportant to comprehensive to spare to user-friendly.
Discovering Requirements
The target-customer characterization described in Chasm is one starting point for a requirements survey.
Designing a Task-Based Test Case
The target-customer characterizations described in Chasm can be treated as generic usage-based tests.

These books' tables of contents

Crossing the Chasm

Part I: Discovering the Chasm

Introduction: If Bill Gates Can Be a Billionaire
1. High-Tech Marketing Illusion
2. High-Tech Marketing Enlightenment

Part II: Crossing the Chasm

3. The D-Day Analogy
4. Target the Point of Attack
5. Assemble the Invasion Force
6. Define the Battle
7. Launch the Invasion
Conclusion: Getting Beyond the Chasm

Inside the Tornado

Part One: The Development of Hypergrowth Markets

1. The Land of Oz
2. Crossing the Chasm - And Beyond
3. In the Bowling Alley
4. Inside the Tornado
5. On Main Street
6. Finding Your Place

Part Two: Implications for Strategy

7. Strategic Partnerships
8. Competitive Advantage
9. Positioning
10. Organizational Leadership

Services

Writings

Tools

Agile Testing

[an error occurred while processing this directive]