founder-led-content

创始人主导的内容

你不必“做营销”。你要成为开发者在这个问题上信任的人。推广品类，而不是产品，让你的权威吸引人们主动靠近。

适用场景： 你觉得内容令人反感，于是避而不做；你的“博客”只是更新日志；或者竞争对手正悄然成为行业首选的声音，而你还在默默埋头交付。

核心理念

开发者青睐技术深度、坦诚和鲜明的观点，反感精心包装的空话。正确做法不是推广，而是教育。成为这个问题上值得信赖的专家，表明你对行业发展方向的立场，产品自然会成为显而易见的答案。

在实现产品与市场契合之前，只有创始人能做到这一点。DevRel 是以后要招的第 2 位员工，不是现在。

框架：权威定位（Frankl）

• 掌握问题领域，而不只是产品页面。通过演讲、帖子、拆解分析和独到论点来建立影响力。
• 推广品类： 讲解问题，描述人们为何需要“这样的工具”，分享成果，但不要主动推销（那会触发开发者的防御心理）。
• 对行业发展方向要有明确的观点。值得信赖的专家有见解；供应商只有功能。

“O'Reilly 图书”内容计划（Frankl）： 想象一本关于你所解决问题的权威著作，大约 10 章，每章约 10 个小节。这意味着你可以规划出约 100 篇真正有用的内容。按照大纲持续发布。你要写出一本能让你成为权威的书。

框架：以内容和 GitHub 作为分发渠道（Czakon）

• 讲解问题领域（DigitalOcean 模式）：撰写教程和深度文章，即使读者永远不会购买，也能从中受益。满足好奇心 > 推广产品。
• README = 你真正的落地页，适用于 OSS/开发者工具：它是什么（一句话）→ 为什么存在 → 5 分钟内完成快速入门 → 可复制粘贴的示例 → 徽章/社会证明。开发者会根据 README，而不是你的网站做决定。
• 仓库 SEO： 将实际搜索词放进仓库名称、描述和主题中；开发者（以及 Google）会通过问题关键词找到仓库。
• 真实胜过精致： 采用第一人称，真诚、透明。粗糙但诚实的帖子，胜过华丽却空洞的内容。

决策树：接下来写什么

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.)

看似合理的错误

• 把更新日志当内容： “我们发布了 X”既不是故事，也无法吸引人（Frankl：功能不算新闻，客户的成功才算）。
• “很高兴宣布”： 没人在乎你对这次发布有何感受。
• 重包装、轻实质： 开发者一闻到营销味就会离开。
• 忽视 README： 再好的产品，配上敷衍的 README 也无法促成转化。
• 缺乏持续性： 连发三篇帖子，然后沉寂。能长期坚持的发布节奏，胜过一次拼尽全力的爆发。

接下来的 30 分钟

• 草拟你的“O'Reilly 图书”大纲：围绕你要解决的问题写 10 章。你现在有了一份内容路线图。
• 写下一句你真正认同的观点，说明你认为所在领域将走向何方。
• 根据上述结构审查 README（是什么 · 为什么 · 5 分钟内快速入门 · 示例 · 证明）。
• 将问题领域的实际关键词放进仓库的名称、描述和主题中。

---

内容基于真实的开发者工具 GTM 经验，并借鉴 Adam Frankl（The Developer-Facing Startup）和 Jakub Czakon（markepear.dev）的框架。 如果你想找到自己的切入角度，并建立一个真正能坚持下去的发布节奏，欢迎通过 LinkedIn 联系我。