Many startups post articles to Hacker News in the hope of getting the community's attention. Most don't get far. They're either about topics that HN readers don't find interesting, or they're structured in a way that loses the audience. It's dismaying to see these because I can feel how much work people put into them and how disappointed they are when they sink from the /newest page without a trace. What a waste! Below is a bunch of advice I've given to YC startups who've struggled with this over the years. The bulk of this article has been copied from old emails. Eventually I'll wrangle it into something publishable. Before that, though, here's one point that is worth more than all of the below: if your post reads like marketing or feels like an ad, don't bother. Not only will HN readers reject it, you'll train their immune system to reject you. You'll be in the hole, worse than if you hadn't posted anything. In the HN state machine, the end state you most want to avoid is "This is just an ad." What reads like marketing? Anything written not for its own sake, not because you personally found it interesting, but to produce something you hope other people will like and then do what you want them to do. This is the kiss of death on HN. Our readers smell it in the parts per million. Their fingers twitch on the 'flag' button just waiting for it. Don't do this! It won't work. What to do instead? The people who actually did the work should write about what they did, and they should write what they personally find interesting. Intellectual curiosity is the currency of HN. You can't fake it, nothing can substitute for it [1], and you can only be sure you have it when you yourself personally feel it. When you genuinely feel curious, it's contagious: the reader will resonate at your frequency and may get curious where they'd never have bothered before. It's also contagious when you don't: readers quickly pick up that it's all just a means to an end (trying to snag them as a customer, most likely). If you don't really care about the material, why should they? Don't try to substitute for this by talking *about* how interesting something is--you need to show, not tell. For this, what matters is your own personal relationship to the material. On HN, communication that works is peer-to-peer. Don't write for some abstract customer or user that you hope exists out there. Nobody talks to their friends the way they would talk to customers--it would come across as fake, and that's how it comes across when you write that way for HN. Your readers might *become* customers or users, but you won't get there by talking to them that way. On HN, if you try to sell the reader, they will get bored and close the tab, or get annoyed and start poking holes. Instead, you should *interest* them, then let them sell themselves. Write for yourself or, if you like, imagine a friend that you're meeting up with for drinks, who has no idea what you've been working on, but is smart, curious, and asks good questions. Never try to wrap a shiny surface around your messy reality; that is the essence of bad marketing on HN. HN readers want an *inside* view--behind the curtain, under the hood. They can feel it when something's hidden from them, and they hate that feeling. Find something interesting *within* your messy reality, then express it in a not-too-polished way. Your messy reality is much more interesting than any shiny surface. Simply not making this mistake will put you in the 90th percentile of interesting on HN. If you're the kind of startup that is able to digest the above and write this way, email me at hn@ycombinator.com so I can recommend that you apply to YC. [1] There's also outrage, but I don't recommend playing with those chemicals. --- Ok, here's the advice copied from emails. --- This is a good article, but there are two big limits to its appeal: it doesn't motivate the reader, and it's more of a tutorial than a story. Walk the reader into your world Your article needs to motivate the reader by introducing yourself and the problem. When you assume that people know who you are, what you do, and what problem you solve, your article will only make sense to readers who already know these things. The larger audience, which doesn't, is cut out from the start. In person, listeners who don't understand will nod politely until they can leave. But on the web, they just close the tab. Readers have an early warning system called "why should I care", and your success depends on getting signals on that radar. Actually there are multiple "why should I care" hurdles that you need to clear, and they start kicking in a second or two after someone clicks on your link. Two major ones are "who are you" and "why is this interesting". Who are you? We've learned a rule from HN: no matter how often you've said something on the internet, the set of people who heard it has measure zero. There are always many more who never heard it or forgot. So follow a stateless protocol: with each message, bootstrap your world from scratch, beginning with what your company does. Once you become a household name you don't have to do all those steps; Amazon doesn't need to introduce themselves as an ecommerce company or AWS as a cloud service. But I think it would help you to. Don't, however, make a general-purpose intro. Your goal is not to fill out the whole picture, it's to get the reader over that first hurdle so they'll keep reading. For that to happen, they need to feel oriented. So make an article-specific intro that leads straight to the problem that your article is going to talk about. Something like this: "FooCo is an X that does Y. Our users are Z. Because of that, we have to deal with W." Now you've walked the reader from nothing (who are you? what is this?) up to the problem you're about to delve into. This sequence can be short, but needs not to skip steps, so readers can follow along. Don't go into too much detail—make it a refresher for those who know you, but give enough info for someone who's never heard of you to stick with it. Ruthlessly cut all fluff from your intro. Don't go on about your vision or who you want to empower or what your values are or how excited you are. All that is a lose-lose: it crowds out the interesting stuff, like weeds obscuring flowers, and readers will hear it as just-another-startup-ad. Turn it into a win-win by cutting it: your post will be more interesting *and* you'll stand out by absence of smarm. That's the fast track to credibility. Why is this interesting? Once you've gotten to the problem, stay there a while. Do not shortchange this! A common mistake is to give only a quick description of the problem before jumping into how you solve it. This loses readers who don't know about the problem you're solving or why they should care. Your problem section matters a lot: it is the fueling stage that energizes the reader for the journey. The problem must be interesting enough that readers become curious to hear about the solution. Otherwise, again, they'll close the tab. Think of a blog post like a conversion funnel. You're probably losing the two largest cohorts of readers right at the start: the ones who don’t already know you, and the ones who don't get what problem you're solving or why it matters. To make the problem interesting and arouse curiosity, you need to communicate three things. All three pins need to land in their sockets: (1) what is it? (2) why does it matter (what pain does it cause)? (3) what makes it hard? Spend at least half your time making sure you get this right because if you don't have it, most readers won't make it further. It needn't be long, but must be clear. The best thing for clarity is examples. It's easy to jump from examples to a general description, but hard the other way. Abstract descriptions are risky: they make sense to people who are already immersed in your world (you!) but are a closed, slippery surface to the rest of us. If you've ever looked at a website or heard a pitch and felt "I can't tell what this is", that's why. Clear examples give your readers the satisfying click of ah-I-get-it. Better yet, you can then just drop the abstract description, because readers will recreate in their heads. Use real-world examples if you can; contrived ones are unconvincing. (Btw, there's a second way to excite curiosity, where you don't motivate the problem at all: you just say what you wanted to do and the only reason is "just because". This is good for whimsical hackery, like making a Turing machine out of Lego. It works great when the problem is arbitrary, surprising, and tricky enough to be weird. But a business can't use this strategy so easily since people will question how it adds to the business.) When describing the problem, don't be dry. Make it vivid. You want the reader to put themselves in your position and think "if I had that problem I'd sure need to solve it, and yeah, I can see how hard it might be." You don't have to embarrass yourselves, but if you can explain how bad things were and talk about failed attempts to fix them, it will make for a better story: more credible, by showing how the problem was hard--but also more relatable, because everyone knows what it's like to flail around before finding a solution. Exception: some things are automatically worth writing about because they're immediately cool and interesting. Those leap out at the reader, and all you need to give are the details. So don't make up a story or force-fit your article into any shape. But if you do have such a story, share what happened. It will be more alive than the abstract facade that most companies present, which is both boring (because it's abstract) and annoying (because everyone can feel that it isn't real). In your post, you cover some of the problem situation, but it's not vivid enough; it doesn't give me a feel for why it was hard or bad. Put us in the room with you at the time. The problem doesn't have to be huge. What it has to be is interesting. Sometimes a tiny thing is more interesting than a big one; it depends on what hooks it has to catch the reader's curiosity and draw them in. A problem should be easy enough to describe that the reader gets a dopamine hit of recognition at the beginning (e.g. "hey, I know Rails, I wonder what they're saying about Rails"), but not so easy that they can guess the end from the beginning. There must be unexpected details along the way. It should be like a murder mystery, where the big reveal is unpredictable enough to surprise, but not so much as to make the reader go "WTF?", feel cheated, and rush to the comments to complain. Don't give a tutorial, tell a story The second limit to your article's appeal is that it is a tutorial. Tutorials are fine, but rarely do well on HN. It took us years to figure this out, but once you see it, it's obvious. Many people trying to get attention on HN get this wrong, so there is upside for anyone who gets it right. Tutorials focus on *how* at the expense of *what* and *why* and *who*. Nobody reads tutorials for fun. They're valuable when you have a specific task, google it, and spend as little time as you can. The goal is not to gratify curiosity, it's to get your task done and move on. A good HN story, on the other hand, gratifies the curiosity of a random smart reader. The things that make a good tutorial make a post bad for HN, and vice versa. Imagine a recipe that went into how and why its steps work, how they got that way, and compared itself to other recipes. That would gratify curiosity better, but it would be a lousy recipe. Tutorials have the conversion funnel problem too. They appeal to a small audience—readers who have that specific task—and lose the big audience that is looking for interesting things to read. The least interesting details are the ones that apply only to a particular program or product, like "Step 14: put a file named foo in a directory called bar/baz". For a tutorial, these are the most important steps, the ones that are hard to derive or guess. But for the general reader, they are the most boring. What am I learning about the world, about problems? I don't care about arbitrary details I can just look up when I need them. For appeal to HN, don't frame your material as a tutorial, frame it as a story: "we needed to do X so we tried Y, had trouble because of Z, solved it with W, and oh by the way have some surprising details A, B, and C". What makes a good technical story? First you need to say who you are and motivate your problem, as described above. That provides 'who' and 'what'. Then you need 'how'--but not as a set of instructions or steps to follow. Rather, take the reader along as you solve the problem. Don't say "what you, the reader, should do" (that is condescending), but rather "what we, your humble narrators, actually did, warts and all". That is more fun to read, and if there are dips in the story where readers get to feel smarter than you because of mistakes you made, so much the better. "Tell a story" doesn't mean you have to literally tell a story in the sense of "One day Alice did this and then Bob did that". It means following the logical format of a story. You can do that in a purely technical style too. Write your post in whatever style fits the material, but make its deep structure be that of a story. For a distillation of what that means, watch https://www.youtube.com/watch?v=vGUNqq3jVLg. Frame your article for the largest HN audience, the one that is just curious about things. Start with something that has random-access appeal, not in the sense that everyone has the problem, but that everyone can see why it would be interesting. Make the general reader curious, even though they might not have that problem in their own world. HN users enjoy reading about problems they don't personally have, if they can see why they matter and are hard. Here's an example. Say you have to manage authentication for lots of different users coming in from different clients with different protocols. If you describe that problem generally enough, it becomes interesting. Anyone who's had to deal with either authentication or integration (which is most of HN) can imagine how hard that is to solve. But if you frame it as "how to install our product to do authentication federation", it reads like a tutorial and becomes boring. Start with something big enough and puzzling enough that it isn't obvious how you'd solve it, but is obvious why you'd need to. A story should be about something hard. Unexpected obstacles and twists make it better. In a tutorial, those are distracting and bad; a good tutorial makes things easy. On HN, however, easy equals boring. No one comes to HN to read about easy things. That's another point it took us years to figure out! This is why slick 1-2-3 or single-click solutions for customers fail to excite interest on HN: it's a mistake to present these the way you would to a user—"you barely have to do anything, isn't it great!" Actually no: it is a turn-off to HN readers, who want to know the under-the-hood complexities of how things work. As a *user*, should they become one, they'll love the simplicity. But for a *reader*, if all you present is your smooth surface, curiosity is frustrated. Worse, if you talk about how sophisticated your technology is behind that surface, readers will feel patronized. It is as if your message is "Unlike you, we are smart enough to understand this, but don't worry, we take care of it all for you." At this the hivemind gets ornery and will start to poke holes. This is not because they hate you--it's because you frustrated their curiosity. To fix this, gratify curiosity. Pull back the curtain, open the hood, give the details. One way to do this is to talk about the complex path you followed before you could make things simple. Show how hard it was to make easy. Show *how* you did it. Readers will appreciate the payoff at the end, but only if they get to participate in the puzzle along the way. False starts, unexpected disasters, and everything that makes a problem harder than it seemed—all that is in scope and adds to an interesting story. Don't do content marketing Let's review. When the real purpose of an article is to sell a product, but it's pretending to be about something else, HN readers see through the facade and discount the content. It's obvious that the content has not originated in the author's own interests or curiosity and that the problem really occupying them was not the one they wrote about, but rather, "how can I make an article that will interest HN"? One imagines the whiteboard discussions trying to brainstorm topics that HN might go for. This is why startup articles about how to use their product to solve some task rarely do well on HN. It doesn't matter how clever $TASK is; the arbitrariness makes it uninteresting. The problem wasn't intrinsically important to anyone, not even the author. If you treat a topic as a means to an end like this, it will be low in energy and fail to excite readers. Worse, when it's clear that the author is a marketer or writer whose job is to produce such content (and this is usually obvious), readers discount it almost to zero. HN readers are averse to such material. Don't conjure up artificial content for prospective customers or users. Rather, talk about the real world of the startup--what the product is, what problem it solves, why it matters, how the product is made--and the real people working on it. Address HN readers not as customers or users, but as peers. The person doing the work should be the one writing. Sometimes that's not so easy--they might not have time, or they might feel like they suck at writing. But be wary of hiring an in-house blogger to write exciting things about what your developers or product people are doing. You're probably wasting that money, at least on HN. Articles written by people who "suck at writing" work far better than content produced by content-producers. The latter rarely does well on HN. Real people writing in their own voice--not an artificial voice making content that somebody hopes others will like, but their own voice, be it laconic or naive or curmudgeonly or whatever--about real work that they're doing on some hard technical or business problem, and/or something that they're simply interested in, has perennial HN appeal. Get this, and stop there. If you add blogginess, evangelism, professionalism, you're spending money to make it worse. This only makes it harder to stand out from the flood of marketing that isn't intellectually interesting. Fancy web design makes things worse too: it visually classifies you with the countless professional-looking sites that have nothing interesting to say. It's a shame, because many *would* have something interesting to say, if people could simply trust themselves to write directly about their real challenges and work, and stop trying to dress it up. In short: spend less money to be more interesting! Resist the temptation to self-flatter. If you say nice things about yourselves or your product, you're singing in the key of marketing and losing the reader as a peer. Since internet dynamics are essentially contrarian, this only invites people to make objections and knock you down a peg. Grand claims and superlatives (fastest, biggest, first, best) are especially weak. Turn this to your advantage by using modest language and being cheerfully self-critical. Then the only way people can make objections is to find something nice to say about you! Never bring up your startup only at the end of an article. To readers this feels like a bait-and-switch. It signals "actually this has been an ad all along; we were only writing about that other shit to grab your attention". HN readers hate that, and if your article actually did draw them in, it's even worse, because it destroys the connection you built up with them. They trusted you and you betrayed them. This is why such articles produce strangely angry comments. The opposite is a mistake too: if you mention your startup too much, your post will sound like an ad regardless of what else you say. Worst is when people refer to their company in the third person: "FooCo lets you bar your baz with ease. Before FooCo, people had to bnog. That's why we started FooCo. Customers love FooCo because FooCo bligs." Nobody actually talks that way. Readers want to relate to *you*, so write in the first person ("I", "we"), use your company name sparingly, and don't try to brand the reader. Just be aboveboard. Bring up your startup at the beginning by briefly explaining what you do and how it relates to the interesting problem you're going to write about. Bring it up again at the end if you want. Do the things described above, and you'll be well-positioned for HN. It doesn't guarantee you attention--there's no way to do that--but at least you'll be playing the odds. ============================================================ Here's an example of some feedback I sent to a startup that covers much of the same ground: Ok, I've had a chance to read the post. I see three problems: it doesn't go into technical depth; it talks to the reader as a user or customer rather than as a fellow implementer; and it is corporate rather than personal. That combination of qualities will cause HN readers to classify the post as "enterprise marketing material", which is a community killfile. You might get a flamewar out of it, but I doubt that would benefit you. For better results, you need to interest HN readers and respect them intellectually. I'll try to explain. Readers come to HN to have their curiosity gratified. They want to learn surprising details about hard problems. If you only give them a shiny surface, they'll feel short-changed and channel all that curious energy into finding flaws in what you said, or complaining about how you haven't said anything. Your post doesn't offer anything more than a shiny surface technically, though it does trigger controversy at the start by dissing NoSQL in a contentious way—which can be good for clicks! though it also invites flags. But it's unlikely to leave readers with a good feeling about you. In your post, when I finally get through the "why [our startup] is better" section, I have the feeling that I've just read a blurb directed at purchasing managers, not a gratifying dive into interesting material. It may be a fine blurb for purchasing managers, but it's going to turn off the HN crowd, who identify with *not* being that. They don't want bullet points. What they want is the hard stuff, details to chew on, and the feeling of having learned something. When talking to customers or users, it's good to present a shiny it-just-works surface. When talking to *readers* (on HN at least), it's the other way around, even when you're hoping to convert those readers to customers and users. The old adage that people don't care how your technology works, they just want a product that solves their problem, does not apply here. On HN, this is exactly what people care about, and what they come to the site to hear about. There's one word in your post that typifies this issue: "sophisticated", in "[our product] has a sophisticated distributed query processor." That lands with the typical HN reader as follows: "we're smarter than you, so don't worry about how we do magic which you couldn't possibly understand, just trust us and buy our product—it's sophisticated". That's going to drive HN crazy! User and reader are opposites here. As a user I want a don't-make-me-think solution that just works. As a reader, that's what I *don't* want, because it's boring. Show readers that you respect them intellectually by giving them some of the hard problem, then giving some unexpected aspects of the solution. Should they eventually become users, they'll appreciate the simplicity and sophistication of your product at that point--but not before. > your people can use [our product] the way they use any other > relational database. They don't have to be retrained. This sounds like enterprise marketing, which is the wrong key for HN. The minute the typical HN reader realizes that that's what they're reading, they will close the tab. HN readers want to hear from individual humans, not corporations, and to be talked to as an individual human, not an org role. HN readers want to be talked to as fellow engineers and entrepreneurs, not as prospective customers or users. Talk to HN the way you would talk to a couple of smart friends you haven't seen in a long time, who you're catching up with over beers, who want to hear about what you're working on and ask good questions. You know the kind of friend who starts turning your problem over in their head the minute you begin telling them about it? That's how HN is, except that your HN "friends" cover the entire spectrum of experience and knowledge, from naive at one end to expert in your problem space at the other. In terms of how to rework this post so that it pleases HN and gratifies curiosity, you have one theme that's hugely valuable: your personal experience in the field. You mention your years at $CORP1, and then at $CORP2, all working in this area—that's gold, because it suggests a long backstory and plenty of details about what you learned. But you don't follow up on it, or even connect the material to what specifically you did or learned. I think your post would be better if you organized it around this. Then you're doing two things that hit the sweet spot for HN: (1) telling a story, and (2) talking personally, not corporately. Does this make sense? If you want to send another draft I might be able to give you some more tips. For example, I think it would be better if you didn't lead with strong polemical language against NoSQL at the beginning. That snaps the reader's brain into fight mode. Rather, you should signal your destination mildly at the start, then go into your story and interesting details as described above, slowly building up your case—and only hit hard at the end. This will build you more credibility in the reader's mind. A generic "NoSQL sucks" controversy might get lots of discussion, but it reduces your role to kindling, and it's a bit too 2013 anyway. Another tip: your "bias alert" disclaimer is good, but you should put it near the beginning (e.g. at the end of your opening paragraph). Being up front makes it credible, while putting it anywhere else feels evasive. It's obvious from the company domain who you're representing anyway.