Developer Science: Segmentation

Introduction

This is the first post of a series about my experiences in developers program management. It is a very personal point of view but, no doubts, it includes many insights from my work as teacher in a Computer Science school,  after as community coordinator in a open source community, Morfeo Project, and lately, as Developer Program Manager in BlueVia.

First of all, I have to clarify that my vision of developers program is a scientific vision i.e. the management has to be scientific, including segmentation, product definition and tracking with proper metrics. Many useful strategics and tactics can be extracted from educational industry (mainly STEM universities), organizations working on technological transference, knowledge management, open source communities and, obviously, technological star-ups (technology adoption cycle). Some useful references are [1][2][3][4][5][6][7][8][9].

Segmentation Model

Concerning to developer segmentation, even though geographical segmentation makes sense, I will present here a model based on skills or "maturity". This helps to introduce the term "developers maturity's paths". In the last part of the post, I will comment a few things about geographical segmentation.

The model I will use is shown in the following picture:



I have identified four vertical categories:

• Students. I include into this category students from different levels, but also researchers. All of them need technical support closer to training than to commercial support. However taking into account that many time the members of this category evolve into entrepreneurs, technical staff in SMEs or corporations or open source leaders, it is important to track them in their maturity paths. Typical activities for this group include on-line training, contests, internships, and some kind of technical certifications. Free resources for researchers might produce amazing outcomes. Documentation and branding are typical feedback from the developers in this category.
• Entrepreneurs. This category request support in term of solution definition i.e. business and technical support, and also funding (incubating and accelerating). Considering valid the model of disruptive innovation, it is critical to track this group due to its potential on product definition for next generation, platform requirements and product team re-engineering. Even though considering the high mortality of the start-ups, many useful insights can be extracted working with the developers in this category. Freemium models, cross (sector / geographical) polinization, networking and funds are typical action for this group. From my point of view, agile product definition (alpha APIs & services) is the best way to gather feedback from them. An open innovation strategy is very useful. The influence path is stronger for students and SMEs.
• SMEs. This category requests professional technical support. Sometime they are even willing to pay for professional support: this means the level of support needed i.e. offering non-professional support to this category could be catastrophic. Dedicated tools such as Trac, Bugzilla or Assembla are highly desirable. The typical feedback from them is about product definition and, very important, product performance (scalability, throughput, etc.). Beta testing or release preview are typical activities for this group. The influence path is stronger for corporations and entrepreneurs.
• Corporations. This category requests professional support, training and other technology transference tasks and most of the time interoperability support. Obviously, the impact in term of business, but also in term of resources is high. The typical actions are specific/private events, analysts information and benchmarks (technical/financial). The feedback provided is technical performance and financial KPIs (ROI/TCO). The influence path is mainly affecting other corporation. It is very important to pay special attention to public sector. Into this segment i.e. corporation, special public sector is worth to consider special segmentation for e-health, e-gob, digital inclusion and mobile e-learning.

There is an important segment cross to all vertical categories: open source communities. This is an especial category because developer of any kind contribute to open source communities. Due to OSS plays a special role in the technology development strategy it is worth to consider carefully. In concrete, special tracking tools must be used. This is complex topic, but you can figure it out taking a look to Bitergia's blog. Typical activities for this segment are community hosting (blogs/wikis/forges) and funding progam such as Google Summer of Code or Microsoft's CodePlex.

Developers' paths

The segmentation model proposed allow me to introduce a couple of dynamics structures: Influence paths and Maturity paths. Here you have a proposed definition:

• Influence paths. That means how activities in one segment of the developer ecosystems have influence in other segment. Even though the activities structure are different, in form and messages, it is possible to extract useful information from entrepreneur & SMEs segments, enforcing the messages for students and corportations.
• Maturity paths. That means how the developers go through different segments. However, it has to be understand from a role point of view i.e. how the developers evolve and how they play different role for the developer program. Obviously, that means also evolving in skills and monetization.

I called this structures "dynamic" because the developers program is configured using this tools i.e. depending on how it is implemented influence, the developer program amplify its activities, promoting technology and brands. In the other hand, maturity paths allow developer program managers to work from the very beginning, profiling their own developers community, driving how the developers create products and services, how they monetize their contributions and how they create a meritocratic profile.

Geographical segmentation

Geographical distribution is another approach for segmentation. But from my point of view, it is a complementary segmentation. Even though the developers outreach strategy should blur geographical frontiers, it is true that language and culture have a great impact in the strategy. Once again, the general approach "think globally, act locally" is fine. In any case, the meritocratic principles should include a hierarchical structure, beginning locally and reaching global level.

Concerning to the communication, here I think that the organic grow is better. Using a hubs network, the PRs activities should run by them self, creating proper channels for communicating both sides from local and global level of the activity.

Conclusion

Starting with a simple segmentation model, it is possible to define an overall structure for a developer program. In coming post, I will use this model to describe activities, communication and feedback gathering for developer communities.

References

[1] Wellsprings of Knowledge: Building and Sustaining the Sources of Innovation, by Dorothy Leonard and Dorothy Leonard-Barton.

[2] Crossing the Chasm: Marketing and Selling Disruptive Products to Mainstream Customers, by Geoffrey A. Moore.

[3] What the Best College Students Do, by Ken Bain.

[4] Producing Open Source Software: How to Run a Successful Free Software Project, by Karl Fogel.

[5] The Innovator's Dilemma: When New Technologies Cause Great Firms to Fail, by Clayton M. Christensen.

[6] Innovation and Entrepreneurship, by Peter F. Drucker.

[7] Organizational Behavior, by Robert Kreitner & Angelo Kinicki.

[8] Open Innovation: The New Imperative for Creating and Profiting from Technology, by Henry W Chesbrough.

[9] The Sources of Innovation, by Eric von Hippel.