Market Segmentation


Someone in the Seagull chat room tossed out a question, to paraphrase, they were looking for the magic formula that has led many projects to fame and fortune, namely, How do I motivate my Devs to pump out tons of code?. Aside from the obvious block all game ports, pay them more or feed them exponentially larger doses of caffeine, I felt it was time we delve into market segmentation. Market segmentation, is the study and selection of demographics who will be best served by our product, The Seagull Framework. This is part of our overall product development which will define how we apply resources.

Segmentation analytics can prove very beneficial, especially for framework projects. Frameworks, by their nature, must be many things to many people. We attempt to address this by first realizing that we must appeal both to users and developers. We are the meeting place in which these two groups meet, we bring them together. This dynamic creates a kind of chaos that, if not identified, is difficult to follow and can lead to the kind of icky divisions within the community that drive quality developers far far away. The project must also make up its mind to be made up of servant leaders. At Seagull Systems, egos get checked at the door in favor of a more open and inviting method of idea sharing.

One factor in long term project health is proper identification of each market segment, and how to best serve each, now and down the road. Since we are discussing a software product, we must, in our research, realize there are several groups involved in the development and consumption of a good open source framework project. There is an Eco-system that is required for optimum health and longevity. We will attempt to identify and separate the main market segments into Groups of Participants. This enables us to identify not just customers, but our talent as well. Open source projects rely heavily upon volunteers and evangelists. Each group provides it's own set of talents that lends to a quality end product.

The evolution and life cycle of a framework dictates that we start our market analysis at the bottom and work our way up. Just as in the code, each successive layer forms the foundation for the next above it. It is tempting to treat these groups as linear, however we must look at these groups more as nodes, but that is for another article.

Participant Group 1: Core Project Developers

A small number of developers talented enough to develop a quality framework. Core developers should stay core. These are the decision implementors, taking direction from the community and making possibilities reality. Core developers must retain a vast amount of conceptual and theoretical information about the framework, how it's used and its ultimate goals, then distill these ideas into a usable code base. Continuity in this group is key but it must not be insulated from the community itself to avoid the ivory tower syndrome so prevalent in larger OSS projects. This group normally tackles the largest of the projects in the pipeline as compensation.

Participant Group 2: Independent Developers

Participants here are developers with less emphasis on theory and more on design requirements. Most project leadership should come from this group. Normally, they have all the same access as Group 1, but not the final say so in implementation. You will find most modules being produced at this level. Feature requests and bug reports are handled at this level and translated from user level language into coherent geek/project language. This level normally derives its full income from writing modules rather than minor hacks as in Group 3 or by serving Group 3 itself.

Participant Group 3: Software Houses

Users are typically boutique developers whose primary interaction with the framework is with themes, templates, CSS and small superficial plugins. Given good enough documentation they will be able to hack together just about anything required of them to satisfy their client base. Group 3 should be the driving force behind everything usable and pretty. Frameworks suffer from design ruts more than any other type of web application. Since this Group normally derives its income from theme implementation, small hacks and direct end user/customer interactions, most bug reports and feature requests will come from here. This group tends to write good documentation.

Participant Group 4: Shared Hosting Do It Yourselfers

Users normally are made up of the do it yourself crowd. Early stage SOHO business owners who still think it's saving them money, people who have day jobs starting their own net business and hobbyists. Often the most valuable node of the community. Most pragmatic and practical solutions of a project are driven by the common and specific needs of this group. Real life tends to balance out the theoretical through this group. It must be noted that this group can be broken down into several smaller groups very easily. The two most notable are those willing to spend a few bucks here and there and those looking to be spoon fed. Most of this group has heard RTFM more than any other.

Participant Group 5: End Users in Seeking Easy Solutions

These participants are looking for out of the box solutions and do not have interaction with the code base. Most require installation and minor customization services such as custom shipping calculations or odd brand payment processor integration or theme installation. A significant percentage will use prefab themes to save on time and money. Most prefer point and click solutions. Note that this group is best served by Group 4 due to the level of hand holding necessary. It often requires 7-10 interactions to make the sale. Once the sale is made, loyalty is quite high. Many are very tolerant of honest mistakes, bugs etc. Some may be looking to re-sell the solution to recover costs.

Participant Group 6: IT Departments

Mid-level enterprises, with annual revenues of 100k - 5 million, have specific needs and requirements. This Group is very technology savvy and 90% of the time is seeking a solution to replace the current homegrown or starter kit type infrastructure already in place. They have priced the big software packages and do not think they should spend that kind of money. They complete their due-diligence and appreciate honesty, straight talk, details and both the pros and cons of any given product. If not enough information and too much sales pitch is given, you can bet they will go elsewhere. If you are not landing a these types of clients, you are on the wrong track. These contracts are normally long term.

Participant Group 7: Venture Capitalists

Entrepreneurs with vision, cash and the will to make things happen. For software developers, this is where your limits can be tested. This group believes that software development should move as fast as they can explain what they want. They are not afraid to spend fair money, nor are they afraid to fail and try again. This group demands stability discretion above all else. Not always willing to share custom modules and code with others, it takes a bit of work to convince them that using the open approach on at least some of the framework is a good thing that saves them time to market.

Participant Group 8: Big Corporates

Corporations seeking open source solutions from which to build upon. The intent of this particular group can be twofold. They may be seeking the basis of a new product, or they may be seeking the basis of a new tool for use by their customers. Lots of consistent interaction may prompt a buy out offer to consolidate operations, or you may just wind up as a trusted vendor/consultant. There is no one true path with larger corporations as they tend to be more open and free to maximizing the relationship. Be very wary of those who seek an end that may destroy your customer base, you may have to work in this sector again at some point and how you handle your exit strategy may reflect upon you later when you seek to revive your customer base.

It is also important to note that not all groups are created equally. Each varies drastically in size. Groups 1-5 have a progressively larger market, while 6-8 have progressively smaller markets.

These are your eight basic participant groups in a web application framework. I am fully aware at the time of this writing that these groups may be broken down into many smaller groups, but this approach allows us to deal in a manageable number and envision how we can service each one. Each group description can and should be modified over time to ensure an accurate depiction of the community.

In conclusion, the original question How do I motivate my Devs to pump out tons of code? I feel can be answered: By accurate identification of the demands coupled with proper delegation and application of one's resources towards said demands.

-- Mike Wattier