The CloudForecast team and I 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.