Everybody who touches our codebase also communicates with our customers. That’s very deliberate. That’s by design. Some of these guys aren’t necessarily comfortable with that, or they weren’t when that began or when we started doing that. But I basically just created accounts in our Intercom, we use Intercom from all of our customer communication. I created accounts in Intercom for our developers and I always, whenever I can, a lot of times I’m travelling business so I can’t, but whenever possible, I man the frontline support.
Jay Gibb is the CEO and Co-Founder of CloudSponge, a contact importer for email referral forms. CloudSponge has two technical Co-Founders, 25 developers supporting the company and no Sales or marketing teams. Yet they’ve achieved initial traction, growth and are now a self sustaining company with no requirement to raise outside capital to help them grow.
Jay spoke with me on The SaaS Revolution Show podcast, where we talked how being an engineering/developer led SaaS Startup has driven company growth. A super insightful case study for SaaS Startups at the traction and growth stage.
How one SaaS Startup uses engineering to drive growth – with Jay Gibb, CEO of CloudSponge by The SaaS Revolution Show
In this episode of The SaaS Revolution Show, we take a look at CloudSponge and how they’ve utilised their development workforce to drive company growth. Jay Gibb, CEO of CloudSponge steps into the guest hot seat and provides a case study of his startup that is a must listen to for those looking for insights into growing their SaaS Startup.
Jay, can you tell us more about CloudSponge?
The simple way to say it is that CloudSponge helps companies with user acquisition specifically focusing on the email referral channel. Our clients have an email referral channel. They need help making sure that more people get through that channel. Those who do get through invite more of their friends.
We have a self-service product that companies can subscribe to. If they want to do the integration and the split-testing and analytics, reporting and iterations and all that stuff themselves. Then we also have a full-service consulting relationship that we can engage in for companies that would rather have us handle all those things and be accountable for the results.
Would you classify CloudSponge as a startup?
Actually, I don’t really know what the definition of that word is anymore. I think of us as a startup. I think there are lots of companies that are much, much bigger than we are in every metric and that still call themselves a startup. So I think we’re certainly a startup. That’s the way I think about it anyway.
When was CloudSponge formed?
Technically, 2009. We did a couple of pivots since then but we’ve been a company, an entity since 2009 and working on getting better at solving this problem for about 6 years now.
How are you funded? Are you bootstrapped or have you taken VC money?
Neither of those. It’s kind of in-between. CloudSponge is very similar to the 37signals story where their Basecamp and Campfire and those products came out the 37signals Agency.
In this case, CloudSponge is a by-product or a product of my agency with my partner called Arizona Bay. That company has been around for about 15 years and we’ve done all kinds of projects for all kinds of clients over that time.
At one point in 2007, I believe, we decided we’re going to make an effort on investing our profits, our income from the agency into our internal projects. CloudSponge is one of those projects. I’m not sure if that fits one of the two options you gave me there.
Do you have a co-founder?
Yeah, that’s right. So Arizona Bay is two of us. I think there are now about 25 developers that work in Arizona Bay. That’s the team that backs CloudSponge. But my partner and I are co-founders.
Your background is as an engineer and therefore going into CloudSponge you were a technical founder. Has your commercial and business acumen come about by founding this company and being CEO?
Yeah. I think so. Before I started really working on the CloudSponge product and the other things that the agency funded at that time, I consider myself an engineer, a developer, a product designer for the most part and so for the last 5 or 6 years I’ve developed that business acumen, as you put it.
From our prior discussions, it’s apparent that engineering has been a real cornerstone of the business. Responsible for driving company growth. I guess that’s because you’re an engineer yourself so you’re playing to your strengths. Would you say that’s kind of one of the reasons that engineering has been so important throughout the departments within the company?
I think so. It’s my comfort zone, for sure. It’s what I fall back on. And I’m mostly surrounded by engineers, by highly technical individuals. Yeah, I think that’s a big part of it.
Also, CloudSponge initially when for the first couple of years, it was from a marketing positioning perspective very much targeting engineers. That was part of the whole learning experience of business acumen that we just mentioned. But yeah, we were kind of “By Engineers, For Engineers” kind of mentality. We were solving a problem that engineers had for the most part.
Now, we started to reposition a little bit but, for the most part, we do still have a very large segment of people that are interested in our product are people that are searching for technical solutions to problems they’re solving.
Let’s dive into that a little bit deeper then in terms of how engineering has been so important for CloudSponge in driving company growth. Let’s look at marketing first. CloudSponge got its first traction through developer-first marketing. Can you tell me a little bit more about that? What is developer-first marketing and where did you do this and what were the results?
Sure. That was really part of our initial traction like our first, going from zero to 100 customers. Again, we’re kind of just staying in our comfort zone which was engineering. We were solving a problem that we knew about. As we were working through that solution, we just noticed that there are tons and tons of other developers who were asking the same questions that we had on Stack Overflow primarily. But also like in other developer forums, on specific places like Google Forums and Yahoo Forums and other places like that. But Stack Overflow was kind of a whale.
Then the more business-oriented people, sort of quasi-technical or marketing and sales and product management people were asking similar questions in a non-technical way on Quora. There were lots of open-source GitHub projects and things like that to participate in. So we basically just got involved. We spent our time answering questions.
Whenever it wasn’t too shameless, we would mention what we were working on. We would mention CloudSponge if it was actually the answer to their question. But that wasn’t always the case. Sometimes somebody just needed some help and we knew the answer and we’d answer their question with the CloudSponge email address that they might see if they looked, but not actually explicitly mentioning the product.
But over the course of 6 months or a year, we ended up answering dozens and dozens and dozens of questions on those platforms for people. That really drove all of our initial traction and our initial customers came to us through that channel.
And that was a deliberate strategy? You had the understanding that if you went to Stack Overflow and if you went to Quora as well, on a daily basis, and took part within those communities answering questions, that you felt that this would be one of the channels to really drive growth for the company.
Yeah, totally deliberate. We used their notification systems to make sure that we knew whenever somebody asked a question that had our keywords in it. And we had like Google Alerts and other alerting systems set up so that anytime somebody was talking about these topics, we were aware of it and we were alerted to go and get involved.
Did you experiment with lots of different marketing channels? Gabriel Weinberg’s book, Traction, is about a startup getting that initial traction and lists something like 17 or 18 different marketing channels. But what you should really do is try and find that bullseye via experimentation. Find the one that really works for you and then go deep.
So did you look at 17 different different channels or did you stumble upon these developer communities, found that they worked and went with that?
Gabriel Weinberg’s book and his Bullseye process is something that it’s newer than this. We didn’t have the luxury of having that book. Now, when I read it, I’m able to fill in a bunch of blanks. I’d be like, “Oh, yeah, cool. We did that. We did that.” Those are things that he’s sort of reverse explaining what we were able to do. In our case we didn’t have the expression “Engineering is marketing.” That was one of his 19 chapters, Engineering is Marketing.
Most of the other things, we did a few experiments accidentally in those things but not nearly in like a nice, organised, analytical, deliberate way like he suggests. But engineering is marketing was clearly something that was going to work for us. It was really obvious it would work. In our case, that meant building plug-ins and extensions and add-ons for platforms like WordPress and Heroku and things like that.
There’s a guy in New Relic. His name is Cooper Marcus and he’s a really helpful guy. He’s got lots of resources out there where he’s shared publicly his playbook for a big long list of places where you can build extensions and plug-ins and add-ons for products like ours. So we were able to just use our engineering staff to basically, rather than having everybody always working on our product, we allocated some time for them to go out and build marketing assets in these places and build add-ons and plug-ins and so on.
And each of those things pays dividends forever, basically. You put in a little bit of effort, maybe a week or two, sometimes a couple of months of effort for something as intense as Heroku and those assets just keep paying dividends forever and ever. And you just start to build up a really big base of incoming, inbound leads from all those different sources.
Can you provide some data points from these engineering growth hacks?
I actually share one that it wasn’t actually my team that built this particular one. It was like a volunteer from our community. But it’s still the same basic concept.
So for WordPress, anybody who’s using WordPress to build a product that’s like a social network is probably using a WordPress plug-in called BuddyPress. For BuddyPress, there’s a plug-in that’s kind of like 2 degrees of separation for WordPress is a plug-in called Invite Anyone. That plug-in when you install it, in the Administration panel you’re able to paste the CloudSponge license key if you want to enable the ability to let your users upload their address book, the same way that you can do it with LinkedIn and Facebook and these other bigger social networks. If you want to have a feature where you can let people upload an address book to connect with all their friends who are already there and send invitations to their friends who aren’t already there then that’s how you would do it with BuddyPress.
That was a piece of software that was built by the manager, the guy who owns the Invite Anyone plug-in years and years ago. I don’t even know now. Maybe 4 years ago. It was pretty early on for us. And that thing still drives a meaningful amount of traffic to us all the time. I don’t actually have the stats and metrics at my fingertips for you, but suffice it to say that it moves the needle for us still to this day.
You’ve had success with the online developer community in Stack Overflow and GitHub and Quora. What about offline? Have CloudSponge utilised hackathons or meetups?
Not yet. That’s not to give Gabriel Weinberg too much press here. I’ve recently read his book a second time and he’s really inspired us to do some experimentation. Let’s move it out of our comfort zone and just stuff like that.
Coming up shortly, I think it’s November 13-15, there’s a startup weekend here in Pasadena where I work out of and we’re going to sponsor that startup weekend. It’s our first experiment.
It’s an offline sponsorship. That’s really we’re just kind of following the Bullseye playbook here and we’re going to do an experiment that costs less than $1,000 and takes less than a month and measure it and see if that’s something we should be doing more. We haven’t done a lot of offline stuff but we’re definitely open to trying some new things.
When did you hire your first sales person?
We don’t have a formal sales team or sales person. My CTO and I handle the sales ourselves.
CloudSponge is still founder-led sales organisation and you’re both technical co-founders as well. How then are you utilising your technical skills to drive sales?
So there’s a few things there. One of the things that’s become very important is we’re dealing with sensitive data. People’s address books are very private and they care about them. And companies that are considering using like a product like CloudSponge they care a lot about our processes and our security practices and our infrastructure and the way that we handle this data. So we have to get involved in those sales conversations in a really deep, technical way.
Any other company as we move up market and we track more sophisticated groups, there hasn’t been one sales call yet where there wasn’t a security person on call. They care. As they should. So we really get deep. The value proposition of CloudSponge is really easy to explain and we don’t spend a lot of time helping people understand why they should buy it or why they should use it. We spend probably 80% of our time on those calls under the microscope answering questions about our security patch in our infrastructure, going through legal to make sure that everybody’s covered as far as liability is concerned. And so really they end up being very technical calls where CTOs and CSOs or security staff are grilling us the whole time.
How has engineering helped CloudSponge across the rest of the organisation?
We do it in all those places and I think really the clear way to think about it, in my world anyway, is removing layers of abstraction between the customer and the people that are actually developing the product, if at all possible, is a really healthy thing to do, I found.
A couple of places where that manifests itself in the CloudSponge context is customer support and product design. They’re both very connected when you only think about it from the customer development perspective. But we don’t have layers of abstraction. We don’t have like a support guy that’s sort of handling support and escalating to development and being a proxy between our customers and our developers.
Everybody who touches our codebase also communicates with our customers. That’s very deliberate. That’s by design. Some of these guys aren’t necessarily comfortable with that, or they weren’t when that began or when we started doing that. But I basically just created accounts in our Intercom, we use intercom from all of our customer communication. I created accounts in Intercom for our developers and I always, whenever I can, a lot of times I’m travelling business so I can’t, but whenever possible, I man the frontline support.
I’m the guy who’s answering as many questions as possible and deflecting from the team and delegating accordingly. But I’ll delegate to anybody. I’ll delegate to any developer in the whole team and basically make them own a conversation with one of our customers or one of our would-be customers who’s kicking the tyres, especially if it’s a customer who’s reporting a bug.
And so a lot of companies will have a process where the customer will report a bug and then we’ll try to recreate it and insert bug into GitHub and kind of go through a whole bunch of layers of abstraction before a developer actually sees it. In this case, I just remove all of that and I just give that customer straight to the developer who’s going to fix that bug. It takes away a lot of inefficiency and it actually is a good culture builder. It’s a good way to get these guys really owning the customer’s problem and feeling accountable to solving it.
And they’ll push their own like pull requests through and they don’t have to necessarily worry about the development lifecycle and the process when it’s really a customer that they’ve promised they’re going to fix something. They really want to take ownership for that and they get it out there. They make sure it works and they recreate that bug.
Even though they’re much more expensive than what I could pay for a low-cost somebody to man like the support channel, I find that it pays off in terms of efficiency and culture building in a way that it’s obviously worthwhile.
What are the tradeoffs for being a developer-run/engineering-led company? Are there any?
Yeah, there certainly are and I’m sure everybody listening they’re already thinking about them. One of them I just mentioned. Developers are expensive. They’re 2 or 3 times more expensive than a lot of kinds of people you can have when it comes to these things, especially in the Bay Area in California. Like I said just now, I think it pays off in terms of removing all the inefficiencies.
The other thing is really that the management is careful to try this is context switching. Developers, everybody knows that it takes a certain amount of time to get in and out into flow and then when you break that flow you’re creating all these overhead for somebody. And that’s a real thing so really it makes sense to create some kind of safe, timebox period for developers to get out of whatever product, problem with product development they’re working on into other things like in marketing getting out on Stack Overflow or getting involved in the sales call and getting some support. You got t do those things in a really organised way and make sure that their primary job function is their priority. You don’t want to be spontaneous with them.
That’s one of the tradeoffs. But there’s definitely ways to manage that and make it a pretty minor tradeoff.
You previously mentioned using Intercom for customer support. What are the SaaS tools that you use for sales and marketing/other departments?
Yeah, sure. So for outreach like things that aren’t just internal tools, GitHub and Gists are huge. We use them a lot. We get into a lot of codebases out there and a lot of open source stuff, we write a lot of code for our customers and create big libraries and Gists. We have public API wrappers written in all the popular program languages out on GitHub. It’s also a great marketing channel for us since we have a lot of developers that want to use our product. So that’s a big one.
Slack is huge for us. I’m actually considering an experiment similar to the one that you just started. I’ll let you talk about it if you want to.
I’m thinking about an experiment of using a Slack channel publicly and make one that’s not just an internal one for our team. So our customers can sort of cross-pollinate, talk to each other and get involved in more of a community atmosphere.
I’m addicted to Zapier. Zapier is just so powerful, so interesting. My favourite tools nowadays are Segment and Zapier, I think, with Slack and Intercom. But Segment is really great for me because it allowed me to once we had the Segment snippet installed on the site, it allows me just to experiment and turn on and off other SaaS tools and see if I like them.
I used it to do a bakeoff between KISSmetrics and Mixpanel, for example. It’s really easy to do that without any extra work by the developers. We use it to try out like Crazy Egg and Inspectlet and all these other tools.
Then when those tools don’t really do exactly what I want them to do, I can usually find a way to use Zapier to get things working together, complementing things together in a way that’s interesting for us. Be able to pipe notifications from different tools into our different Slack channels and so on.
I would say like anybody who’s starting out now and they’re wondering what tools, definitely start with Segment and Slack and Zapier. And just with those three guys you can kind of do everything from there because you’re able to branch out in a really organic way without feeling like there’s this huge Barrier-to-Entry to trying out new products and getting them to work in your company.
What has been the secret to your success to date?
I think I’ll just use what other people tell me about myself as an answer just because clearly something that I’m putting out there, is patience. I’m a really patient guy and sometimes it takes patience, I think, to make the decisions. I find a lot of people that I work with are in a big rush to make a bunch of money or to grow really big or to do whatever it is they’re doing. And sometimes being in a big rush is just a bad call. Bottom line.
I’ve been told by lots of people that I’m an exceptionally patient person, and maybe to a fault. But as far as the things that I consider my successes, everything from my relationship with my wife to the successes I’ve had with my business are all things that required a ton of patience. So I’d put it on that. Anybody who feels like they’re not a patient enough person should give it a shot.
Never miss an episode. Subscribe to The SaaS revolution show podcast for more insights, inspiration and actionable learnings for SaaS Startups.