I’ve been known to read a book or two on management or marketing now and then. I know it’s a personality flaw on my part. I should be reading books on agile development processes or the latest new language like Ruby on Rails. But the fact is most high technologies have a half-life of about five years. When you get to be a certain age, and have survived a thirty-year career in high tech, you have seen so many technologies come and go it’s hard to get excited about something that in the long view seems like just another fad. Plus, you figure maybe it’s a good idea to practice
just-in-time learning instead of expending bandwidth with stuff that you might not live long enough to use. Time is short, and you want to make the most of what you have left.
Even while reading a book on marketing, it is hard not to see it through a lens polished by decades of technical experience. And so it is that when I read Paul Smethers’ and Alastair France’s book
Five Myths of Consumer Behavior: Create Technology Products Consumers Will Love, I chose to see it not as a book on how to design and market consumer-friendly products, but as a book on API design, and to see the consumers described in the book as other software developers using my code.
Is that sick, or what?
I’m sure if I specialized in user-interface design, such as GUIs or web pages, this short book would have even more resonance, since it talks specifically about the design of human interfaces for cell phones and web pages, based on work by the authors. But I found much of value just from my own experience developing real-time and embedded software for use by other developers.
Myth 1: Consumers behave the same in all marketsFive Myths describes the
Consumer Adoption S-Curve, which is a sigmoid curve passing through the phases
stalled adoption, to
rapid adoption, to
mass adoption over time. The first consumers who use your product will do so because they are curious, seek innovation, or have a problem they think your product can solve. As we will see later, only a fraction of those initial users become repeat users, only a fraction of those become regular users, and only a fraction of those become power users who may come to know more about using your product than its developers. If the barriers to entry to using your product are too high, you will weed all of your users out at the first stage, and your product will become stalled in the first (low) part of the sigmoid curve. The key to wide spread adoption is lowering the barriers to entry. Barriers to entry include usability, performance, and a product value that is hard to find.
I'm sure many readers have recognized this as being very similar to the cumulative
Innovation Adoption Curve described by Everett Rogers in his book
Diffusion of Innovations. Rogers separates his sigmoid curve into the phases
innovators,
early adopters,
early majority,
late majority, and
laggards. While Smethers and France concentrate on talking about mass-market consumer products like web pages and cell phones, Rogers talks about how innovations ranging from new agricultural technology to rap music spread through a culture. The similarity of these two concepts suggests to me that both books are talking about the same thing, and that it is something fundamental.
Five Myths offers examples where consumers in different markets, for example Europe versus Japan, behave very differently in terms of what they find interesting or acceptable, making the same product or feature move through the sigmoid curve much more quickly in one market than in another. Success in Japan does not guarantee success in Europe when marketing the same product or feature.
A good example of this is to compare developers of enterprise software to those of embedded software. The success of Java in the enterprise was possible because that domain’s developers found the overhead of the JVM and its garbage collector vastly out weighed by its many advantages. Embedded developers just smiled and shook their heads. Historically this was also true about C++, and lately with its more exotic features like generic programming.
I have argued in recent articles that it is time for Java (“
If Java is the new COBOL, is C++ the new assembly?”) and generic programming (“
Generic Embedded Programming Using Templates”) to take their place on the embedded developer’s tool belt. But it is wise to remember that as technologies become mainstream, they filter though problem domains ranging from innovative to conservative, just as
Five Myths describes.
Want to get a clue what embedded developers will be doing and using a few years from now? Look at what enterprise developers are doing and using today.
Myth 2: The more consumers see it, the more successful it will beThe biggest marketing effort in the world can’t make up for an ugly product. The secret isn’t attracting users. It’s keeping users. Marketing might get potential users to become initial users, but they won’t stick with an ugly product to become regular users. Products can be ugly (my term,
Five Myths would probably say "unattractive") for lots of reason, like poor performance, poor usability, or value that is too hard to find.
Five Myths has a pretty interesting discussion on how products abandon their core consumers. Marketing managers insist on adding more and more features in an effort to broaden the product’s appeal. It evolves over time to the point where much of its installed user base can no longer find value in the product.
(A good metaphor for this effect can be found in popular entertainment. I was a fan of the television series
Twin Peaks until I figured out that David Lynch was just making it all up as he went along and there was no hidden context. The series was cancelled shortly afterwards.
The X Files came perilously close to this with its meandering mythology based on a government/extraterrestrial conspiracy. But it sustained enough great episodes that it remained worth watching. And of course there was the UNblonde character.)
I remember installing one of the popular Linux distributions, Ubuntu, on one of Digital Aggregates’ servers, only to discover that it did not include a C compiler. Apparently the folks that packaged this particular Ubuntu, which is marketed as “
Linux for human beings”, was not marketing it to developers. (From this we can infer that developers are not human beings, something my spousal unit has wondered aloud about from time to time.) It was easy enough to download the GNU package and installed it, but it was definitely a WTF moment for Mr. Overclock.
While I know folks that are successfully using Linux as their desktops (and I still run it experimentally on an old laptop), all of those folks are hard core technologists, definitely not part of the mainstream. My laptop runs Windows, not because I am a Microsoft fan, but because I simply don’t have the time (see first paragraph) to figure out how to do with Linux things that are relatively simple with the applications available for Windows. And before you start commenting on how Mac OS is UNIX-based, recall that it is not Linux-based (and you will have to pry the Powerbook running Mac OS X from my non-technologist spousal unit’s cold dead fingers).
I have seen the same happen to products in the embedded tool chain, such as real-time operating systems. Victims of their own success, they become so feature-rich that one of two things happens. They can no longer be used by their core constituency for their traditionally memory-constrained applications, or they require so much memory that alternatives that were formerly unthinkable, like Linux, suddenly become competitive.
While I can appreciate the marketers trying to broaden the appeal of a product successful in narrow market segment, this can be the death knell if the product loses sight of its core value, the problem it was originally trying to solve.
Myth 3: If I’ll use it, my users willOn one hand, the points that
Five Myths makes seem almost too simple and obvious. On the other, they are contrary to many truths that my technologist brain holds to be self-evident. This is one of the points of the book: engineers are power users of their own products, and are therefore the
least qualified to have an opinion on how to make a product attractive to a new user.
It is difficult, for me anyway, to try to view the APIs that I design from the point of view of someone approaching it for the first time. Yet that is exactly what I think you need to do: try to see it with new eyes. And be willing, eager even, to evolve it once you have some real developers using it and getting their feedback. Don’t be afraid to say “this was a stupid idea” and move on. If it really is a stupid idea, why would you want to keep it around? Maybe it’s just stupid in the current context. So keep it in your hip pocket for when you find a context in which it is a brilliant idea. But don’t force it on your customers.
I’ve become skeptical over the years of design reviews that do not incorporate some kind of actual use of the API as part of its evaluation. The most useful technique I have found that did not require running code was to at least code up the interfaces or header files defining the API, with no executable code behind them, and code up some example programs using them to see how it feels. Even without any executable code, I was surprised how many problems this technique shook out. Plus, if you comment the interfaces with JavaDoc or Doxygen, the result is the beginnings of a usable (and current) design document.
Of course this sounds an awful lot like some of the precepts of agile development, like
working closely with the customer, and
test driven development, and so it is. I find a lot of API issues while writing the unit tests. These problems range from “this isn’t pretty”, to “this is awkward” to “this doesn’t work at all”.
Myth 4: Consumers will find a product’s valueFive Myths says you have to make your product's value obvious right up front, and make it easy for consumers to find it. Using web pages for mobile devices as an example, you lose customers with every single mouse click and menu drop-down they have to go through to use the feature they really want to use. With every step consumers have to take, a proportion of them give up and spend their attention budget elsewhere. Place enough barriers to entry in their way, and they give up, weeded out before they ever figured how why they should care.
So it is with APIs. On a Java project I remember comparing JAX-B with XMLBeans as tools to convert between Java objects and XML. I didn’t particularly like either one of them, but for sure the one I liked the least was the one that seemed to take more work to get something usable.
Five Myths is the latest among books I’ve been reading that push an
evidence-based approach: evidence-based medicine, evidence-based management, and now evidence-based marketing. It’s easy to be lulled into thinking that evidence-based marketing is the norm, what with all the talk about focus groups and consumer surveys. But
Five Myths tells us about how most such approaches are deeply flawed, and frequently only serve to reinforce mistakenly held beliefs by the product developers and their market managers.
Five Myths suggests an approach I recall reading as having been used by the early Intuit developers: give your product to real customers, follow them home, and watch them while they use it. The most useful feedback I’ve ever gotten on how difficult most systems are to use is when I watched over the shoulder of an actual customer as they tried to use it. The second most useful is when I tried to do the same while an irate customer was standing over
my shoulder. This is why I strongly recommend that developers interact directly with customers. And not just in the customer briefing center either, which is a restrained and carefully controlled environment, but at the customer site, where the products are being used. I guarantee that it will be a valuable learning experience, albeit perhaps a painful one for all involved. (You might even make a friend or two.)
I’ve come to think of this as
evidence-based design. Design based on facts and measurements, not on what you think is right. Agile proponents will recognize this as a form of
don’t build it until you need it and
incorporate the customer into the development process.
Myth 5: Consumers want more featuresConsumers do not want more features. More features only confuse them and serve to hide the value (if any) in your product. When it comes to features,
less is more. It is better to have a few (maybe as few as one) key features that work well, than a lot of features that all work marginally. This contrasts sharply with the
boil the ocean approach of many modern software products.
Five Myths classifies features as to their
attractiveness, their
stickiness, and their
usage. Attraction is the ability of the feature to attract consumers to use it. Stickiness is the ability of the feature to attract repeat users. Usage is the ability of the feature to engage a customer over a period of time. The most successful features are those that have high measures of all three metrics. But a feature that is just attractive, like a built-in MP3 player, may encourage potential users to become initial users, where they discover a sticky feature, like text messaging, that keeps them coming back. A high usage feature, like cellular phone calls billed by the minute, increases revenue.
This plea for simplicity describes well the problems I have with many software tools, frameworks, and APIs. They are just too damn complicated. It takes too long to come up to speed on them (see first paragraph) and to ferret out the best practices for using them, when all I really want to do is make my dates, ship a product, and book revenue. (All good things come from booking revenue.)
And many software products seem to be designed by a committee, having every single imaginable bell or whistle, with a cumbersome API that tries to be all things to all people. The POSIX Threads API comes to mind. Of course, like many public standards, it
was designed by a committee, and
does try to be all things to all people. It is no accident that the original, simple UNIX API was the product of just a couple of guys sitting around in the lab. Popular new tools, like Ruby on Rails, are frequently the product of just one or two people trying to address their own issues and coming up with a particularly effective solution.
My own experience has caused me to re-think how I design APIs for the software that I write, and
Five Myths just reinforces it. In particular it has changed how I design something as mundane as constructors. In recent work in both the Desperado C++ library and the Buckaroo Java library, I have started putting only the absolutely essential arguments in the constructors, and setting all other options via dependency injection using settors which return an object reference.
For example, Buckaroo features “
Chip’s Instant Managed Beans, classes which vastly simplify exposing useful information as MBeans to remote JMX browsers like JConsole. (For those of you in the C++ world, this is akin to exposing MIBs to remote SNMP browsers, which can be a very good thing indeed for system monitoring and field troubleshooting.) The constructor of the Buckaroo Counters class takes one mandatory argument, an enumeration, creates an array of counters for use by the application which are indexed by that enumeration, and exposes that array as a Dynamic MBean via JMX. It makes exposing debugging counters and even simple controls absolutely trivial.
Of course, there are some optional parameters for this capability, like the name of the managed bean, the location of the mbean server, a logger to use for error messages, and a callback that tells you when a counter has been changed remotely. But there are usable defaults for all that stuff. Instead of cluttering up the class with a bunch of polymorphic constructors, Counters has settors for those options. And since each settor returns a reference to the Counters object, you can write your application code as simply as this
enum Fault {
FAULT_INVALID_CONTEXT,
FAULT_OUT_OF_SPEC,
FAULT_INVALID_CHECKSUM,
FAULT_ SEQUENCE_NUMBER
};
Counters fault = new Counters(Fault.class);
or as complex as this
enum Fault {
FAULT_INVALID_CONTEXT,
FAULT_OUT_OF_SPEC,
FAULT_INVALID_CHECKSUM,
FAULT_ SEQUENCE_NUMBER
};
Counters fault = new Counters(Fault.class)
.setCallBack(myCallBack)
.setMBeanServer(myMBeanServer)
.setMBeanName(myMBeanName)
.setLogger(myLogger);
I know this sounds like a mundane example, but I think that not only does this simple constructor design lowers the cognitive cost of entry for using this class, the fact that you don’t really have to know what an MBean server or an MBean name is in order to make effective use of it makes the value more obvious.
This isn’t a new pattern, and I certainly didn’t invent it. But I’ve recently warmed to it, and
Five Myths just convinces me that this is the right way to go.
Five Myths preaches simple usage, and if you absolutely must have options for the power user, hide them and provide usable defaults.
The Rapid Consumer Adoption ProcessFive Myths defines the
Rapid Consumer Adoption Process. It goes like this:
Design Product,
Implement Design, then iterate in the cycle
Deploy Product,
Analyze Product,
Improve Product, until golden, brown and delicious. Developers will recognize this as just a form of iterative development. But this cyclic process is more controversial than you might think, and getting more so all the time.
As competition gets worse, budgets get tight, and companies are under more pressure to improving the bottom line while shortening the time to market, the fact that all product development is
fractally iterative sometimes get lost. I remember ten years ago working on one product for as many as six release cycles, or about three years. In the past few years, the norm is more like two or even one release cycle before I’m pulled off and put on the next crash priority project.
This is not good. It’s not that products were shipped too soon, but that after they were shipped there was no budget to keep developers around to improve the product. I felt like I was shipping nothing but prototypes. Customers felt it too: many complaints were heard about slippage in quality. But the first release of those later products weren’t any worse than the earlier ones. In fact, thanks to improved tools and better processes like test driven development, they were often better. But they never got much better than that first release, and it was really this lack of maturing, I think, that the customers were complaining about.
Every time I complain about quality, I feel especially old and cranky. I remember when I had to hike three miles to the computer center, carrying a box of punch cards, through a foot of snow, uphill both ways. The fact is programming languages, development tool chains, and processes have vastly improved since I started my career in the 1970s. There is no way I would want to go back. But
Five Myths is just another voice telling me there is still plenty of room to move forward.
SourcesPaul Allen Smethers, Alastair France,
Five Myths of Consumer Behavior: Create Technology Products Consumers Will Love, ConsumerEase Publishing, 2007
Everett Rogers,
Diffusion of Innovations, Simon & Schuster, 1962
Chip Overclock, “
Generic Embedded Programming Using Templates”, January 2007
Chip Overclock, “
If Java is the new COBOL, is C++ the new assembly?”, January 2007
Chip Overclock, “
Uncle Chip's Instant Managed Beans”, December 2006
Buckaroo, Digital Aggregates Corp., 2007
Desperado, Digital Aggregates Corp., 2007
