The Debrief: Go to market in dev tools – Part 1

At Alven, we continue being excited about the growth and innovation we’re seeing in the developer tools space. We’ve been backing the category for a number of years, and have been fortunate to support great teams such as Infinit (sold to Docker), Stripe, Algolia, Platform.sh, Keymetrics and Sqreen. 

And while some of these devtools solutions have seemingly already developed into market standards used everywhere, the continued emergence of new players across Europe indicates this is only the beginning. Capital invested in the category is increasing fast, and with the majority of developers learning a new technology every few months, the pace of innovation is speeding up.

So as DevTools are entrenching themselves even further into a durable trend, we thought we’d look into why this category has been so dynamic in recent years, what makes launching a DevTool startup different than other software & SaaS companies, and share learnings from some of the founders in DevTools we’ve partnered with.

What are developer tools?

“Developer tools” is one of those categories that encompasses a wide array of products, anything from infrastructure layer applications to any tool that is used by developers on a daily basis to either build, collaborate or deploy.  The lines can be blurry – for example Algolia is not per se a developer tool company, but in their early days they did start and act as one. 

Why are DevTools becoming such an important & dynamic ecosystem?

Due to the increasing expansion of tech use and the software stack globally, there is a strong demand and an undersupply of developer talent. Developers are becoming precious commodities that can reach premium talent costs, making developer productivity crucial and a real economic pain point.

In parallel, a number of trends have led to an accelerating increase in the supply and adoption of devtools solutions:

• A democratization of cloud-based tools, which are easier than ever to discover (through trials) and adopt at scale and rapidly

• A decentralization of the decision and in many cases the purchase process from the traditional CIO to developers, who can try solutions directly and assess the right tool to pick, with many companies having budgets for developers to buy tools for personal use 
  • Once considered end-users, developers can now act as evangelists within their organization, and this has huge implications for go to market for dev tool companies
• Finally, most developers learn a new technology at least every few months, which in turns creates a opportunity for more solutions to be tested and gain traction, a virtuous creative circle for this particular sector

This makes dev tools a market with a combination of significant financial stake for companies, a broad user base, high disposition for novelty, and the potential for rapid, if tricky, roll-out.

“Developer productivity is the fuel of business, the speed of iteration is a key main factor of success.
The Build vs Buy decisions are obsolete, they are replaced by Buy and Build: developers select a set of platforms that are easy to use and can be extended. Twilio is a great example of such a platform.”
Algolia co-founder Julien Lemoine

Dev Tools Go-To-Market: a unique approach

Succeeding in rolling out a dev tool solution at scale and with durable monetization relies first and foremost on mastering a fairly unique set of go-to-market tactics, quite differentiated from traditional SaaS, and involving a quirky blend of B2C and B2B characteristics.

If you think about traditional marketing – it usually involves talking up the product or pre-announcing features, but people are not directly using the product. In the developer tools space however, you have to compete on the merits of the products and feedback will be honest: it works or it doesn’t. So it might be harder to get initial traction, and only once you start winning the battle on quality, you can turn traditional marketing to your advantage, and go as fast as you can before incumbent have the time to react (and often, they cannot react fast enough once you get traction.

“Even turkeys can fly in a high wind. Marketing shouldn’t be the driving force until you know your product is in the right place”
Stripe co-founder Patrick Collison

A key success factor amongst many dev-tool companies is a very early vision and ability to link the technology to the business use case and stakeholders  i.e.:

• who will use it (a.k.a. persona, persona, persona): a fairly common starting point in defining a go-to-market, regardless of the vertical. For example, are you addressing a developer working solo or within larger organisations? Very few tools will manage to appeal to the entire developer market initially.
• who will pay for it: this is where DevTools start becoming a beast of their own: as we’ve mentioned above, User & Payer can be the same person but sometimes different and ‘double opt in’ from bottom and top of the organisation may be required. 
• where it will be used: Most importantly the key ethos here should be to add value to the stack developers already using, rather than trying to redefine or re-invent the way they do things.
• how it will be adopted: what is required for mass adoption? Will there be compatibility issues or changes in processes? The adoption curve is paramount from a scaling perspective: do you need 100 engineers to use the product to spread adoption in an organisation, or is it 90% of the engineer base? For productivity level tools particularly (Jira, Clubhouse) go to market can be akin to B2C virality (i.e. Slack) but the tool that has the most footprint will eventually win as large organisations rationalize tooling.

The inevitable up-market move

While building a Dev Tool means addressing a large base of users, often leveraging the insights of decentralized individuals, creating a Dev Tool company that scales shouldn’t be envisioned as focusing on the long tail.

“At Sqreen, we consciously and rapidly went through an up-market motion in our early days, targeting companies that would become the mid-market in a couple of years”
Sqreen co-founder Jean-Baptiste Aviat

• Building a product that is relevant to small companies when you get started generates very fast feedback cycles, and then allows you to iterate with a lot of agility. Therefore, as an early stage startup, the key is to gather lots of feedback with a large sample set of companies so you don’t get stuck iterating on overly complex features 
• The enterprise move is recommended after extensive testing with smaller entities and gradually go up in size; building all the features (product, security, etc.) that you will face with more complex organisations, so your sales cycles should become manageable
• Once you go up market, only invest in features that will be relevant to large organisations because this is the segment that will generate the real value in the longer term; at the same time balance needs to be maintained so that you don’t turn back on your core fanbase 
• There are some examples of companies that go enterprise directly, but this is rather an exception than the rule  – the only way you can start with enterprise directly is if your prior experience is in an enterprise-oriented function (i.e. FANG or other large software companies) and are able to build a market around a pain point you know extremely well. Other examples are companies that were created inside another larger entity and spun out into an opensource project (i.e. Planetscale from Youtube)

KEY TAKEAWAYS

A lot of stars on Github doesn’t equal a monetizable product: understand the user persona, route to mass adoption and willingness to pay.

Go to market depends on persona: selling to individual developers vs selling to a Facebook developer working with 1000s of other stakeholders has significant implications with regards to product features (i.e. collaboration) and ultimately go to market: make sure that you have in-depth understanding of your target audience

Don’t spend too much time on product building (critical, but ultimately controllable) versus customer insights & discovery early on (which will provide indispensable feedback to build in the right direction and effectively):  hundreds of potential customers interviews are a must before launching into full scale production

Go as far as you can within your network when gathering initial feedback, from the community but also from approaching larger organisations within your network,

The Upmarket move is a must, eventually, if you want to build a global success

The pain within bigger organisations is substantially larger: ‘enterprise features’ such as communication and collaboration become more critical as you target large customers

Developers may make the decisions but they don’t always pay the bill

Creating Authentic Value: Open Source and Open Core as go to market strategies

When it comes to defining the go to market strategy of a dev tool, Open Source offers enticing advantages. Open Source software simply involves releasing source code under a license which grants users the rights to use, change, and distribute the software to anyone for any purpose, and it can therefore be built collaboratively through the developer community. It has become popular due to its decentralised approach, fast development cycles and also because it allows companies to get to distribution and adoption rapidly.

A common misconception is that Open Source tools are developed by hundreds of people – which is often not the case. It’s often just a way to quick adoption.

However, this fast adoption often comes with an important caveat: effectively, when a (truly) Open Source project gets released into the wild, by definition, it no longer is its creator’s property. Therefore, it becomes much more difficult, if not impossible, to monetize an Open Source project without a fully fledged enterprise version (except through donations).

An alternative is the “Open Core” model, an evolution of the Open Source go to market model. The “Open Core” model is a ‘modified’ Open Source approach, and is a go to market strategy where a company offers a “core” version of the product open source but with limited features (usually for free). 

Essentially, it retains some of the biggest advantages of the Open Source model.  It provides a network effect in the user base, which has been lacking in the traditional SaaS model historically, and allows software companies to go from an expensive sales-based model to a minimal, marketing-led one. It also acts as a feedback loop, with a proactive community that can support the product roadmap, and has other second-order benefits such as hiring (i.e. identifying highly engaged and brilliant individuals).

Under this model, premium commercial add-ons can be purchased, and those parts are proprietary. Hence, this enables much improved monetization prospects, though this model works best when significant value has been created through enterprise features, otherwise users will stick to the free version or will churn rapidly. 

Bear in mind however that a lot of tools (still the majority today) are not community based but still built from traditional B2B marketing!

In a next part of this article, we’ll look more specifically at marketing tactics during adoption phase, and finally, pricing models and monetization strategies in the developer tooling space

Acknowledgements: Thanks to the stellar dev tool founders Eiso Kant (Athenian), Guillaume Montard (Bearer.sh), Julien Lemoine (Algolia), Jean-Baptiste Aviat (Sqreen) and Thomas Paul Mann (Raycast) for sharing insights for this article.