Transcript:
Presented by Christina Voskoglou
Introduction
Today we will be discussing segmentation, but before we do so, let me introduce who we are and what we do so that you can get an idea where the insights I will be sharing today come from. We are SlashData, we help the world understand developers. In particular, we help companies who target developers understand their audiences. The three key areas in which we provide such help has to do with who developers are. And this is where segmentation, that we'll be discussing today fits in.
Who they are, how many there are across the globe. Then second, what they buy. What technologies, what tools they adopt, why they adopt them, and how happy they are with their choices. Last, but not least, where developers are going. Which means what emerging trends, seem interesting to them, which they consider as being interesting, as promising. How do we do that?
Well, before that: our clients who trust us with this kind of research are the top guys in the tech industry. Here's just a small sample of them. And here's what we do. We run developer surveys twice per year. We cover eight developer audiences, so eight development areas if you prefer: Mobile, Desktop, IoT, Backend, Web, Games, AR/VR, Machine Learning and Data Science. So we have roughly 20,000 developers in each wave, which is about 40,000 annually because there's a little overlap between surveys. We have run 16 such surveys to date and we're actually about to launch the 17th one in a couple of days. We reach developers in more than 160 countries, each time, and we do that through a network of more than 70 partners and channels, across the globe. They're not necessarily the same guys every time. From small local meetups to big forums and communities, vendor and non-vendor alike, we make sure we reach developers wherever they are. Based on all this data, we produce more than 40 research studies per year. Now, just to give you an idea of the spread of our sample, this was our latest survey. It was the 16th wave, which ran between November 18 and February 19, we reached more than 19,000 developers this time, from 165 countries, not all 165 could fit on the slide, only a small sample of them shown here. Just some numbers there to give you an idea of the spread of our sample across regions. So it's not a single community that we cover, not a single geography. It's across the globe and across communities.
Segmentation
With that out of the way, let's get into segmentation. This what we will be discussing today. First of all, we're gonna look into how developer marketing and DevRel practitioners actually segment their developer audience. Then we'll discuss some basics of segmentation - key principles. Third, I'm going to touch on just some of the key drawbacks of popular segmentation practices out there and why these are a really bad idea in the end. Then, I'm going to discuss our data-based approach and then why and how you should customize your approach for your developer audience. Finally, we'll be addressing any questions you may have.
On top of our developer surveys, we also run a survey that we call Developer Program Leaders survey. In that, we ask developer marketing practitioners questions about their experiences. One of those had to do with how they segment their audience. We had 52 responding last time and I was very happy to see that the vast majority, 92% of them, actually do segment their developer audience. I'm not sure what the other 8% are doing. The question then is how they segment their audience - those that actually do. You can see that the most popular practices have to do with app categories, industries, geography of course. Towards the middle of the list here you find technology considerations: devices, platforms, programming languages, type of development. While things that are inherent features of the developers such as, age, experience, education, so on are towards the bottom, the question is: is that a good idea? Now, to answer that question, we must consider "what is a good idea?". In other words, "what should a good segmentation look like?".
These are what I like to call the four pillars of segmentation. Ιn geek language, segments should be homogeneous within. In normal language, that means that members within the same segment should be as similar as possible to each other. "Similar with respect to what?" You may ask, and that is a very good question. Please hold on to it. We'll get there. Why do you want members within the same segment to be similar? Well, because you want them to react, to respond similarly, given an incentive, a campaign message, right? You need to know how they are expected to respond so that you can maximize response to your campaigns. Secondly, segments need to be heterogeneous between, or in other words / in simpler terms they should be as dissimilar as possible.
So, two developers belonging in two different segments should be as far apart as they can get, again back to this magic set of features we will be discussing. Thirdly, and very related to the other two, segments should be what we called "MEE: Mutually exhaustive and exclusive". Exclusive, meaning they do not overlap, so no overlapping segments. Why? Because you want each developer belonging in just one single segment. So you know what campaign, what offering to use to reach out to them. You want your segments, if you put them all together, to be exhaustive, to cover your whole population. Now, in the not-so-ideal world, we live in, this may not be always possible, especially if you use a statistical approach where 100% is really not defined. There's always some noise. If you are somewhere around 90% covering 90+% of your population of interest you're in a good place. Last but not least, this definition of your segments should be independent of the outcome you're trying to predict. A simple example: technology choices, tools, which tool are they going to use, for example. If that's what you're trying to do at the end of the day with your segments, then the usage of those tools should not be part of your segment definition. If somebody is already using tool X, then okay. You know, they're very likely to use it, right? So it's like going around in circles. With that, let's visualize that a bit to make sure you all follow what we're trying to do and why.
Assume that in a very, very simplistic universe out there, we somehow found that the best way to segment our audience is based on shape and colour. You can see here we have four segments on the left, blue diamonds, green rectangles and the other two and they are similar within. So, you have to be a diamond and you have to be blue to be on the top left. You can be a different shade of blue and you can be a slightly different size. That doesn't matter as long as you're a diamond and you're blue. These are distinct. They don't overlap in any way. You will notice that there are some odd fellows there in the middle space, that doesn't belong in any of these four segments and they do not form segment themselves, because they do not meet the shape and colour criteria of any of these four segments and they do not belong together. For example, you do have two Xs there. Same shape, but one is red, one is grey - so different colour, therefore they cannot be grouped together. You gave two greys, but one is X and the other one's a circle. Having defined our segments, how do they help us? Through predictive modelling, what we find is that segments have different reactions when offered different choices. Our green rectangle friends there are far more likely to go for choice B (65%), more likely than choice C - just 20%. On the contrary, those orange pentagons that don't like very much choice B, our robot friend, only 10% of them would go for choice B. They would instead go for choice A. They have very strong reactions, very strong responses to different messages, offers. They don't always have to be products, it's just an example. They could be campaign messages. For example, we have a product that has a robot aspect to it and it has a mobile aspect to it. To the green rectangles, you would go with advertising the robot aspect while to the orange pentagons, you would advertise the mobile aspect. This way, you maximize response. Why? Because if you just had this one single group with greens and oranges mixed together, then if you were to offer choice B, you would get a very low response as a result. Something like 40%, somewhere between 10 and 65. This is what we're doing and why we're doing it. Let's see if some practices that are popular right now are a good idea or not.
We know that many clients tend to use technology, you know, platforms used, we also saw it in the first slide, as their way to segment developers. Is that a good idea? No. For many reasons. I'll just give you a couple here. One is that technologies have a really bad habit of becoming obsolete. Remember when Symbian was king? Well, it's not there anymore really. Between 2012 to 2013, it had lost half of its mindshare among mobile developers, this mindshare we have been tracking for quite a long time. If you had defined your model back then, based on the mobile platform used, suddenly you would find yourself with empty segments. Either nobody would be there, or very few people would be there. There would be other people using new technologies that you wouldn't have accounted for. The problem with technologies is that they come and go and if you define your segments based on those technologies, then one way in which you're in trouble is that you will find yourself with obsolete segments and developers or people who are not accounted for because they use entirely different technology.
Another very, very important point that is the root cause of many problems here is that developers are active across more than one developer areas. There is no such thing as a "mobile developer." As you can see here, 5% is only focused on mobile developers. The vast majority of developers are active across more than one developer area. A simple example: somebody has a backend in the cloud. And they have, let's say, a mobile front end and they have an ML algorithm as part of their product, their app. So they're active across three sectors. What I'm showing you here with this graph is how focused developers are within each of the sectors. Even for web, which is the most focused, with more loyal developers. Only 8% of web developers are only into web, 92% are all doing something else. If you look at the bottom of the slide, you'll find all the emerging sectors, VR, AR, machine learning. It makes perfect sense because developers in these areas mostly come from other sectors. They have some background in some other area and are just pouring into the new sector exploring the waters.
What does this mean for segmentation? It means that even if you're strictly interested in only one sector, you still need to consider what developers are doing in the other sectors in which they're active, because their choices in other sectors, their experiences in other sectors are bound to influence what they're doing in your sector of interest.
If you don't take that into account, then you will be observing behaviour that you will not be able to explain. You will consider it as noise, while in fact, it's not noise at all. It stems from the choices in other areas of development. Another issue is with developers being active across different areas. It's not just the technologies they may be using elsewhere, but also their motivations. We have developed this, several years now, and we have put it into test several times. It works every single time. A motivation-based and outcome-based model which is based on the main goal that developers have in each of the areas they are involved in. Here, you can see all the segments that we have as rows and the sectors on the right and you can see which segments apply to what sector. Roughly grouped together, we have segments that have to do with self or community improvement, such as explorers. This is a really important, segment throughout and applies to all sectors. These are the guys who explore. They're not just having fun, but they're not professional, either. They are trying to gain experience, in order to monetize in the future somehow. Το have future opportunities in that sector. We also have hobbyists for example, who are just having fun. Specific to machine learning, we have pioneers who aim to advance human knowledge, to contribute to research. They don't want to do anything other than that.
Then we have two segments that are focused on getting direct revenue out of development, either through selling apps or through contract work. And then we have people who do so indirectly. They want to monetize indirectly either as part of an enterprise IT department. These are the optimizers who increase organisational efficiency or reduce costs. Also, people like product extenders. They're usually found within the marketing department of large organizations and they're trying to promote, a non-tech product or otherwise. They're just doing customer analysis, trying to sell a product. These are all, I won't go through each and every segment here. The idea is that developers may have different motivations across segments. So a developer may very well be, in a quite common scenario actually, be a Hunter. Generating direct revenue or a gun for hire in a sector, usually in a mature one like desktop, web or mobile, while they're also explorers or pioneers in an emerging sector. Really typical, right? They're monetizing out of the mature sector where they know how things work and they're exploring the new sector to figure out if they can somehow make it work for them. Motivation should be taken into account, but all motivations across all sectors. These were just a very few examples, of things that can go wrong with segmentation.
Other examples include practices that include revenues. For example, people segmenting based on revenues, find themselves in trouble, but I won't go more into what doesn't work, I'll share what does work. On our data-based approach, what we do is that we rely on the data to speak unsupervised. Unsupervised? Well, it's a class of models. But it also means that we did not make any prior assumptions. We do not ask the models to figure out something specific. We just try to identify clusters, to identify really homogeneous groups, as we just said.
What do we include in our models to come up with those segments? A really broad range of things: demographics, involvement in each area, whether they are professionals or not, their industry, whether they're making decisions about tools - tool purchasing decisions that is, their coding experience and many, many more. What we do not include - definitely - are technology choices, because as we just said, that's very problematic and revenues or revenue models.
Based on all those inputs, we use those and we run at the end a declustering analysis with a few steps in between. And then, that's not the end of the road. Suppose we do have satisfactory clusters. That's not the end of the road. Why not? Well, if we were to feed those clusters into a recommendation system, for example, then we would be fine. That will be the end of the road. The thing is that, with segmentation, our clients are the marketing people. So whatever we produce, has to be well explained and understood by humans, not by machines. To make it work for marketers, it has to be really well-defined, profiled, well-explained and described, usually with a picture to go with that and a name. These are the personas.
The Personas
You need to go back to translate your clusters into personas. We did that. We did that across all software developers. The idea was mostly to demonstrate the whole process rather than come up with personas that are useful to everyone. We'll get into that in a minute. We don't hope to make this work for everybody. But here's what we found: There are six segments, six personas.
We didn't design it that way, it just came up from the mould. It appears that evolution of the developer is really what matters when defining distinct segments that behave in a distinct way. Our first segments are our young learners who are, well, as the word implies, young.
They have to be below 34 to be in this group, but most of them are in their early to mid-twenties. They are not professional, typically. They have to be at least learning or exploring one area to be in this group and typically most of them are not professional. Some of them who are, are not in there. They're in groups of up to 20 people. So really, just a startup on the side or something like that. They don't take any tooling decisions, they don't buy tools. They're youngsters. They're students, without a budget.
Then, we have young professionals, one, just one step further up the ladder of evolution. Now, these are typically motivated by making money somehow. And they are professional in at least one sector. They're also young, but on average, slightly older than young learners. Their company does buy tools, but they're the juniors. So they have nothing to do with those tool selections at all.
Following are the middle standards. Middle standards are a bit more experienced. They have nothing to do with emerging sectors, though. They have a background in the more established sectors. Here we start seeing developers say they have roles, other than the typical "I'm just a programmer" response. We start seeing specialization and they also take part in the decision making. However, they don't call the shots, they don't make the decisions.
Then, we have another group that is in parallel with this one. It's not further up, it's not another stage of evolution. These are the emerging extenders. Emerging extenders are really interesting in my mind. They have a background in one of the mature sectors: mobile, desktop, web and they are involved in at least one emerging area: IoT, AR, VR or machine learning, not necessarily data science, they're not data scientists. Data scientists are quite different. Emerging extenders are ML developers. They're usually in up to medium-sized companies and they do take part in the purchasing decisions.
And then we have the seasoned decision-makers who are the top of the hierarchy here. They are older than the others, they actually approve budgets and they have the final decision on tools. They usually have several teams. And of course, they have managerial roles or otherwise specialized roles. They're the ones who you actually want to talk to. They will decide if they are going to buy a tool or not.
Last but not least, we have the experienced loners. Also not part of the evolution track. They're in the side path of their own. They're older on average and they are the least experienced. They're involved in a very limited number of sectors and they have very limited experience in the sectors they're involved in. They usually work alone or in groups of up to five people and they have several roles. We have several designers, for example, in this group.
These are our six personas. Should you use them? Maybe, maybe not. Our personas here are just generic tools of the developers out there, so they may not exactly fit your needs. Your audience may be a lot narrower than that. Maybe active in a very specific field.
The very first step you need before you even start thinking about segmentation is to very clearly define your audience. Come on, that's a trivial question, right? You know your audience. Well yes, but in some cases, maybe you don't. Maybe that depends or is flexible based on what you're trying to do here. What is the product that you're trying to promote? You may want to include a broader audience.
If, for example, you're trying to get people into machine learning through your solution, then maybe you should include more developers outside of your ecosystem, to get them on early. Just an example.
Once you have defined your audience, you need to build a segmentation model that is specific to that audience. That may match our own or not, in most cases expect it to be similar. Similar things would surface as important, but it's not necessarily identical. Whatever you do, whatever your audience is, the methodology remains the same, as we have just discussed. You have to make sure you come up with segments that are independent of what you're trying to predict, that are homogeneous so that they can be trusted to behave in a certain way. All members behaving similarly and each segment are distinct from the other. This way, you can target each one of them with a distinct message. That's all I had to share today and we can move on to your questions.
Q&A
Host:
We've got some great questions here. One attendee asks "Why do you exclude revenue as a segmentation filter? Isn't it a useful indicator for developers who want to run a successful business?"
Christina Voskoglou:
There are issues with revenue. In a nutshell, you would be excluding the long tail. It also depends in which sector you're active. Let's think of games as an example, there we have many hobbyists. We also have people who are trying to make money, but they're not really making any money. All of those, put together account more than 70% of the game developers. Right? So if you were to segment on revenues, you would be automatically excluding more than half of the market. And we know that these developers are the ones that really shape market shares. That's one problem with revenue. The other thing about revenues is that they change, it's not a constant thing, it's part of evolution. It may also cause you trouble in that sense.
Host:
So, I guess one of the questions that I might have is when we talk about revenues, are we talking about the revenues of the business where the developer currently is, or are we talking about, I don't know, something else? Their salary?
Christina Voskoglou:
No, we're talking about the app revenue or the development-related revenue that their company makes, what they make if they're just working as individuals. These segments anyways, any one company could have all of these or most of these segments represented in there. A company of developers, they may have different ones in there. A company will have juniors and a company will have seniors. Right? It depends who you're trying to target.
Host:
Just a reminder, if you want a copy of the slides you need to contact SlashData directly. So Christina, what's your contact information if they want to have a copy of the slides?
Christina Voskoglou:
I think you could just, send an email to our marketing email, and we will get back to you with an answer to your questions.
Host:
Wonderful. This was a very, very thorough presentation. Your methodology seems quite sound and you know, segmentation is something that should be practised across the board. Marketing sounds a little bit like a dirty word in some instances when it comes to developers and developer relations, but really, if you know your audience well, you can just drive better outcomes, right?
Christina Voskoglou:
Yup, that's right. Thank you very much for hosting the webinar and everyone for attending.
Host:
Thank you