Hunting For Very Specific Leads

Sexy headlines of companies becoming overnight viral successes reach our eyeballs every day. But the reality is that a lot of businesses rely on systematically sending cold emails to grow. Quite a few lead finders specialize in identifying “companies between 51 and 200 employees in the automotive industry”. But what if you’re looking for something more specific?


A Small GitLab Integration

I have a productivity tool for GitLab.com and GitLab EE Self-Hosted which assists teams of programmers during their stand-ups. Company size and industry don’t matter – the few programmers that they employ just have to be using GitLab. Let’s try to develop a filter to identify them.

One way to do it is to imagine what people are saying and try to match that. A way that actually works though, is browsing through a thousand threads and learning.

So I set out to learn.

Learning

I started with a simple filter: gitlab. This resulted in over 300 hits per day. Wonderful. My results on one screen, a notepad on the second and a draft of this post on third, I set out to go through all of them. There are two approaches.

Eliminating False Positives

The first approach will focus on what to exclude.

I want to help teams improve their daily stand-ups. Open source projects are irrelevant. And besides, everybody knows, you should never sell to hobbyists. Let’s try to identify, and exclude them.

The first thing I noticed is a bunch of posts by a bot on Reddit:

That little “source code” link? It points to https://gitlab.com/juergens/stabbot, which matches our filter.

Another way to spot an open source project is a link to its issues, e.g. https://gitlab.com/LineageOS/issues/android.

Or to its code: https://gitlab.com/Puffles_the_Dragon/core-software/blob/master/src/coreutils/rm/rm.c or https://gitlab.com/0xnaka/thehelperdroid/raw/master/helplist.txt.

In fact, I realised that all links to https://gitlab.com/ were pointing to open source projects.

My filter thus became:

gitlab NOT `https://gitlab.com/`

It still matches a lot of false positives. But at least I know that I won’t miss anything relevant. Tomorrow I’ll stand a better chance against the, now tamed, influx of posts.


Want more growth tips?

Get notified about new articles by email

Or you can also subscribe with RSS.

Just The Needles From The Haystacks Please

The second approach will focus on specific phrases someone we want to reach out to will use.

As I was weeding out irrelevant hits, the number of my browser tabs with valuable hits kept growing.

Here are a few posts by people who clearly are programmers using GitLab in their day job. I hilighted phrases that, hopefully, will match threads similar to them in the future:

Problem was with authorized_keys file. Find Issue in https://docs.gitlab.com/ee/administration/operations/fast_ssh_key_lookup.html

I am migrating projects to Gitlab.com from a hosted Gitlab-ce

I am working on using GitLab CI/runners to push my site to S3 and invalidate files on cloud front.

I want to store the vendor manually and lftp replace only changed file or new file of this directory (changes only). how to do it? My gitlab-ci.yml command is:

For the ease, I have created a common group runner. My question is, how may jobs can a a single group runner can handle? What is the best runner strategy for having less queue for **CI/CD **?

Hi, we’re using Gitlab CI/CD on gitlab.com with a connected Kubernetes cluster. Until recently, we ran on Azure, but have now decided to switch over to digitalocean.

I find a way to fix it. I had to edit manually the database as in https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4085. First, connect to the database: sudo gitlab-psql -d gitlabhq_production Second, delete the column: ALTER TABLE services DROP COLUMN deployment_events;

Triggered pipeline should contain remote yaml, example: include: remote: https://gitlab.instance.example**/api/v4/**projects/N/repository/files/ci.yaml/raw?ref=REFERENCE&private_token=TOKEN&.yaml […] Tested on gitlab 12.2.4 and 12.4.2

And many more, but we’ll stop here. Let’s assemble our excellent, evidence-based filters:

gitlab \`/api/v4/\`  
gitlab \` 12.\`  
gitlab \`ci/cd\`  
gitlab \`runner\`  
gitlab kubernetes  
migrating "to gitlab"  
\`https://gitlab.com/gitlab-org/\`  
\`https://docs.gitlab.com/\`  
\`gitlab-ci.yml\`

These will have almost no false positives in them, perfect for the busy, although you might miss a post every now and again.


Conclusion

Designing a good filter is never a one-and-done job. If you want it to stay sharp you have to maintain it like you would your kitchen knife. But if you do, you’ll never complain about a lack of people to reach out to again. Your customers are out there, waiting for you to help them.

Theory is nice and good, but now it's time to get your hands dirty Hunt For Very Specific Leads