In 2017 we decided that we wanted to grow our company by offering online tutorials for a new project. We know how to create and deliver the materials well, and we know that there is a need for quality online training for more than just Drupal. The next big questions after this decision were: What new project? Which new market to tackle? We needed a target market that made good business sense and aligned well with our company values.
Going through the process of defining criteria and assessing potential markets was a major learning experience. As importantly, we learned more about who we are as a company and what really matters to us. We ended up with a clear list of criteria to guide us — and it ultimately guided us to Node.js. Having gone through this process once, if and when we expand into another market, we’ll use that list again.
Choosing our initial criteria
Our initial criteria borrowed heavily from ways we found success with Drupalize.Me, as well as some general business principles for the kind of products we create. We asked ourselves what was the market environment when we launched Drupalize.Me in 2011, and what factors contributed to its success, both then and today. This is the market criteria list we created:
- Open source code or access to an app-building platform.
- Mainstream adoption of end products that use technology X. For example: Drupal is used by a lot of very large enterprise sites and household names.
- Good hiring trend: Is demand for X devs/experts increasing or outstripping supply? Are companies/orgs complaining about a lack of good talent?
- Are there software versions and regular version cycles? When is the next version due (approximately)?
- Is free/community content centralized or scattered?
- Is there already an established competitor(s) in the space? If so, how are they regarded? How do we compare feature-wise? Content-wise?
- Does the ecosystem have lots of competing solutions to the same problem, and do learners need to understand how to choose the right one? (Example from Drupal: Context vs. Panels, or Zen vs. Omega vs. Bootstrap)
Market assessment
Once we had our list of criteria, we needed to start gathering together a list of potential markets to evaluate. We looked at current tech trends, projects similar to Drupal, and what tools we and our peers were using. We came up with this list to investigate:
- Angular
- Elm
- Gatsby
- Go
- Magento
- Node
- React
- Vue
- WordPress
Online research
For each market, we created a template for quick overview assessment. The checklist contained the following:
- Who owns the project? (A community/association or a business?)
- Where is the main community documentation?
- Who are the top 3 online training providers?
- Is there an international conference? When/where is the next one?
- Is there a list of local or regional events (meetups, camps, etc.)?
- What is the development cycle like? Is there a release schedule?
- How is the job market (measured by Indeed)?
- Additional interesting facts and observations
After we filled in the answers for all of the markets, we got a sense of relative strengths and weaknesses. Some markets were eliminated because the market was too small, and not enough people were hiring for those technologies at the time to support the user base we would need to be successful (Gatsby, Elm, Magento, and Vue). We did make note of Vue and Gatsby having more potential in the future, as they’re both growing quickly and may become good future candidates.
In prioritizing the rest, we looked at the overall trends for adoption and use of the technology. A look at trends compelled us to drop Angular from our list. While it’s still widely used, it isn’t really gaining ground over other JavaScript frameworks.
After this initial research, for a combination of reasons, we removed half the technologies from immediate consideration. Then it was time to dig deeper.
Community interaction
One great way to get a sense of a market is to engage with the community. This is a key way we’ve found success with Drupalize.Me. So it was natural for us to start looking at events to attend in person as well as figure out where the community comes together online.
Throughout our year of research we attended 8 events total for React, Node, Go, WordPress, and Vue, along with some general JavaScript events, since we were looking at multiple JavaScript projects. Even though we recognized Vue was too small at the time, we liked the project and took advantage of an opportunity to check it out. While we attended sessions at these events to note trending topics, we were mostly there to get to know the people. We chatted with beginners and experts about their experiences both with the technology and the community. We asked them about how they learned and what resources they used. If the events had activities or sessions about contributing to the project, or getting involved in the community, we introduced ourselves and contributed if there was an opportunity to do so.
This process gave us a lot of insight not only into the viability of the market for us, but also (and more importantly), what kind of community we would be committing ourselves to.
Revised criteria priorities
One thing that became very clear to us was that while open source was an important criteria, it was a broad way of capturing what matters to us. A lot of our joy as a team comes from contributing to a community, and so in addition to the software using an open source license, we realized that we have requirements for the openness of the community as well. Communities that encourage active engagement and welcomed our contributions ended up much higher in our rankings. I should point out that no events or communities ever actively excluded us, but some of them were better at drawing us and other folks who weren’t already experts into the core community.
In revising our criteria, we didn’t change much. We did, however, add community engagement as a factor. We prioritized this and hiring trends as very important, along with the fundamental criterion that we could see a place for us amongst existing competitors.
Choosing the Node.js market
When we looked at our revised criteria, the experiences we had, and all of the data we gathered over many months, we sat down to pick which market we wanted to dive into first. Node best matched for us because they were incredibly welcoming and they have good support in place for helping us get involved very quickly. As someone who is not a Node (or JavaScript) developer, even I was able to engage and contribute right away.
Node is being used all over the world in a wide variety of applications, and many large organizations invest heavily in the Node project and seek out Node developers regularly. Many providers we enjoy and respect offer various ways to learn Node. But we didn’t feel that there was someone filling our strongest niche: deep dives with a hard focus on Node and its closely-related tools (i.e. not multiple JavaScript frameworks or other technologies as well). Unlike other sites, we target intermediate developers who know the basics and now need to put Node to use in real-world use cases and sort out best practices.
Striking off into unknown territory was definitely made easier by us taking the time to think through what is important to us and how that can be represented with research criteria. Going through the market research process taught us not only about business development, but also helped us more clearly define our values and needs as a company. We’re very happy to have settled on the Node.js project and community, and ultimately we launched a new online training site, HeyNode.com, last year.
We’ll be writing more about our journey into a new market, why we did so, and the lessons learned along the way. To keep up with the story, follow us on Twitter or Facebook.