SaaSCast Ep.8 - Growing a Business to Developer SaaS

A recap of our 8th SaaSCast episode, where Shubham Sharma, head of growth at Keymetrics shared his knowledge on growing a B2D SaaS.

SaaSCast is back for a 2nd season! And we just added a dedicated SaaSCast page on the website too. This way you can easily access all our past episodes, suggest our next guests and subscribe ot be notified for future sessions.

About the guest

Keymetrics is a monitoring platform for Node.js powered apps. It is part of PM2, which provides process management tools for Node.js apps.

Summary

This time we talked about selling and marketing tech SaaS to developers. And as you already know if you're in this space, it's a bit of a conundrum. It goes like this:

Developers need softwares to power their apps and use them everyday...

But...

Many great tools and libs are already available as open source or at least free packages. So there is an inherent "sharing is caring" spirit in the dev community. And for many developers, it's one of the appeals of writing code in the first place...

And here's the real kicker...

That is of course diametrally opposed to the aspirations of SaaS companies (hint: 🕊vs 💸 -- one is not like the other). Companies that provide services for devs have to compete in that market.

So how DO you do it?

Well, that's precisely the question we'll try to answer in this episode!

traditional customer profiles vs developers

The way developers adopt, use and want to be informed about the product is different than most traditional SaaS.

Traditional SaaS companies sometimes look to drive consumption of content, and move their visitors and leads through a specific funnel designed for conversion, which ultimately leads to their subscription.

For developers, you need a more "hands off" approach. They'll want to be completely autonomous with their purchase decision.

Meaning you'll start with providing all the documentation they'll need to solve the problem they're facing on their own.

Then you'll be able to mention your tool (only if it directly addresses this problem). Thus, this step only comes after the potential user has already acknowledged how a tool would make his/her life easier.

And it's only at this point that you can afford to link your software with the issue at hand, showing the value you'll provide vs the other possible options.

During all those stages, the developers need to be free-flowing between looking up your tool and the documentation. They need to dig into the issue to untangle all its intricacies before being ready to consider relying on a tool to solve/alleviate it.

In the case of B2D, or at least PM2/Keymetrics, there are three types of personas you'll most likely target:

1) Developers, the end-users of your software

The developers that need to monitor their app's usage and uptime are the ones who will interact with Keymetrics the most. What's key to understand about developers is that they can become your biggest champions and referrers if they fall in love with your product. So there's a lot to be gained by providing a perfectly tailored solution for them.

2) Product managers, monitoring tech from a distance

PMs don't need as much granularity as developers do. But they'll rely on a limited set of key metrics (suddenly you realize how spot on the business's name is 😉) to assess product improvements from the tech side of the operations.

3) C-level managers, looking to keep costs down and efficiency up

The CTO juggles between efficiency of his/her team, reliability of the app and development costs. So if Keymetrics alleviates this, it's a great way to introduce themselves.

Same with personas, this rule applies to all businesses (that's why NPS exists). The difference here is that developers are more "extreme" in their opinions about a software.

If you provide a good experience, they'll love you for life. If you provide a poor experience, gaining them back will be an almost impossible task.

If you have lost a user and he had a bad view of your product, it's really hard to gain them back. So you better not do the bad thing. You better stay really transparent.

For this reason, anything that remotely ressembles bad buzz can breat your product's reputation in the community.

Hence, social proof is a huge factor in gaining more market shares. That's especially true when communities like Github come with the built-in "starring" system, or npm with number of downloads for each package. This helps to give more visibility to the projects developers love.

Googling things before asking for help is the default behavior for devs. So when they open a support ticket, it's already after spending the time to search for an answer and not finding, so there's already one level of frustration.

Then, if the first contact they have with the support is with a non technical person who will have to escalate the ticket to someone else, it's an extra frustration on your customer.

To avoid frustrating your users, you'll most likely need your support representatives to be technical - it's the case at Keymetrics.

That also means that every support ticket comes with a higher churn risk on this customer's side. That's especially true when your software has other alternatives.

You may think that you're less at risk of churn with a developer software, especially if it's deeply integrated within the app. For example, removing Segment from an app that already sends events and customer's info to other apps thanks to this service would be a huge pain, so you're not likely to even consider it.

But in fact, developer softwares come into play in different parts of the stack. It may be deeply integrated into your customer's stack meaning they'll be less likely to churn. But it could also sit on top of it, like it's the case for monitoring softwares. It's a reasonably limited pain to switch off a monitoring software for another.

The advantage of Keymetrics is that it sits on top of PM2, which is the point of entry for most of their customers.

So you can't really underestimate churn as a B2D SaaS, and need to be realistic about where your software sits in your customer's stack.