Back to Details

founder-led-content

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Founder-led content

创始人主导型内容

You don't have to "do marketing." You have to become the person developers trust on the problem. Sell the category, not the product, and let the authority pull people in.
Use this when: content feels slimy so you avoid it, your "blog" is a changelog, or a competitor is quietly becoming the go-to voice while you ship in silence.
你不必“做营销”。你需要成为开发者在该问题领域信任的人。推广品类而非产品，让你的权威吸引用户主动靠拢。
适用场景： 你觉得营销内容虚浮因而避之不及，你的“博客”只是更新日志，或是竞争对手正悄然成为领域内的权威声音，而你还在默默埋头开发。

The core idea

核心理念

Developers reward technical depth, honesty, and a real point of view, and punish polished fluff. The move isn't promotion; it's education. Be the trusted expert on the problem, take a stance on where the space is heading, and the product sells itself as the obvious answer.
Before product-market fit, only the founder can do this. It's the #2 hire (DevRel) later, not now.
开发者认可技术深度、诚实态度和明确观点，反感华而不实的内容。关键不是推销，而是教育。成为问题领域的可信专家，对行业发展方向表明立场，产品自然会成为用户心中的最优解。
在产品-市场契合之前，只有创始人能做到这一点。DevRel（开发者关系）是后续的第二优先级招聘，而非当下。

Framework: authority positioning (Frankl)

框架：权威定位法（Frankl提出）

  • Own the problem, not just the product page. Talks, posts, teardowns, a distinctive thesis.
  • Sell the category: teach the problem, describe the need for "a tool like this," share results, without proactively pitching (that trips developer defenses).
  • Have an actual point of view on where the industry is going. A trusted expert has opinions; a vendor has features.
The "O'Reilly book" content plan (Frankl): imagine the definitive book on your problem, ~10 chapters, ~10 sections each. That's ~100 genuinely useful pieces mapped out. Publish against the outline consistently. You're writing the book that makes you the authority.
  • 掌控问题领域，而非仅局限于产品页面。可以通过演讲、文章、拆解分析、独特论点来实现。
  • 推广品类：讲解问题，阐述“这类工具”的需求，分享实践成果，但不要主动推销（这会触发开发者的抵触心理）。
  • 对行业发展方向要有明确的观点。可信专家有自己的见解，而商家只会罗列功能。
“O'Reilly图书”内容规划法（Frankl提出）： 想象一本关于你的问题领域的权威书籍，约10个章节，每个章节下约10个小节。这样就规划出了约100篇真正实用的内容。按照这个大纲持续发布内容，你正在撰写一本能让你成为权威的书籍。

Framework: content & GitHub as distribution (Czakon)

框架：内容与GitHub分发法（Czakon提出）

  • Teach the problem space (DigitalOcean model): tutorials and deep dives that are useful even if the reader never buys. Curiosity-feeding > promotional.
  • README = your real landing page for an OSS/dev tool: what it is (one line) → why it exists → quickstart in <5 min → a copy-pasteable example → badges/social proof. A developer decides from the README, not your website.
  • Repo SEO: put the actual search terms in the repo name, description, and topics; developers (and Google) find repos by problem keywords.
  • Authenticity over polish: first-person, real, transparent. A rough honest post beats a glossy empty one.
  • 讲解问题领域（DigitalOcean模式）：制作即使读者从未购买你的产品也能从中受益的教程和深度解析。满足好奇心 > 推销产品。
  • README是OSS/开发工具的真正着陆页：用一句话说明产品是什么 → 为什么存在 → 5分钟内快速上手 → 可直接复制粘贴的示例 → 徽章/社交证明。开发者会通过README而非你的官网做出决策。
  • 仓库SEO优化：将真实的搜索关键词放在仓库名称、描述和主题中；开发者（以及谷歌）会通过问题关键词找到仓库。
  • 真实大于精致：采用第一人称，真实、透明。一篇粗糙但诚实的文章胜过一篇光鲜却空洞的文章。

Decision tree: what to write next

决策树：下一步该写什么

Do you have a real, contrarian-but-true opinion about your problem space?
├─ YES → write that. POV posts build authority fastest.
└─ NO  → write the tutorial you wish existed when you hit this problem.
         (Useful-to-a-stranger is the bar. If it only helps someone who already bought, rewrite it.)
Do you have a real, contrarian-but-true opinion about your problem space?
├─ YES → write that. POV posts build authority fastest.
└─ NO  → write the tutorial you wish existed when you hit this problem.
         (Useful-to-a-stranger is the bar. If it only helps someone who already bought, rewrite it.)

Mistakes that look reasonable

看似合理的错误做法

  • Changelog-as-content: "we shipped X" is not a story or a draw (Frankl: a feature isn't news; a customer win is).
  • "Pleased to announce": nobody cares how you feel about your release.
  • Polish over substance: developers smell marketing and leave.
  • Neglecting the README: a great product with a lazy README converts nobody.
  • Inconsistency: three posts then silence. Cadence you can sustain beats a heroic burst.
  • 将更新日志当内容：“我们发布了X”不是故事，也没有吸引力（Frankl认为：功能不是新闻；客户成功案例才是）。
  • “荣幸宣布”式文案：没人关心你对自己产品发布的感受。
  • 重精致轻实质：开发者能嗅出营销味，然后转身离开。
  • 忽视README：一款优秀的产品配上敷衍的README，转化率为零。
  • 内容发布不连贯：发三篇文章后就沉寂。能持续保持的发布节奏胜过一时的高产爆发。

Your next 30 minutes

接下来30分钟你可以做的事

  • Sketch your "O'Reilly book" outline: 10 chapters on your problem. You now have a content roadmap.
  • Write one POV sentence you actually believe about where your space is going.
  • Audit your README against the anatomy above (what · why · <5-min quickstart · example · proof).
  • Put your problem's real keywords into the repo name, description, and topics.
Built from real dev-tool GTM experience, with frameworks from Adam Frankl (The Developer-Facing Startup) and Jakub Czakon (markepear.dev). When a framework can't make the call, that's what a human is for: The DevTool GTM Company.
  • 草拟你的“O'Reilly图书”大纲：关于你的问题领域的10个章节。你现在有了一份内容路线图。
  • 写下一句你真正认同的、关于所在领域发展方向的观点（POV）。
  • 对照上述结构审核你的README（是什么·为什么·5分钟快速上手·示例·证明）。
  • 将你的问题领域的真实关键词添加到仓库名称、描述和主题中。
基于真实的开发工具GTM（Go-To-Market）经验打造，整合了Adam Frankl（《面向开发者的创业公司》）和Jakub Czakon（markepear.dev）提出的框架。 当框架无法做出决策时，就需要人力介入：The DevTool GTM Company。