一年内从 1 到 100 场线下活动:让工程师愿意演示产品的秘诀

18

自从我2025年夏天加入PostHog以来,我们从1场线下活动增长到一年内超过100场。其中大约95%的活动涉及与客户交流,公司超过50%的成员已经在全球多个城市进行了演示——而且这一比例还在不断增长。

我接触过的每个开发者营销团队都很难让真正为他们产品开发的人(现实生活中)走出去演示。虽然这明显是促进留存和扩展的方式,但只有少数内部的喋喋不休的人会优先考虑这一点。

这和我以前工作过的地方很疯狂,以前演讲机会被当作帮忙或义务,很多开发工具公司也会这么说。

以下是PostHog的现实活动团队如何实现这一目标(毫不强求)。

产品工程师,真是太棒了

开发者关系圈里有句老话:“发货,给人看。”我们有很多话要聊。

但许多其他公司也在快速开发产品。我们与众不同的是,我们公司的价值观之一是公开.我们做的所有事情都是开源的,我们一直很喜欢写关于我们正在做的事情。

我们最早的营销之一就是詹姆斯发布他学到的东西作为创始人这件事在HackerNews上迅速走红。

公开不仅仅是为了浏览量。无论是书面形式还是演示形式,分享帮助他人利用我们所学,建立信任,也迫使我们清晰表达思路。所有这些都形成了一个自我强化的循环:

A flow diagram: engineers build stuff, share what they built (and what they learned along the way), which flows into written word (blogs and social) and spoken word and visuals (talks and video), all feeding back into feedback and learning

我在其他公司看到的问题是,如果你们组织的工程师需要被说服去分享他们做的东西其实对客户更好。在PostHog这很顺利,因为我们大多数工程师都是产品工程师:

“产品工程师与用户沟通。他们决定构建什么。他们拥有定价、收入和用户体验。他们直接支持客户。他们主要对用户和付费客户负责。他们拥有产品决策权。”(来源:我们的产品工程手册)

随着更多的所有权和透明度,工程师自然会想要展示他们打造的产品。这带来了更多的客户互动,进而激发对用户的好奇心和同理心,进而带来更多的演示、采访和博客。

而这一切最终又会循环回来。

本次活动回顾来自迈克尔在他做完一次演讲之后米兰dev聚会今年夏初展示了当产品工程师热爱他们所做的工作并与用户分享时的样子:

A Slack recap from Meikel after speaking at a dev meetup in Milan, encouraging others to get out to IRL events

演示文化

演示在这里也变得很自然。在PostHog的任何工作日,你几乎走不远,总能看到大家内部的演示,这要归功于:

  • 我们每周的全体会议。这些视频以公司各方共享屏幕(同时向演示之神祈祷)结束。
  • 我们的许多人。无论是小型团队聚会,还是年度全员公司外地活动,我们的黑客马拉松永远最后每个团队演示他们做过的作品。
  • 我们的“后 #demo 猪”频道。人们随时在这里发帖,让演示持续一周,而不是等待下一次全员演示。

例如,这是Sam在我们SQL Insights产品中演示散点图的演示:

请记住,演示!=幻灯片。我们关心的是展示它实际运行,而不仅仅是谈论它。全球许多最新的AI社区聚会也优先考虑这一点,因为这有助于提升出席率、参与度和热情。

当然,也有例外——主要是超出产品、功能或工具的深层主题——但我们强调展示实际解决方案,而不仅仅是销售推销或概念框架。呃。

让开

因为我们工作异步活动团队的角色是提出演讲机会,然后退居幕后。我们随时准备回答问题和反馈,但理想情况下,这甚至不是必须的。

我们相信工程师们知道,因为他们是该领域的专家,毕竟是他们自己构建的。我们不为他们制作幻灯片,也不做演示,只是让他们自由发挥。

这也与我们另一个价值观相关,叫做“你是司机。”.没有人会告诉你该怎么做。

我们确实提供一些品牌团队的指导方针、资源和资源。例如,以下是某些人参加并在现实活动中发言所需的条件:

  1. 谁、什么、哪里、什么时候。活动详情是我们首先与所有演讲者分享的内容。
  2. 给参与者发放周边。赛事团队发货女孩演讲者现场发言。
  3. 预算出差。活动预算的一部分用于必要时的出差。
  4. 官方品牌幻灯片、标志、猪。任何东西品牌资产相关资料随处可见。
  5. 指导原则和技巧。我们有一些手册页面和一份基于过去成功经验的通讯。

即使在联系有机会的演讲者之前,我们也会使用演讲专长技能那位建设者关系队友克利门特创建。它会根据该员工的GitHub账号,研究他们过去6个月在PostHog组织中合并的公关,然后生成他们的工作大纲、详细的候选技术演讲主题,以及每个主题的N/10演讲价值评分。

这帮助我们带着起始想法坐上谈判桌,而不是把这些想法强加给员工。

以下是技能输出的摘录,参考了亚历克斯·列别杰夫的工作:

The speaker-expertise skill in action identifying a talk topic based on a teammate's GitHub activity

他以此为起点,在华沙WAWTECH举办了关于自动驾驶的演讲,吸引了大量观众:

Photos and a Slack recap from WAWTECH in Warsaw, where PostHog spoke about Self-driving to a packed room

有些工程师甚至会自己组织活动(主要是晚宴和聚会),并在活动中发言,甚至不需要我们参与。我们很喜欢这一点——这又是我们“你是司机。”公司价值。

一旦人们试玩过,就会被吸引住

到目前为止,我们看到一旦工程师做了演讲机会,他们就会被吸引。我们一些唠叨的人实际上期待未来的活动,并主动联系我们。如果他们正在开发一个高优先级的产品,这一点尤其好;我们会寻找更多机会让更多人参与开发这些项目。

不过,好东西总可能过多,所以我们尽量遵守标准,避免让任何个人或团队被活动压得喘不过气。我们始终注意别人上次做演示的时间,尽量不超过季度或双月一次的频率。

我们也会考虑地理位置来提供展示机会。在像西雅图这样ICP重叠很多的地方,我们提供的机会比像堪萨斯城这样的小市场更多。要么是其中一个。

要么两个。结合起来。

迪伦是我们西雅图的工程师之一,经常愿意进行演示,并且真心享受这项工作。这里是他为本地车主演示自动驾驶的活动回顾AI Tinkerers 开发工具版聚会:

A Slack recap from Dylan after demoing Self-driving at AI Tinkerers, sharing takes on the event and the community

所以如果你想让工程师在现实中走出去,解决办法可能不是更好的演讲项目和培训。而是让他们对自己建立的东西拥有所有权,这样他们已经有真正想展示的东西,然后当他们展示了时,再让开。

声明一下,没有人必须做_any至少有20%的公司成员告诉活动团队,他们对在活动中演示或公开演讲没有兴趣。这并不适合所有人,也不应该被期望如此。

因此,当演讲请求被拒绝时,总是可以接受的——没有提问,asked._

参与讨论