Following Part I of our Dev Tools discussion, we wanted to focus on several potential action points for developer tools companies at their early stages of marketing, and also address a recurring question in software and developer tools: “how should we set a price for this product?”
Before setting a price: putting pricing into context of developer persona
The most important characteristic of developer marketing, which has important implications for pricing, is that while it has B2C characteristics, developers are not your typical B2C customers:
(i) Developers love to build their own tools, so there needs to be a deep value proposition for them to actually want to consider paying for a product. Also, almost all of them use a large array of tools, and intuitively will think about the price they pay in the context of other tools they already use.
(ii) The type of developers you are targeting in terms of “availability to spend” also matters greatly. Are they coming from a place of abundance and comfort, or are they coming from a place of scarcity and struggle?
(iii) Developers, generally speaking, prefer to limit human interaction and abhor marketing fluff, so make sure the process is as digitized as possible (for example online demo vs an in-person sales demo) and also have easy to understand tiered pricing model that address the different types of persona.
(iv) While developers are very picky, at the same time very forgiving because they have to deal with bugs themselves all the time. Therefore focusing on value proposition is more important than having a beautifully functioning product in the early stages of development, and simply fix any bugs as you iterate with new releases.
KEY RECOMMENDATIONS BEFORE THINKING ABOUT PRICING
Don’t build too complex too early. Validate a core value proposition and pain point first.
Make demos, landing pages and pricing models simple and clear: a product trial (not asking too much info and incorporating easy email registration) combined with a simple pricing structure and no marketing fluff
Onboarding has to be a frictionless and easy not to create unnecessary barriers to adoption or feedback
Clear and concise documentation is a must and increases perceived quality
Content and community building is key initially to evangelise the solution you’re selling to a precise pain. This includes testimonials and technical reviews, building developer advocacy and writing about topics that are uniquely interesting
Don’t sell technology but instead focus on selling a solution
Map your buyer and user persona in terms of purchasing power
Do not give everything to the single player mode and leave space for enterprise features that will come later on
I’m ready to sell – now how do I think about Pricing?
Below is a few items to guide you in your pricing decision:
i) What budgets are you targeting?
To first assess ‘ability to pay’, and with regards to the budget approach, the traditional view has been that developers choose what they use, and the organisation pays for it. However this really depends on what level of the stack you are and also the developer persona (individuals, large organisation, purchasing power). What is therefore key is to understand where budgets really lie: some of the budgets are indeed massive (for example, for infrastructure or hosting) but it also depends on exactly what you are purchasing. A few examples:
- Developer tooling: Github has set the pricing anchor for developer productivity tools (i.e. between $4 and $21 per month, per seat model) and budget lie at the developer level. But the question now becomes: is your tool better or more valuable than Github?
- For consumption based models (for example API tools, or compute power based tools) where budgets lie higher in the organisation, most companies are adopting a cost + markup model because it is understandable and convenient to all parties.
- When it comes to Infrastructure, where budgets may be even higher in the organisation, the main model remains licence per organisation, sometimes evolving into consumption based models to tailor to growing organisations.
(ii) What is the best pricing model?
… or, more specifically: in a space where marginal costs are approaching zero and in new markets where demand is uncertain, what is the best pricing model? If you want to price according to “value”, how do you put a $ value on a pain point? And if you price based on peer products, what are the “industry” benchmarks?
The specificity of targeting a technical persona is that there are many alternatives to buying your product, including doing nothing, living with the pain, building it themselves, or going for an alternative product which may solve the pain-point or at least part of it.
Eventually, your product pricing may fall in one out of two categories: it will appeal to either the rational (how much do I save?) or the intuitive (scarcity, what does the tool remind me of?) part of the buyer brain.
As mentioned earlier, Github is setting the pricing in developer tooling. This is because every developer uses it. But those developers are also probably using Jira, Heroku, etc.
The tooling stack will act as a benchmark and set an anchor around pricing. Therefore one needs to understand other tools used by the persona and user you are trying to convince, and be able to frame pricing according to that context.
The first step here would be to map all the substitutes, alternatives and complements that may anchor your buyer willingness to pay, and this applies for both small and large organisations.
Only if they can’t come up with anything similar, then will they shift to a more rational approach and try to pin-point a mathematical formula to price your product, like a cost saving analysis (i.e. Net Present Value calculations), budgeting, etc. In this case, a great value statement is often positioned as: significant time saving, combined with time to market advantages.
Assortment pricing: a few lessons from good old-fashioned marketing
Assortment pricing is particularly important in the dev tool pricing strategy, which comes back to the popularity of Open Source + premium features and opencore models we discussed in Part 1.
The first type of assortment is vertical, that is: offering different features that make your product better or faster as you buy the premium version. Users value features differently (for example whether they are an individual developer, part of a large team). A popular option is to offer a variety of features and paying options on top of a free version, with the perceived value and price increasing with each addition.
This is a great way to upsell over time from a free tier, so that developers can start using the platform and unlock features as adoption grows. There is often a middle tier pricing (rarely purchased) that really acts as a lure for the full premium versions and meant to increase the perceived value of some features.
The horizontal assortments typically come later in the lifecycle of the company where you start to establish your brand, and involve selling different products to the same persona. You see this everywhere in the ‘traditional’ world: if you purchase a camera, there’s always going to be a bag, tripod and cameras that will also be suggested as complements, but another good example are mobility companies going in the payment space. With some clever pricing and product positioning strategies, this can allow you to expand your total addressable market significantly.
Rational approaches: quantifying the savings
As you move upmarket, many discussions around pricing turn to a more rational discussion i.e. What processes are you saving on? Are you reducing the need for additional hires?
Compelling cost saving and efficiencies are behind the success of companies such as Snyk, which builds security as part of code-commit, and thus created key advantages in terms of faster time to market and cost optimisation in devops security teams.
KEY TAKEAWAYS
Think hard and assess the value proposition – both in the context of time saves and best alternatives (nothing, doing it yourself, another tool)
Vertical and Horizontal assortments are a great way to build up pricing
Pricing can hurt your product in the long term if you put limits on usage
Pricing plans linked to cost don’t always make sense over time; while Snowflake has a consumption based pricing model, its gross margin improvements clearly shows that it doesn’t tie to costs.
The right pricing is somewhere between cost + margin and perceived value. Don’t hesitate to iterate and evaluate the impact of pricing on demand. Do ask what your individual and enterprise customers would be willing to pay and what how the rationalise the pricing
When getting stated however think adoption first, and then optimize for $ revenue later
In this two-part series, we’ve looked at key areas instrumental to the success of Dev Tools adoption. Whether pertaining to the adoption & go-to-market strategy of a Dev Tool, or to its pricing point and model, Dev Tools present a number of intricacies which, if leveraged correctly, can pave the way to rapid adoption, and the opportunity to grow into a major player in the enterprise world.
While these aspects are an important part of “succeeding at Dev Tools”, there are also a number of other topics to look into – if you’re a Dev Tool company founder, feel free to reach out, and we’ll be happy to discuss these topics in depth with you!