Creating Champion Developers
How Builder Loyalty Differs from Buyers & Users
This is Part 2 in a series on Customer Loyalty
Part 1 Who Are Your Champions?
In my earlier post Who Are Your Champions, I described the dynamics of building the loyalty pyramid among your Buyers and Users. In this post, I explore why software builders (such as developers, data engineers and analysts) are a very different breed of user than either business or tech users. Therefore, tech companies need to build loyalty among the builders in a different way than among their buyers and users.
By the way, my Feb PMF Bootcamp has a few limited seats left. To apply check this out.
Building Software Gets Easier
In my customer quartet framework I define two types of users - business or tech. In the B2B world, business users such as employees, partners and vendors are the most common. For decades now, every business function from sales to manufacturing, and every business process such as order to cash and every business problem from detecting defects to predicting churn has had some software product or solution developed for it.
To serve these business users, an IT department of a company has many tech users - like engineers, security & sys admins, architects - who operate, manage and support these internally developed or commercially purchased software systems.
Historically, building these software solutions was expensive and onerous. Large companies like banks and telcos made huge investments to build custom solutions through an army of developers in IT service shops. This gave rise to the IT services industry in India that employs over 4 million people today. In the last decade, though, SaaS companies have developed applications for every niche enterprise function and are beginning to replace the legacy custom solutions. And the cloud native companies from AirBnB to Netflix have proven the power of software by building modern large scale software systems to reshape entire industries.
With the rise of cloud computing, data and AI technologies, building software has become easier than ever. No-code platforms are transforming every job to be done by business users.
These new products are a novel combination of apps, AI, data, devices and sensors built on foundation platforms (cloud computing AWS), foundation models (OpenAI) and open source software libraries (GitHub). Today, even a novice can generate decent code using text prompts in ChatGPT.
Building software is fast becoming as common as reasoning and writing.
Builders are a Unique Type of Users
For many tech companies, this has given rise to a large class of Users who are the modern day makers of software for and within an enterprise.
These are the Builders: Developers, data engineers, data scientists or even business analysts.
They use the major public cloud platforms, thousands of software development tools, and hundreds of open source software libraries, and dozens of AI models to build and run apps, fetch and stitch data, create and operate services - all to enable digital experiences for their business users.
These builders serve the other two types of users. They serve the business user directly by building software and digital experiences for them to improve their job to be done. And they serve the tech user by building software tools to help them accelerate their internal software development cycle, which adds new digital capabilities to further enable business users.
In summary, developers either enable business jobs to be done directly or provide software tools for other tech users to do so.
Thanks for reading Growth Matters! Subscribe for free to receive new posts and support my work.
Builders Create Relationship Equity Differently from Other Users
[In this section, I build on the excellent Orbit Model of community engagement, developed by Patrick Woods and Josh Dzielak. I apply their model to the pyramid framework to compare and contrast builder loyalty with end-user and buyer focused loyalty.]
Most software tool companies now target builders as part of their go-to-market planning since it offers a bottom-up, product led growth pathway to creating value for a customer. [More on Product Led Growth].
However, tech companies build relationships differently with software builders like developers, data engineers and scientists. These developer relationships (DevRel) are very different from the relationships with end users of software in product-led growth or those with buyers in sales-led growth.
Developers, or builders in general, are passionate about the tools they work with. How they discover, play and adopt new tools is different from business users seeking to get a job done or a tech user working with a tool.
Developers detest “marketing'' because they are not persuaded by “the promise” of a product. Since the concept of purchase funnel is not relevant, the conventional marketing tactics don’t work or backfire with developers.
Builders are influenced less by the tech vendor and more by the social capital created within the community around a tool or technology.
The Orbit Model defines this social capital as a combination of gravity (what attracts the members to a community) and love (what deepens their involvement). Community capital is the bedrock on which to build builder loyalty.
Builder Goal: To Build Better Through Community
Why is the builder's goal and journey different?
Building software has always been hard, but it is especially difficult to build scalable software that serves millions of customers. As an analogy, the 20th century saw manufacturing go from artisan products to mass customization with engineering focus on efficiency, speed and scale. The factories became more critical than the artifacts they were producing.
Even today, Elon Musk's take on the Tesla car is: "You want to have a good product to build, but that's basically the easy part. The factory is the hard part."
This is now becoming true for information goods as software shifts to the mass customization era with public cloud platforms and open source software stacks. [For excellent discussion, see Flow Framework by Mik Kersten].
Today, developers within a company have two software ''factories” or ecosystems to build upon. One, the employer’s internal tools and development platforms, standardized and maintained by the IT department. Second, the external open source communities [GitHub, GitLab, etc].
Not just code, but data is following the same path. With the explosion of data and AI/ML, data engineers and scientists now have a large set of tools available to support the data lifecycle. To build new software apps and data products, these builders navigate both external and internal ecosystems to become productive and efficient.
So, if you want the builders to use your new software product (an API, an SDK, a cloud service, etc.), you need to ensure it is adopted by the customer’s software “factory” and the community. Without doubt, the community is more important.
Builders face the choice of thousands of tools and techniques. They turn to the community to explore, find, learn and use the right tools for their tasks. Everything from sample code, documents, APIs, library, test cases etc. are supported by the community.
This is consequential - builders often become more loyal to the community than their employer. Their personal growth and future employment may depend on their status and credibility in the community. Especially with the gig economy, developers seek communities around fast growing technologies to stay productive in the market - way before companies adopt them. The recent flurry of developer excitement around ChatGPT and generative AI is a case in point.
Therefore, to create champions among builders, you need to engage them in their communities.
The Orbit Model is an excellent example of how you need to engage the builders in their community. Your focus should not be on transactions like purchase or downloads but on enabling the community to connect with your tool. You need to help builders in their journey to explore, participate and contribute in the community with your tool to build something of value.
For Champion Builders, Build Love for Your Product in Their Community
We can look at the Orbit engagement model from a cohort lens: How do builders progress from observers to become ambassadors (i.e. champions)?
Observers: They might not need your product yet. Your dev rel or community manager can help educate them with quality product content and tutorials. The focus is on building and nurturing connections with them. The critical metric is Time to First Interaction when an observer begins to engage with the community around your product.
Users: For this cohort, dev rel and community managers focus on increasing interactions among the users and other community members. The focus shifts to customer support and deeper product campaigns and channels. The critical metric is Time to Hello World or a similar metric that captures time a user takes for the first trial of your product.
Fans: This is the cohort of users who are willing to share their product expertise with others in the community. The focus of dev rel and community managers is to help fans contribute to code, build hackathons and engage in community and social channels. The critical timing metric is Time to First Build or a similar metric that captures time a fan takes to build something new with your product.
Many communities have lots of users, maybe even fans, but they do not take takeoff. They lack the ambassadors (champions) among them who can coordinate and lead the community. This separates developer-led companies from others.
Ambassadors (Champions) - This small group becomes not only your product advocate but also coordinates major social and building efforts around your product. These users become your evangelists or VIPs of your community with their own personal brands and status. They need to be supported by your product, engineers, and customer support to keep building community love. The critical timing metric is Time to VIP.
In Summary: Builder Loyalty Differs from Buyers & Users
This chart shows how the builder loyalty differs from that of buyers and users.
In summary, builder loyalty rests on community love, and is developed through evangelists and other expert builders in the community. Therefore it is critical to keep the community engaged with a roadmap relevant to their needs and initiatives that help the community build and grow.
This is Part 2 in the Customer Loyalty series
Part 1: Who Are Your Champions?
Thanks for reading Growth Matters! Subscribe for free to receive new posts and support my work.