Contents

How to market on Hacker News (learnings from Tailscale)

Chat icon
Transcript

Was always wondering how some product posts come up on the first page of Hacker News while most disappear in the abyss of the /newest section.

Actually, I had some of my own posts get to the first page or even the very top. Most of them however, completely bombed.  

Couldn’t really understand why. 

And then I saw one company climb to the top of Hacker News time and time again. 

Tailscale.

After seeing another post “Tailscale Funnel” on the first page I said to myself: “ok Tailscale, let’s see what you are up to”. 

Typed in “tailscale.com” to Search Hacker News and got this:

Wow. 

759 upvotes on your freaking product announcement. 

249 on “how {our commercial product} works”.

Like, come on. We are talking Hacker News here, where people hate promotion. And when I say hate I mean the worst type that comes with no upvotes, no interest, and eye rolls. 

Ok, so there must be some learnings to extract here. Let’s find out what those are.

How to get your product on Hacker News

Before diving into how Tailscale does it, I want to share a few resources I came across while doing research for this article.  

So my recommended reading is this:

But the best resource by far comes from the Hacker News mod himself Daniel Gackle. If you just shoot him an email at hn@ycombinator.com he will happily share his notes with you. 

https://news.ycombinator.com/item?id=30066969

Combining insights from these resources and my learnings from Tailscale, this is how to write posts that can get on the first page of Hacker News: 

  • Create something that doesn't feel promotional. Stay as far as possible from (obvious) persuasion. Educate on the problem you are solving or the technical ways in which you are solving those problems. 
  • Explain benefits through problems. A framework I see is this “problem -> obvious solution-> why an obvious solution doesn’t work -> product -> how it works”. You let people connect the dots and understand those benefits by first getting them to understand the problem deeply.  
  • Create deep new-information-heavy content. No regurgitated listicles will ever make it here. You need content depth that comes from being interested and/or knowledgeable in the subject. There is zero chance to write for devs without either being one or working super closely with one. 
  • Satisfy curiosity, explaining how things work, not “how to gain X by using Y” but rather “How to build Y from scratch”.
  • Write dev-to-dev, conversational. Use technical jargon wherever it makes sense, be very technical. Basically, imagine your dev friends talking shop. Write like that.   
  • Go with to-the-point titles. No “10 secret ways to…” or “gain X by doing Z” but rather “I sell onions online” or “Tailscale Funnel”.

Creating articles like this requires a lot of founder or developer time, genuine interest in the problem, and great writing/communication skills. 

In other words, you need to put in a lot of effort to create something that has a chance. 

And almost nobody does. But those who do, reap the rewards. Tailscale is one of those notable exceptions. 

Let’s go deeper into how they do it (with examples). 

Good post titles for Hacker News

Feature product announcements:

There is nothing “special” about those titles which is exactly what is so special about those titles :). 

Zero fluff. 

No “speak to benefits” and “How Tailscale SSH makes XXX faster”. Just “Tailscale SSH”.

If anything, some titles speak to one of the core intrinsic motivations of devs on Hacker News: curiosity. “Making an SSH client the hard way” or just “How Tailscale Works” are about exactly that. 

So the Tailscale titles are probably not the secret sauce that gets them to the top. But at least the HN community doesn’t discard them as marketing fluff right away.

That is a good start, let’s look into the posting logistics.  

Who should post and when?

Figured I’d check whether there is something special here. 

Are they posting at special times, or from special accounts? 

Didn’t see anything interesting. Doesn’t seem to matter much. 

Typed https://news.ycombinator.com/from?site=tailscale.com

What I saw:

  • Multiple postings of the same thing (and sometimes one worked)
  • Different people posting
  • No “company” account at least not obvious to see
  • Didn’t see anything clear when it comes to karma: dartShadow with 731 worked and tosh with 125668 didn't. 

Not much. 

That is a good thing to know, as it means you should focus your energy elsewhere. 

The article itself. 

How to write articles for the Hacker News dev audience

I went through the following Tailscale articles that ranked high:

And there are some clear-as-day indicators of why this is working:

  • they jump straight to the topic, zero-fluff intro
  • they explain benefits and products through problems and obvious (not working) solutions
  • they explain how things work deeply, technically, almost “giving away” their solution. This appeals to the curiosity of devs on HN.  
  • they create deeply technical content, impossible to write by a non-dev marketer alone
  • they speak in a friendly dev-to-dev: technical jargon-heavy, conversational tone.

Let’s go through these points one by one. 

Info-packed introduction

Let’s get one thing straight. 

Most article intros suck because they are either:

  • speaking to vague
  • speaking to deep
  • speaking to many reader personas at the same time
  • making it understandable to everyone

Tailscale’s articles intros are great. They really speak to only one group: devs who know how networks work.  

By assuming that, they can build trust quickly with their ideal reader. 

They can cut the fluff that is obvious to their ideal reader.

This is good copywriting 101. Focus on one reader. Imagine yourself reading this intro/article to that one reader. Imagine that person listening. Do they nod their heads, chuckle, or eye roll? 

So when creating content for developers create for them. Not their bosses, not yourself, developers. Most marketing writers fail at it. Tailscale does it really well. 

On top of that they do three interesting things:

  • they mention their company by explaining what it does to set the context for new product/feature
  • they go straight to the point, the feature/product, zero fluffs given
  • they really say what the product does, technically, so it almost feels like a spec document, not a product launch article

It seems that they assume that “every page is page one”. Or that people who come here may not be familiar with Tailscale and it shouldn’t stop them from easily understanding where they are and consuming the content. 

So they start by mentioning the company and something they do. 

What it does is:

  • sets context for the reader
  • makes it explicit/transparent that there is a product
  • makes it easy to navigate -> if devs want to learn more about Tailscale they know where to go

  Take a look at these examples:

They mention the company and what it does in relation to what the article is about briefly and then jump into action. 

They transition to details quickly. 

No long mission statement stories.

No lists of what imaginary business people or enterprises need today. 

Straight to technical details. And when I say technical, I mean it. 

Just look at these examples:

‍

Speaking of writing technically.  

Jargon-heavy, dev to dev, writing style

You often hear copywriting advice like “write so that even your grandma understands”. I said it before and I say it again, this advice is really bad. It is especially bad when it comes to the dev audience. Unless your grandma is your target audience that is. 

Tailscale is an example of a company that breaks this “grandma rule” all over the place and doing great. 

You should speak to your audience in the language that they use to create trust and rapport. To resonate. And since “devs only really trust other devs” it is even more important to speak this way with the dev audience. 

Here is what I mean.

As someone who doesn’t know much about how networks work, I am completely lost here. And that is ok. Make it interesting for people who do get it. Not for everyone. 

One more example to drive this point home:

If I am a dev who “gets it”, you are not wasting my time explaining the things that are obvious to me. You are sharing new and interesting information.

To do this kind of thing you need to know your developer audience, there is no way around it. Simple but not easy. One quick shortcut is to find a dev on your team or network who is that target audience and run your content by them. 

Ok, but style and tone are one thing. The message you are communicating is even more important.   

They write deeply technical content

There are many examples of them going deep technically. Just open any article from them and you’ll see. 

At times it almost feels like reading docs or a technical feature spec. 

Developer audience in general likes it (and probably your developer persona likes it too).This is what you want your developer content to become when it grows up.

Writing this way makes it feel “non-marketing” and because of that, your message can actually get through. 

But deeply technical doesn’t have to be bland and serious. 

They write in a friendly and conversational tone 

What I really like about Tailscale writing style is that it is very peer-to-peer and conversational.

No third-person talk. You won’t find stuff like “enterprises need streamlined 360 security”.  

You will find things like:

  • “ it usually works dangerously well until administrators turn it off”
  • “That’s two Nats, no open ports” 
  • “Started out as Brad’s vacation hack to see if Go’s WebAssembly support was good enough” 

They tell those interesting, technical, real-life stories. What’s not to love?

They even go a bit snarky, especially when talking about potential solutions or their product.  

I think it helps disarm some “oh this is a promotion not a technical education article” feelings that devs may have when reading. 

That said, they do talk about products, features, and benefits a lot.  

But they do it through deep problem explanations. 

They explain benefits through problems and solutions

You’d often hear in marketing:  “Talk about values and benefits, not features”. (btw, I wrote another post about creating dev tool value propositions that dives deep into this).

The “Why” is more important than “How” and “What”. 

Well, it is sort of true but packaging it for devs hardly ever works. 

You end up with either high-level fluff or too low-level spec. The magic happens when you balance it.  

But folks who write for Tailscale do something beautiful here. 

They use some version of a classic AIDA (attention, interest, desire, action) framework adjusted to the dev audience. 

Let’s call it a “problem -> obvious solution -> why an obvious solution doesn’t work -> their product -> exactly how it works technically” framework. Or “POSWAOSDWTPEHIWT” for short :). 

They create the following conversation with the dev reader:

  • Problem: Introduce the problem with gory details to make a dev feel it (Agitation)
  • At that point, most devs reading this have one or more obvious solutions in mind
  • Obvious solution: They meet the readers where they are and list those obvious solutions
  • Why obvious solution doesn’t work: They then explain why those solutions didn’t work for them or wouldn’t work for the reader
  • This gains the trust of the reader who sees that the author has something to add to this. That the author knows what they are talking about. Starts building rapport. 
  • Introduce their product: Then they introduce their solution.
  • At this point some devs will think: “I kind of get it and could build it myself” 
  • Share how it works exactly: Again, they meet the readers where they are and explain the solution with technical details. 
  • The “how it works” makes it obvious to the reader why building it doesn’t make much sense. and using the product seems like a better option. 
  • Action: Doesn’t have to push for action as the decision is made by the dev reader. 

I am against persuasion when marketing to devs, but if you can pull something like this off, go for it. Also it is “just” a classic AIDA framework adjusted to the dev audience.

Truth be told this is actually a deeply technical problem education, right?

To see this in action, you’d need to over entire articles, like ”Introducing Tailscale Funnel” for example. But I want to show you parts of it with a few examples. 

Let’s start with explaining benefits through problems: 

You don’t have to spell out the benefits of not having this pain when someone feels the pain. But to do that you need to agitate it in the words and situations that the reader actually can relate to. For devs to get to those “feelings”, funny enough, you need get technical.

Now see how they talk about obvious solution not working:

You could say it is the same as problem agitation, and yeah, same idea. Make the reader feel it.

And here a lot of those principles packed into a longer intro

The last magic part I found was this deep explanation of how their solutions work. 

Let’s dive into that. 

They really explain how their solution works

No, not just what it does or what benefits it brings. 

How it works. Nitty gritty technical implementation details. 

And this I think is a crucial thing here. They take a ton of time to make this knowledge available to the public. They make it transparent. 

Why is that important? 

Well, they are not open-source and devs feel comfortable with open-source. 

So how do you handle this “I don’t like closed source code” problem?

You explain to them how your solutions works, you show them that your team knows what they are doing. You build trust by being transparent. 

Check out this one:

They go into a lot of technical details so that you really understand how they solve the problem. And what it would take for you to implement it. They present their expertise in the subject. 

And you are slowly but surely gaining your trust. As they should. 

It is a version of the “developer content mind trick” that Adam DuVander talks about. You tell people how to build your product and by the time they read through your how to, they understand why not building it themselves, and likely buying from you is a smarter choice.  

By the way, they even have a post “How Tailscale Works” which was one of the more successful HN posts. So yeah if you feed this “curiosity bug” that devs have (Hacker News devs in particular) you can really build reports with people. 

But if you do go for a post like this, explain it, really. 

Final thoughts

So here you have it. It is simple but not easy. 

Takes technical insights and audience understanding. 

But it is doable. 

Follow these principles and you’ll be do well on Hacker News but in any developer-focused communication:

  • Create something that doesn't feel promotional. Stay as far as possible from (obvious) persuasion. Educate on the problem you are solving or the technical ways in which you are solving those problems. 
  • Explain benefits through problems. A framework I see is this “problem -> obvious solution-> why an obvious solution doesn’t work -> product”. You let people connect the dots and understand those benefits by first getting them to understand the problem deeply.  
  • Create deep new-information-heavy content. No regurgitated listicles will ever make it here. You need content depth that comes from being really interested and/or knowledgeable in the subject. There is zero chance (imho) to write for devs without being one or working super closely with one. 
  • Satisfy curiosity, explaining how things work, not “how to gain X by using Y” but rather “How to build Y from scratch”.
  • Write dev-to-dev, conversational. Use technical jargon wherever it makes sense, be very technical. Basically, imagine your dev friends talking shop. Write like that.   
  • Go with to-the-point titles. No “10 secret ways to…” or “gain X by doing Z” but rather “I sell onions online” or “Tailscale Funnel”.

See you on the first page of the orange page!

Hey, I am Jakub Czakon. CMO at a dev tool startup, dev marketing advisor, admin of a dev marketing Slack, and creator of the dev marketing . I share insights from my experience, research, and talking to other practitioners.
Hey, I am Jakub Czakon. CMO at a dev tool startup and a dev marketing advisor.‍