The primary customer in API Economy is application developer. They work with your APIs often daily. The manager behind developers is your moneybag or resource gatekeeper. Please the developers first, but don’t forget that money makes the world go round. Win the hearts of the developers and money will follow. In this post you’ll learn that developers are not all alike and why segmenting is important. Fluent and intuitive API keeps the application developer in the flow.

Typical developer

Since the blog series is about Developer eXperience, I need somehow understand what kind of people developers are. Drawing a picture of (stereo)typical developer as your API consumer helps you understand the customer. Keep in mind that typical developer described here is not your target group. Instead you’ll understand something about the mindset, expectations and values of your customers.

Eat and breathe code

Stack overflow has created nice report of the platform users. Not all developers use (at least not by leaving traces) Stack Overflow or answer surveys. Nevertheless, you can learn a lot about developers by looking at what kind of user is the typical Stack Overflow user.

Stack Overflow survey 2018 caught the attention of over 100 000 consumers, out of which almost 60% identified as back-end developers, and about 20% considered themselves mobile developers.

Continuous learning

Another interesting high-volume developer survey is Hackerrank from 2018. Data was collected 2017 and can thus be considered as relatively new. According to Hackerrank 1 in 4 developers started coding before they turn 16 years old. Hackerranks results support the Stack Overflow results regarding continuous learning.

The number one thing that developers want most above all is a strong work-life balance (for example flexible hours, remote working). Professional growth and learning is the second most important while compensation is the third. To me this can be translated to “developers are cleverly lazy bastards”, do what you are expected to do, but do it wisely.

Now that you have a solid understanding of the developers and their motivations and how they learn, you can start constructing ideas how to use developers (aka 3rd party API consumers) in your quest for top of the world API.

Co-create with external developers

Since your company is developing APIs, you must have developers (paid staff or hired guns). Top of the industry APIs are not build internally, but in close cooperation with external developers (customers). Lets have a look at how the 3rd party developers can be segmented and how developers in the segments should be used in your API development.

Some of the developers are more prone towards innovations and bleeding edge solutions. These developers can be labeled under “Innovators”. Rest of the segments are: early adopters, early mass, late mass and laggards.

The first two segments on the left contains customers seeking for the newest things. Early adopters settle with minimum feature set and even accept incomplete or defective products just for the pleasure of being the first ones to use this new product. Two segments in the middle contains customers who seek comple solution and convenience. Early majority is not happy with minimal features, but expects whole product solution. They are also called pragmatic, who buy new products only after they got references. Late majority are the conservatives, in other words, those who buy only after the price has dropped substantially. Laggards is the segment who most likely never become customers or at least will require extremely long adaptation curve.

Target is in the middle

Thus your target segments for finalized API product is in the middle. The productizement needed to get there (and make money) requires working with the innovators and early adopters. They will help you cross the chasm.


Innovators live in the future. Discussions with them is occasionally like a scene from Back to the Future. Or like Star Trek, since they are exploring or sometimes creating the unknown territory. They can help you identify possible rising trends and technologies. These developers often build all their tools since there aren’t any available.

Early adopters

Early adopters are familiar with product thinking. They are forgiving eg if your API lacks some features, the documentation is not fluent yet or the behaviour of your API is shaky or unstable. Early adopters know what your API should be to be labelled as product. Usually, they are influencers within organizations and communities in which they participate. They can be used to test your API and the developer experience. Note that early adopters are normally not from inside your company. Even if they are own staff, they should not be involved in the development nor the systems it relies on. In other words, they should not know anything about the API. If they do, they are not free of the cognitive dissonance that hampers developers when testing their own APIs. They help you to cross the Moore’s chasm.


The segments discussed above can also be mapped to famous S-curve. This S-curve can be broken in three stages: the slow beginning, which is the innovation stage; later comes the growth stage, when early majority and late majority adopt the product; and, lastly, the maturity stage, in which the product have already conquered practically the whole market. The last stage of any product is end of life, a moment in time when product is taken out of the market, sales ends or it is replaced with an alternative solution. Most startups which fail and do not cross the chasm, take a shortcut from innovation to end of life.

Now what?

When you start to think about your product’s customer (developer) it’s hardly ever like the above. Your target developer is most likely something a bit different. It’s most likely more of a niche and scope is more narrow. You should first satisfy the needs of your primary customers and after that you can aim for the broader scope (above).

Some more to read from 100 Days DX