Product Management

7 signs to identify early-adopters and innovators

Thursday, July 11th, 2013

In crossing the chasm, Geoffrey Moore paints a very clear picture of innovators and early-adopters for the technology world.

The Innovators

Crossing the Chasm by Geoffrey Moore

As per him, Innovators pursue new technology products aggressively. They are usually the nerds, the techies, the ‘sufferable’ know-it-alls! They own the latest gadgets and they spend their time reading and writing about the latest & the greatest in the tech world! They are conversant about the underlying technologies and can speak to you about the pros and cons of each one of them (Jelly-bean Vs Ice-Cream Sandwich).

The Early Adopters

The early adopters, as per him, are just as much of an enthusiasts! They are, however less techy but more business / functional opportunity driven. They are not interested in whether its Jelly Bean or ICS; they are more interested in the significant value-add / competitive-edge derivable from this tool. How it would change the world or at-least part of the world!

Billy Beane (played by Brad Pitt) in Moneyball, would be a classic example of early adopter! Saito in Inception could be another!


So how do we identify them? How can we distinguish them from everyone else in the crowd. Here are 7 empirically defined signs that I collated from experiences (mine and other entrepreneurs).

1. They want to hold your product in their hands, experience it, play with it

Shortly after launching the Yavvy iPhone & Android Apps, I used to go about showing it to prospective clients. There have been instances where some of them simply took the phone from my hand and started playing with the app. On other occasions, they almost immediately downloaded the app from the App store. If I look back upon those who did, almost all of those who pulled it out of my hand and started playing with the device were early adopters. They also became our first few customers.


2. They call back

I used to meet a lot of people and tell them about Yavvy. I still do. At a random meeting, at a conference. Most people listen, most also provide advice. Most of those interactions end right there.

The innovators, early adopters usually come back to you. There have been those who have come back to me weeks later, some even months later. But they remembered and they called back to explore. They wanted to know if it could do something specific, if it could help their friends.


3. They own the latest gadgets (This is a myth)

Most blogs and even Moore’s example states this. Unfortunately, no. of gadgets owned is just a bad yardstick to judge early adopters. Some really amazing innovators I met did not own a smartphone! Infact some of our early customers came to us with a very well defined need (manage billing and invoicing from multiple locations). Most of them had no gadgets. Infact quite a few of them were from rural areas! They were just early adopters in their own market.

On the other hand, I’ve met such a huge number of “Bankers” who move around with the most cutting edge gadgets and yet, have no idea, nor orientation towards adopting technology.


4.  They are interested, they listen, they participate (in shaping the product)

Once an early adopter decides to invest (could be time or effort or money) in your solution or offering, they usually take significant interest in shaping it. This shows up in their feedback, which is usually more insightful. Even during conversations, they give you time and listen. They participate.

There is a sense of excitement in them, when they talk about your product. Here is a quick snippet about the feedback which our early adopters gave us.


5. They have purpose (to use your product)

7 signs to identify early-adopters

Honestly, if I were to picture it, my friends and family would qualify on the above-mentioned criteria. They do participate, they do come back, they do experience the product and give me feedback.

Yet, none of them is an early adopter. Unless they have a purpose or a very well defined use-case for my product, they will not qualify as early adopters. Unless they have felt the problem that I am trying to solve, they would not qualify as early adopters


6. They don’t get stuck up on references

“Do you have another similar company using this product? In our city?”. Early adopters are able to see beyond this question. They are okay, if the answer is no. Infact, if you have too many references, that might actually be a put-off for them!


7. They don’t need handholding (or very little handholding)

As per Moore, the big difference between early majority and late majority is that they early majority is technically capable of using your product. They can work out most parts without you hand-holding them. Early adopters similarly have the technical and functional bent-of-mind to use your product.

Don’t confuse this with feature discovery. That’s a usability aspect of your product. And if your product is bad at it, you’d just have your user come back to you with questions about how to do this and why doesn’t it do that!


Its a tough job finding great innovators and early adopters to help you shape your product. Tough, but unavoidable. Can you leap-frog to the early majority or late majority directly? That’s a question we’d discuss in another post . “How important are early adopters to the success of your venture”


The three stages of testing a product

Saturday, August 18th, 2012

Here at Yavvy, we build and test our features in three phases.

-       The first stage comprises of ensuring functional accuracy,

-       The next stage focuses on usability and

-       The third stage test for integration aspects of the feature.

The functional accuracy determines if your product will sell or not, usability determines whether it will scale or not, and integration determines whether it’ll be replaced or not.

Functional Accuracy

What if Gmail sent half the emails to incorrect addresses? What if Spreadsheets added the figures wrong? Functional accuracy is the foundation of your application without which you can’t release the product at all.

When we built the order-to-invoice functionality, in the first phase of testing we focused entirely on the functional accuracy. Are all the items getting copied accurately? Are the item quantities correct (remaining quantities on an order rather than ordered quantity)? Are the prices getting transferred? Are the terms (credit days) accurately transferred?

Is it Usable

When we had that checked, we released it selectively to validate if it’s usable. For example, how should we let the user know when that vendor sends larger quantities than ordered. How should we navigate because for sales orders, you go from Order to Invoice, but in case of Purchase Orders, you largely go from invoice to order. Where should you be directed when you have created the invoice – to the order or to the invoice details?

Is it Integrated

Can your solution fit into the larger picture? If it can’t it’ll be replaced with something that can. Once we have established functional accuracy and usability, the next thing we concentrate on is how do we integrate this with upstream and downstream activities.

After we built order management and sales opportunity management, we integrated both these features. When we launched expense management, we integrated that into the CRM. When we created KPIs, we built in ways through which whenever a sales-guy closes a sale, it automatically reflects against his booked orders.

The order of the Test driven design

At the design stage, we try and consider all three aspects. Before we build a feature, we define its functional, usability and integration aspects, some more than the other.

But the execution definitely phases out. The phases are actually a little iterative with percentage focus changing in each phase. In the first phase you would look at 70% functional, 25% usability, in the second phase, it’ll be 70% usability and 20% functional. Integration usually kicks in much later, sometime in a distant release.

And if you get confused about when to concentrate on which aspect, you would automatically understand this from the nature of bugs. Functional bugs, usability bugs or no bugs (just requests and queries)!


The most important takeout is that building a product actually requires you to solve three sets of problems. I have seen so many applications, from the biggest corporations of the world solving just the functional aspect and believing it to be a product. Next time you plan to build a feature in your product, remember to solve all three problems.