GitLab CEO Sid Sijbrandij About Growth Strategies And Common Marketing Mistakes In SaaS Companies

The CloudForecast team recently had a chance to do a “Pick Your Brain” session
with the CEO of GitLab, Sid Sijbrandij. The range of topics included, keys to
marketing to developers and growth strategies.

The full interview can be found below this post. Here are a few highlights from
the conversations:

What are some common early mistakes that you see software service companies make with marketing. Which one did you personally fall for? Are there any specific things you can think of with developer marketing that you see that works really well?

You have to trust yourself that you understand your audience. For example, I
post a lot on Hacker News and I saw that as a hobby of mine. I’m seeing the huge
effect it has on people being fans of GitLab through my posting on HackerNews.

Not measuring is a pitfall. If you do any marketing actions you want to make
sure you measure what the effect is. It’s important to figure out ways to
measure those marketing actions effects.

Examples: What is your qualification criteria? What is a marketing qualified
lead? What is the accepted sales accepted opportunity?

Another pitfall is only focusing on the number of leads. If you are only focused
on the count, you’ll get a lot of small opportunities. It’s important to mix in
the total size of pipeline opportunity.

Are there certain themes that you see that resonates with developers with content marketing?

I’m a big fan of HackerNews, so I am biased
towards that. If you read something on HackerNews, it’s because you want to
learn something. There will be a lot of lessons and stories to tell as you build
out your product. These lessons and stories are things you tell your
co-founders, “Hey! This is interesting and this was the effect.”. Writing and
telling those stories in a public setting is an underserved market. I’ve found
that they are mostly done by hobbyists. I find that too many companies want to
present company pitch in their post.

Telling about a hard technical problem that you solved, or something that
totally didn’t work as you intended tends to be more interesting for developers.
It’s very relatable and you feel like you’ve benefited from someone else making
a mistake instead of you making the mistake yourself. That’s a gift that just
keeps on giving. Try to keep it to topics that you discuss with developer
friends when you grab a beer together.

How did you measure what was successful in your early days at GitLab with acquiring customers?

We followed the revenue and tried different things really quickly.

We tried many things at GitLab in the early days. We tried to sell support.
Nobody wanted that. We tried donations. We got it to grow from seven dollars to
less than a thousand dollar a month. We tried paid development but it was super
hard to coordinate. Then we tried licensed software and that went bananas
compared to the rest. We also tried different things with our price with testing
a higher tier and then people bought that. Then we tested another tier that is
even higher and that worked well too.

You all really tried a lot of things. How quickly did you all go from one idea to another?

We hopped from one idea to another pretty fast in the early days. For example,
we tried donations for two months before moving on. What they advised us
at YCombinator, an incubator program we went to, is to set a metric to destroy
and try to prove it. Our metric at GitLab was to increase revenue by 20% every
two weeks.

That really keeps you honest. If you can’t do that, then you have to make a
dramatic change with your product. It’s also great because you might think that
any change should take at least three months to implement. If you are forced to
execute a change in one week and need to have the revenue to show for it after
the two weeks, you start taking all these shortcuts to try to make it happen.
These are not bad shortcuts, but good shortcuts since you’re trying out things
very fast and learning.

Are you paying the price for all the shortcuts? Example: Needing to hire more engineers or putting more engineer resources to fix tech debt , or working with clients to fix things due to the shortcuts that were made.

Not really! You’d think that. We don’t take shortcuts with things like code
quality. We do take shortcuts with the scope of a feature. It’s sometimes
embarrassing with how much we cut scope. For example, we now have a Jaeger
integration, which is a new cool tracing methodology. The integration is you can
put in the URL and it will link to to Jaeger. It’s a trivial feature but it was
a bigger thing. We only had time to ship a basic version of it.

Another good example is introducing a new pricing plan. You can make changes to
your pricing page to see how it converts. You can also take out some ads and see
what click thru rate is with different pages or do interviews with relevant
people and ask them what it is worth to them. We’ve always had these huge two
months plan but we cut them down in scope. This still gave us feedback but in a
lot quicker way.

We define scope based on how much time we have and not the dream vision.

Did you feel like your growth strategy kind of evolved a bit to stay in line with your product and vision? Like how did that change a little bit from your early days to what it is today, over the last eight years?

Again in the beginning we always said, “Hey the majority of the world isn’t
using GitLab yet. So, we’ll optimize for everyone not using GitLab.” That meant
that we had to greatly expand the scope of our product in the beginning which is
pretty controversial. That has worked out really well for us because now that
the scope is so big, people now see the advantage of a single application for
the whole devops lifecycle.

Prioritization is getting harder now that we are bigger. It was whatever
features we thought were needed in the early days. Then you get your first
customers and you focus building features for them. We had one customer where we
built everything they asked for. It turned out to be a really good thing because
everyone else was asking for the same features later. Now we have this mixed bag
of features that needs to be refactored into new features or new features that
need to be extended. An extension of scope.

The most useful thing I can tell you is to have a single person that determines
prioritization of features. At GitLab, product manager’s makes all final
decisions on features. If you don’t agree, you can always talk to the product
manager. We have certain guidelines with how they should make decisions. You
don’t want the decision be between 10 different people.

Any blogs or writers that you recommend that you personally enjoy reading and enjoy kind of looking over whenever you get a free chance?

The blog of Ben Thompson is great. If you’re
starting a SaaS business, I would read Predictable
Revenue
by Aaron Ross.

Any final advice to SaaS companies in the dev tool space?

I think VC’s don’t like to invest in dev tools because it’s notoriously hard to
make money. If you make a dev tool, make sure it’s a broad product. If it only
has a single feature then you’re just selling a C.I. and it will be very hard to
make money.

Thank you to Sid and the GitLab team for setting this up. GitLab is a single
application for the entire software development lifecycle. From project planning
and source code management to CI/CD, monitoring, and security. For more
information on GitLab, please visit their website:
www.gitlab.com

Want to try CloudForecast? Sign up today and get started with a risk-free 30 day free trial. No credit card required.