We spoke to Alan Gleeson, CEO and Co-Founder of a startup called Contento, which offers a headless CMS, about effective strategies you can use to attract developers to your SaaS platform or product.
From Fractional CMO to CMS Co-Founder: My career journey
Before I became the Co-founder of Contento, I was a software consultant for 10 years, and going back even further than that, I was working in banking. But that's a long time ago now.
I worked as a Fractional Chief Marketing Officer (CMO) for probably eight or 10 years. I often helped venture capital-backed, B2B SaaS companies market more effectively. In many instances, they didn’t have the budget for a C-level marketing person, so they'd been relying very much on juniors, and that only gets you so far.
So, I acted as the CMO for a few days a month to help set strategy, allocate resources, hire people, and make decisions about things like the content management system.
More recently, I've left that world and I've started my own B2B SaaS company. I’ve taken a lot of the knowledge and experience from that previous world and brought it into my own startup. Contento is a content management system (CMS) that helps you manage and maintain websites.
The argument goes that WordPress is now 20-odd years old, is beginning to be a bit clunky, and isn't really fit for the current world that we live in when it comes to the internet. So why I shifted my focus.
All of a sudden, developers represent one of the big buyer personas when you look at who buys a CMS, and therefore, I've got to market to those types of people.
If you're selling to consumers, in most instances, you're selling to one person. Maybe big ticket items might have a second person involved, for example, a husband and wife involved in a purchase of a car. But most decisions are for an individual. When it comes to B2B, there can be multiple stakeholders, particularly as the ticket price increases or if the solution spans a few different functions.
For us and your website, it’ll be the marketing function and the development or technology function that’ll be the most impacted. And therefore, developers need to be part of the function that we market to.
Marketing SaaS products to a B2B audience vs a developer audience
I'm a non-technical founder, so there's going to be a big qualification around what I say when it comes to the biggest difference between selling a product to a B2B audience versus a developer. So I guess it's best perceived as an observation from the other side of the fence.
I have a technical co-founder; our CTO is a developer, and I'm sure they’d have a different take on this, but nonetheless, I think it can be valuable for people to understand how C-suite or non-technical people view that kind of landscape.
If you market to a lot of B2B SaaS professionals, whether they’re in the operations function, the marketing function, or the sales function, you've got a fairly similar playbook. It includes things like content marketing, using LinkedIn effectively, or perhaps Twitter, or maybe some direct outreach. You can get away with marketing messages and you can look at creating a funnel.
But developers sit in a different world, if you ask me. They don't tend to be as active in some of those channels. They’re more likely to be on Mastodon, Discord, Reddit, Quora, Stack Overflow, or GitHub.
So, all of a sudden, they're in a very different world. They're not occupying the traditional world that most of the others that you're trying to target are.
They're also very heavily reliant on their community, word-of-mouth referrals, and problem-solving. So you’ll find a lot of Reddit forums, for example, where developers will pitch in with questions looking for help and ideas and solutions. So they're not really going to be taken by a fancy white paper or some blurb online. They're really going to be trying to cut that noise out.
And finally, developers are going to want to try a product. So it's not a case of, “Let's look at a nice PowerPoint and I’m going to listen to you talk for 20 minutes on the feature set.” Instead, it’s, “Give me the keys to the engine, let me kick it around myself and make a more informed decision.”
When you wrap some of those elements together, it indicates that your approach needs to be slightly different.
Contento is in the first year in its build phase predominantly, so we've yet to really engage the developer community en masse. But part of it is that you’ve got to have a really strong value proposition. Your product needs to be really excellent.
Of course, every startup thinks its product is excellent. But it's really, it’s a very high bar because, in many instances, certain categories and solutions will exist already, and you definitely want to be a change in step for them because why else would they consider alternatives?
Developers are a tough nut to crack, but you're beginning to see the emergence of roles that didn't exist 10 years ago, like the developer advocate or the content creators on YouTube, where these independent developers are marrying this world of sharing education, but also sharing their screens.
So, you're getting this hybrid approach whereby they can talk you through something, but you're seeing real-life screenshots and demos.
I think they remain a tough nut to crack, but if you've got a phenomenal product and really clear messaging, you can then market effectively to them. But again, you've got to take on board some of the examples I’ve just shared.
Targeting developers in a saturated SaaS market
There are a few things that people should take into account when trying to market a SaaS platform to a developer. We've tried to tackle it in a few different ways at Contento.
Our logo is a sort of yin-yang symbol, whereby you've got a black and a white shape intertwined, and we're trying to symbolize that there are two dominant personas - a marketing persona and a developer persona.
When it comes to developers, we've got decent docs. We've invested in making sure the docs are clear. We've also got a developer section of the website which is in dark mode, with a toggle.
When you toggle from the marketing mode to the developer mode, you're going from white to black, which again, hints that it's a different sort of approach.
But then, the key point is around how you position, and one of the things that we've recognized is that when you look at headless CMS,’ which is the world we occupy, it's a relatively new concept, but it's been developer-led up until now.
It's a very technical solution, but all the early adopters have been developers, so much so that we actually see an opportunity by being less developer-centric.
So, one of our goals and ambitions is to say, “We're going to tick all the boxes on the developer and tech side of the equation, but we're trying to be a little bit more accessible on the other side of the fence for marketers.”
For example, as a non-tech founder, if I go to the pricing page of a traditional, simple, basic website builder like Squarespace or Wix, it's very easy from a marketing point of view to navigate and understand different pricing tiers. It’s all very straightforward.
But if I go to Sanity or Storyblok or some of the market leaders in headless, I don't have a clue. I don't really understand. It’s all data lakes and composable architecture and webhooks. So I find the pricing pages of those completely inaccessible.
I think it's recognizing that you’ve got to have a great solution, but then you’ve got to take a position that makes you distinctive and clear because nearly every category of SaaS is getting saturated. They're getting very, very crowded. So you then need to make it really clear how you're different and why you're different. They're the elements that you’ve got to work on.
There can be challenges there because people copy features. If one provider brings out a feature that really resonates and proves popular, the others can easily bring it around. So then you're into the whole world of branding and messaging and some of the softer stuff. It's tricky, but it’s very much doable.
If go to the blogs of any of the other headless CMS providers, they're all highly technical and they’re written by lead developers, whereas the content on our site is deliberately written by me for two reasons. One is to keep our developers working on writing code, but also for me to try and break down the barrier and make it easy for marketing people to understand the benefits.
Here's the tricky thing; most marketers in B2B SaaS companies are overwhelmed. It's a really difficult function because the span of activities that you've got to be responsible for is very wide-ranging, from lead gen to managing the CRM, to sales and marketing collateral, to branding, to positioning, to helping with outbound copy, to doing paid acquisition.
When it comes to a new technical solution like a content management system, the bandwidth that you have to explore these new propositions is very limited.
This is why WordPress continues to be popular even though it's deeply flawed as a product; many marketers have been trained on it and are familiar with it, and therefore they're not really interested in switching off, even though it's a deeply flawed solution for growing technology companies.
The balancing act between providing accessible content and satisfying developers
I mentioned that I'm the one writing the content, but a lot of that content probably isn’t targeted at developers because they don’t tend to be on LinkedIn or reading blogs.
It's almost a case of tweaking our strategy a little bit and making sure that we're doing a really good job up to now on marketing channels that marketing people will be on.
We’re neglecting developers a little bit for now, but then we’re dialing up our efforts once the product finally launches, which will be very soon.
And then you're into the world of getting listed on Jamstack and other listing sites and making sure that the development team is beginning to participate in forums like Reddit and Quora, and just engaging in the community, not being salesy.
There are lots of questions that people are posing on these forums, and if you're equipped to answer them, you then run a reputation of being someone that's trying to support the education of that community.
And then over time, we've continued to develop our docs, and the playbook then becomes that little bit more sophisticated. It’ll probably include a dedicated YouTube channel where you’ll have one of the team constantly on camera promoting the latest features or exploring the latest topics.
Those are some of the things that we’ll definitely be looking to do soon.
There was a blog I read once that I think was very informative. It said that your job is to get the reader promoted. So if you look at it through that lens and you assume you can get the reader promoted, how exactly do you do that?
Well, you educate them, you make them understand the concepts, and you make them look good for their bosses. That's a nice way of positioning how you engage.
So, it’s being thoughtful and being helpful, but it's also challenging. The ecosystem is getting increasingly noisy because it's a playbook that all the others are also following.
You can have people with lots of alerts set up so that whenever there are terms related to your area featuring or mentioned on platforms, then they're diving in and trying to follow the same playbook.
There's a lot going on, but you’ve also to remember that B2B SaaS is still relatively young. It's not a mature space, and you can have multiple providers earning a really decent living. It's not a winner takes all kind of category, and therefore, 100, 200, or 300 customers can be a very viable base within a few years to be a very profitable company.
So, I think this VC-backed, winner takes all, “Let's pump huge amounts of cash in,” kind of philosophy is beginning to be undermined a little bit.
I'm all for growth. I'm all for investments. But I think we've seen that there's been over-investment by a lot of vendors in recent years, who are just taking on huge amounts of cash and the market hasn't quite caught up.
It’s interesting times, but if you've got a strong and unique position and a great product, I’m confident you can do a good job of carving out a very viable niche.
The power of developer communities in B2B SaaS
There's definitely a much stronger community sense among developers. And even with what I’ve mentioned about WordPress being an old, traditional approach that's had its day, you can easily get someone who’ll argue the complete opposite because the WordPress ecosystem is paying lots of salaries around the world and has done for 20 years.
There are a lot of supporters of the old approach that would argue, “Alan, you're talking nonsense. There's lots more time for WordPress. It's phenomenal. It's the market leader. It can evolve and it continues to evolve. What are you talking about?”
I think the tech community is definitely one where there’s a much stronger alignment than you'll find with other communities.
Now, I know there are things like the CMO Alliance which are trying to bring marketers together. One of the challenges though, is that the marketing function can be so different, depending on the role and the resourcing and the sector.
You get lots of unique scenarios that crop up that make it difficult to get like-for-like advice on, whereas that's not quite the case with developers or tech where it's more black and white. So that's one of the things with marketing, in particular when you read marketing advice.
What often frustrated me was that a lot of the B2B SaaS content that I read in the earlier years was US-centric. It was written by white males who were between 50 and 60 years old, and who assumed resource abundance.
They had this idea that everyone had got Series C funding in the bank, and therefore had the ability to run amazing tech stocks and have huge teams. As such, it was easy to do attribution and track where every single lead came from.
Whereas, the reality in Europe and the world that I occupied was often Series A or bootstrapped, or pre-seed, or seed level, which is much more resource constrained. And therefore, you had this disconnect.
I do think the tech community is a stronger one, but I think one of the reasons is because your use case can be one that you can share in context, and someone can give you good advice as to how you should approach certain things.
Top mistakes to avoid when marketing a SaaS platform to a developer?
There's this notion of buyer personas, and it’s an important methodology that makes you think about who the different people are that’ll be representative of your buyer personas.
If a developer is one of those, what I'd say is that if there's a development team in your company, it’s important have them help you with some of these challenges.
I can recall the time when I worked with a cybersecurity client and we were looking to talk to developers. Before we did outbound activity, I spent some time with our own developers to help with messaging and outreach. And what was interesting is that they were quite critical of the original drafts that we had made of the content.
They felt that it wasn't likely to resonate and didn't highlight the key features. And they were even more dubious about whether the content and outbound was even going to be effective. So it was almost validating that it’s a different approach that's needed.
I think this goes back to the emergence of developer relations, whereby if you can afford a dedicated resource and create a role where someone acts as a conduit and is technical, but has a goal of representing the brand in all of these communities in a way that’s designed to help people solve problems, rather than to sell in, I think that's a very useful role.
We’ll see a lot more of those roles continue to emerge as companies look to make themselves more aware amongst the developer community.
Going back to an earlier point, you also need to de-risk things as much as possible. If you can give developers free access that's really polished so there's a really strong onboarding process, it's very clear what you're looking to achieve with the onboarding, and they have sufficient time to play around with it, it then you can deliver value early on.
Then they go check the documentation and find that the documentation is robust. Perhaps you're giving free support where you can actually talk to people rather than sending emails in. And then you’re beginning to formulate a community, be it in a dedicated Slack group or Discord channel, so you're beginning to hit in the right direction.
One of the key things for the real early stage startups is that you’ve got to walk before you can run. So you're in a slightly different position whereby you're better off just focusing all your energies on a brilliant product, make sure that some early adopters are advocates, and they’'ll be happy to give word of mouth referrals.
I think your initial challenge will come from word of mouth, developer-led approaches, which then can be supplemented with other activities.
Developers recognise that other developers are time poor, so they're not going to waste any time. It's almost a validation that you're onto something if they're willing to share it and make introductions. That's almost a validation that you're in the right area.
If they're hesitant or reluctant, it's worth the conversation to try and understand what features they think would be important to add in to make your solution more attractive. And then maybe go on a couple of sprints and circle back around.
Then, if you've got developers that have seen features that were probably on your roadmap anyway, but actually live in a product, you've had someone that views themselves almost like as a collaborator. And then of course, they’ll be much more disposed to bringing others on board.
The importance of giving developers the keys to your software
In the old days, when building software, one of the gotchas was that you had companies that didn't bring UI and UX in at the start, and they waited to bring in those experts further on. And in some ways, the product was often pretty embarrassing.
You’d find that on the website they didn't really offer you any visual images of the product. Instead, you saw animated, blurred out backgrounds.
If you have a really beautiful design solution, you’ve got to have big pictures of it on your website that people can see are realistic and truly represent the interface. And you should also have videos that showcase the interface.
Doing a particular task in our instance might be creating a webpage or editing a piece of content, but then giving developers the keys to the car so they can actually go and test it, rather than the old method which might have been a case of hiding the UI and UX, not really showing it on the site, and being very slow and guarded and not giving unfettered access.
If developers really want to have a look at a solution, you’ve got to give them the keys to the car because otherwise, what's the point?
Content management systems have been around for over 20 years. Most developers will be familiar with them, so they'll have reference points, they'll know how to do certain things, and they'll understand how to navigate it when they log in to a new one.
They'll be looking for things like security questions to ensure it’s more secure than WordPress, as well as how the workflows work. Does it look intuitive to manage stuff? Those are some things that they can actually see by interacting with the software, which helps to then inform a decision.
Redefining integrations in headless CMS platforms
On the subject of integrations, it's an API-based approach. So in some ways, if you go back to the old model of WordPress, it was an all-in-one monolithic approach, where you relied heavily on plugins from third party vendors to enhance the functionality.
It's a slightly different approach with a headless CMS. You’re focused on APIs, and the primary API-driven piece is the content being pushed to various heads, which is where the name comes from. Those could be websites or mobile apps or screens in store.
But the whole premise of it is around best of breed solutions from different vendors being blended together. The kind of route it's going down is less what I deem as plugins, and more as constituent elements.