Let’s just face it - early adopters of any technology are going to be technical people themselves; they’re going to be engineers, enthusiasts, hobbyists, or something else. Early adopters are a blessing for small companies, like the one I work for, because they are willing to take the risk of trying out your product without a lot of prodding. On top of that, if early adopters like your product, they’re generally very vocal about it and provide invaluable word-of-mouth press.

Early adopters are also very vocal when it comes to product feedback; they are never short on suggestions to help you make your product “better.”

Conventional wisdom from TechCrunch, Scoble, or any other big name startup profiler is to treat your early adopters like enlightened sages, to understand that the synergy of their various experiences, their passions, and your company will take your technology across Geoffrey Moore’s chasm.

I don’t question the notion that a technology needs early adopters in order to eventually cross the chasm, that the manufacturer needs the evangelism of passionate early adopters to help get just enough momentum to start attracting mainstream consumers.

But there is one major issue that I take with the sacred value of early adopters: the recommendations of early adopters for your product’s technology can almost certainly prevent you from crossing the chasm, and I’ll explain why.

An Anecdote

Over at the blog that I run for my employer, I published a screencast which demonstrated an important feature in our software. The subject matter of the screencast was crucial; it demonstrated a feature unique to our product that every single one of our users needs to know. However, the feature itself is simple to the point of being trivial - it’s a single button that eliminates what used to be a ton of work. In short, I published a screencast that showed our customers how to click on one button; seems pretty obvious, but what’s the #1 rule of UI design? Nothing is obvious enough.

Anyway, the screencast was incredibly well received; by the numbers it was the most popular screencast that we’ve ever published. However, it was also the first screencast to receive a strikingly negative comment from one of our own customers.

This customer, someone with obvious technological expertise, was angry that we’d waste his time trying to show him how to do something so simple and, to him, unimportant. “Why don’t you show me how to do something tricky with your software, like how all of the Excel and PowerPoint tutorials do!?”

I explained my reasoning behind producing such a trivial screencast, which is that many of our users don’t know about the feature (it can be easy to miss) and they find that spending one minute learning how to use it and how it works is well worth it. What’s “painfully obvious” to many early adopters can be valuable to many mainstream users.

Later I had a discussion with the User Experience Manager for our product about the fine line that we have to walk on; this “fine line” boils down to balancing two equally important concerns:

• Do we keep the product simple for first time users and infrequent users (mainstream users)
• or do we allow for more features, more customization, and more content for advanced users (early adopters) at the expense of the a steeper learning curve for mainstream users?

The answer to this question is the life or death of the company I work for.

A Reality Check - Your Most Valuable Customers Might Be the Least Vocal

During my conversation with the User Experience Manager he mentioned a passage from Bill Buxton’s Sketching User Experiences, which said the following:

Your most vocal users will come from the two fringes of the technical expertise curve: your expert users will complain that they don’t have enough control over their experience and that they want more fine-grain control over what they can and cannot do; at the exact same time, your users with the least technical expertise will complain that your program is too hard to use!

So which is it? You have tons of people telling you that your product is too simplistic and too complicated at the same time! Who’s right and who’s wrong?

The answer? Both of them may have good suggestions from either end of the adoption spectrum, but often times both groups are wrong.

How Early Adopters Can Steer Companies in the Wrong Direction

Laggards aren’t pursued heavily by most tech companies, JitterBug being a notable exception, simply because the cost of marketing a new technology to them outweighs the benefit. A laggard also costs more to support and they are always the first to complain that “your product is too hard to use.” Generally speaking, laggards are considered the “most expensive” kind of customer to acquire.

Early adopters, on the other hand, are considered to be “ideal” target customers:

• they are intuitive and can solve most tech problems themselves,
• they are instrumental in building communities around products and technology,
• they spread the word to other potential customers, and
• they all have ideas to help make your product better.

However, the question that needs to be asked more often is: early adopters want to make your product better for whom?

Technical people, like early adopters, will rarely push a product towards simplicity; they will push your product towards open standards, towards interoperability, towards new features, towards increased efficiency, but hardly ever do they push it towards increased usability for the masses.

Oh, don’t worry, all of the input from your early adopters will make your product more “usable,” for other geeks maybe, but how does it affect the other customers you need to cross the chasm, the early and late majority?

Truthfully, the input of many early adopters can actually prevent your products from being adopted by the majority and can drive your company to invest time and money into the wrong features.

Here’s how early adopters can lead companies astray:

• They push towards over-engineering - Early adopters get hung up on the details, sometimes to a fault. Issues like execution speed, file size, memory usage, and so forth are issues that come to mind; if your product takes forever to run or it has problems with runaway resource consumption then yes, your early adopters are right to tell you that you need to improve your technology in those areas. However, if you have a relatively stable product with speeds that are more than reasonable in the eyes of average consumers, your early adopters will still tell you that you need to spend more time optimizing this and that in order to use less memory, disk space, CPU power, bandwidth, etc… At some point it becomes compulsive engineering for the sake of engineering aesthetics, not engineering for the sake of increasing value for the average user.
• They push towards feature bloat - Microsoft haters constantly whine about the “feature bloat” of Microsoft Office, which is ironic given that they’re the same people who are responsible for feature bloat in the first place. They want new features for the sake of automating complicated, yet obscure tasks, features that will only be used by a tiny fraction of the entire user base. These features have to go somewhere in the interface and each additional feature adds some increase in the overall complexity of your program.
• They push towards increased control - The biggest problem with some of the product suggestions by early adopters is that many of them ask for increased user control over aspects of a technology; product developers put barriers  in place intentionally to prevent average users from digging themselves into holes. For instance, you’d want to lock the toolbars on a piece of software by default just to prevent users from accidentally trashing their interface and being unable to restore it. Many developers refer to this disdainfully as “baby-proofing” software, but it’s a necessary evil. Your early adopters are often the same sort of people who decry the act of “baby-proofing” software; they want more control and they want more access. However, each increase in control that you hand over to the users also increases the total number of pits that the average user can fall into. Increased control can be good for technical users, but it can be just another empirical example of Murphy’s Law for the majority of your technology’s adopters.

The Majority of Your Users are Silent

The point I’ve been alluding to is the fact that the majority of your product’s adopters is the silent majority; user feedback is always a blessing when it comes to product design, but never forget the needs of your core users. The users who scream the loudest usually aren’t representative of the majority. Early adopters are great, but their suggestions might actually make your product less likely to be adopted; after all, it’s that silent majority who has the most say when it comes to crossing that chasm.

If you enjoyed this post, make sure you subscribe to my RSS feed!