More and more, I’m convinced there are two islands where new products are successful: They are either small incremental improvements over the status quo, or massive disruptive changes that represent an entirely new invention. The area in the middle is filled with failures. I think the reason has to do with how the human brain works and adapts to new ideas.
Small changes to something familiar are easy to assimilate. So much is familiar and feels comfortable. Those few small things represent a minimal change, and our minds can concentrate on those changes while still being productive doing familiar tasks in familiar ways. There are many examples of successful software products that have followed this model: SVN felt familiar to CVS users. Google Chrome feels familiar to Firefox or IE users. C# felt familiar to C++ and Java developers. Going back further, C++ felt familiar to C developers.
At the other end of the scale are those products that feel so different that the make you learn totally different workflows. You may be accomplishing the same goal, but the process is so different, you’re forced to adapt and change everything. The iPhone redefined the smart phone market. The word processor introduced totally different workflows from the typewriter. Google maps and Bing maps have completely different workflows from paper maps. Windows 8 promises a completely different shell than Windows 7.
Describe your product the right way
It’s only half the battle to understand that your customers are more comfortable farther from the middle in this continuum of familiarity and disruption. It’s just as important to market and sell your products in such a way that you push your users to expect either familiarity or newness.
Remember Steve Jobs’ introduction of the iPhone: “The phone will never be the same.” He set customer expectations that this was a disruptive product. At the other end of the spectrum, C# was introduced as a component – oriented language that would be familiar to C++ and Java developers. Microsoft understands this in how they market Windows: Windows 7 was described as familiar to Vista users, with higher quality and a few new features. Windows 8 is being described as revolutionary. They are setting expectations about how people should react and adapt to the new features.
Successful products can make changes in their design and their marketing to pull user expectations in one direction or the other. Early digital phone systems included weights in the handsets. That’s because the analog equipment had iron cores in both the speakers and the microphones. They felt heavy. Early digital phones were marketed to be familiar to analog phone users. Yet, they felt too light and were thought ‘cheap’ by early adopters. Adding weight made them feel substantial. And, that was consistent with how they were described. Later, digital device manufacturers highlighted the differences, including the (lack of) weight as a differentiator. That set expectations differently for the customers.
Success in the Middle is harder
The products and innovations that are closer to the middle have a more difficult road to adoption. I’ll mention a couple examples.
Distributed Version Control (DVCS) systems have a quandary. They are quite different from a central VCS. And yet, the commands and the workflow feel similar. This tends to introduce confusion for users. So much experience will tell them that using DVCS is “just like” using whatever VCS system they are already using. And yet, the workflow really is different: push and pull don’t have any analog in a central VCS. Two new commands aren’t enough for most people to appreciate how different DVCS is from traditional VCS. This introduces confusion and frustration.
Programming languages, like Scala or C# 4 have the same problem. Scala is often presented as being easy to adopt for Java developers. C# has been presented as being easy for C++ and Java developers. As I mentioned earlier, it helped C# adoption that earlier versions of the language were very similar to familiar curly-brace languages. But, idiomatic C# 4.0 is quite different from either C++ or Java: Lambdas, query expressions, dynamic typing, covariant and contravariant generics, partial methods and partial classes. Those concepts are not small tweaks from other curly brace languages. I think it would be a mistake to teach developers C# by showing them a feature by feature comparison with Java or C++ in 2011. It’s better to teach them idiomatic C# 4 as a new and disruptive concept that just happens to have similar syntax.
Similarly, Scala is approachable to Java developers. But, idiomatic Scala is quite different than idiomatic Java. It would be a mistake to take developers on a feature-by-feature comparison of Java and Scala.That will cause new developers false expectations. Better to teach it as new, and point to the occasional familiar construct.
Enough Rambling. Do you have a point?
I actually have 2 points. First, when you are learning something new, decide if you should treat it like something familiar, with a few changes or something totally new that solves a similar problem. You’ll have a better frame of reference to tackle whatever new concepts you have if you’ve made that decision.
Secondly, if you are introducing new products or technology, decide how to present it: Is it something new, or something familiar? Guide new users to the best way for them to learn the concepts.