mcpField
T
talk-to-users

talk-to-users

github.com/aidevgtm营销与增长329171 次安装2 天前更新
代码仓库

关于 talk-to-users

talk-to-users 是面向开发者产品团队的营销技能,介绍通过定期访谈组建技术顾问委员会,并将用户原话用于定位、路线图和文案。

主要功能

  1. 01组建具有代表性的技术顾问委员会
  2. 02开展定期的非销售访谈
  3. 03通过个性化联系招募成员
  4. 04按结构化问题开展访谈
  5. 05将引述归入四类研究主题

适用场景

  1. 01通过开发者访谈验证产品信息
  2. 02收集制定产品路线图的意见
  3. 03从公开的问题反馈中寻找访谈对象

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/aidevgtm/gtm-cofounder --skill talk-to-users

安装后在 Claude Code 中输入/talk-to-users确认已加载。

详细介绍

与用户交流(TAB 系统)

面向开发者的最佳营销方式,就是与开发者交流。仅此而已。本仓库中的其他所有内容都建立在这项技能之上。

适用情形: 你从未真正采访过用户;你的宣传信息很巧妙,却未经验证;或者你总是在内部争论路线图,而不是去询问那些深受问题困扰的人。

核心理念

组建一个技术顾问委员会(Technical Advisory Board):由 30-50 人组成,他们代表你的用户和买家,而不是一些白发苍苍、指点你如何构建产品的顾问。反复采访他们,让他们的话成为你的定位、路线图和主页文案。

TAB 访谈不是产品演示,也不是销售电话,而是一次访谈。绝不要提及产品。

框架:TAB 系统(Frankl)

构成

  • 每种会接触产品的用户角色至少有一名代表(参见 who-is-this-for)
  • 用户(使用产品的人)和客户(付费的人)都要涵盖,他们往往不是同一批人
  • 目标人数为 30-50 人

频率

  • 每月一次 · 一对一 · 30 分钟 · 持续约 6 个月
  • 使用 Zoom,经许可后录音,绝不当面进行
  • 每次都问相同的问题 · 绝不推销

招募(这是个数字游戏)

  • 每条消息都要个性化,绝不要批量群发
  • 从他们的问题切入,而不是你的初创公司
  • 从 docs/gtm-cofounder/market-research.md 中的“用他们自己的话描述问题”开始:那里列出了已经发文谈及痛点的真实用户,并附有链接
  • 最多 4 句话
  • 回复率约为 10% → 计划联系约 500 人,以招募约 50 名成员
  • 不付费:提供提前体验机会、影响力和周边商品

模板:

Dear [Name],

Your post about [specific problem] was genuinely sharp.

I'm building something to attack [that problem] and I'd value your view. Would
you consider joining my technical advisory board?

If so, reply and I'll set up a short call to explain what's involved.

7 个问题(30 分钟内最多问 7 个)

  1. 魔法棒:"如果你能挥动魔法棒,改变自己完成[任务]的任何一个方面,你会改变什么?"
  2. 影响:"如果我们实现了这一点,会如何改变你的一天/你的工作?"
  3. 为什么是现在:"如今的世界有哪些变化,让这件事比五年前更有价值?"
  4. 你所在的组织中是什么导致了这个问题?
  5. 你尝试过什么?为什么效果不理想?
  6. 如果再过一年仍然没有任何变化,会发生什么?
  7. 你会去哪里了解这方面的最新动态?(你信任谁/什么)

分析:将访谈记录转化为素材

将完整句子(而非片段)标记到四个类别中,然后用受访者的原话为每类提炼出 3-5 条最重要的内容:

类别要挖掘的内容
痛点糟糕的结果、风险、障碍
收益他们期望得到的结果
待完成工作他们试图完成的事情
环境变化随时间推移令痛点加剧的趋势 → 你的反派

这四类内容会直接为 positioning-and-story 和 value-prop-that-converts 提供素材。

看似合理的错误做法

  • 采访朋友:他们人很好,但帮不上忙。你需要的是敢于说不的人。
  • 在访谈中途推销:你一开始演示,他们就会变得客气,而不再坦诚。
  • 诱导性提问:“如果……那不是很棒吗?”只会让你得到自己设法引导出的答案。
  • 批量联系:向 200 人发送模板化群发消息,只会被 200 人无视。要么个性化,要么别发。
  • 询问解决方案:用户是痛点方面的专家,不是产品方面的专家。要挖掘痛点。

接下来的 30 分钟

  • 列出 who-is-this-for 中的所有角色;每个角色都需要 TAB 成员。
  • 找出 10 位公开发帖谈论过这个问题的人(HN、Reddit、GitHub issues、X)。如果你运行过 research-the-market,你的第一份名单已经在 market-research.md 中。
  • 今天发送 10 条个性化、共 4 句话、以问题为先的邀请。
  • 确定你的 7 个问题(上面的 3 个 + 4 个定制问题)。不要超过 7 个。
  • 完成 3 次访谈后,用真实引述填写「痛点 / 收益 / 任务 / 变化」表格。

内容基于真实的开发者工具 GTM 经验,并借鉴了 Adam Frankl(The Developer-Facing Startup)和 Jakub Czakon(markepear.dev)的框架。 如果你需要帮助组建真正的技术顾问委员会,或解读访谈实际反映的内容,欢迎通过 LinkedIn 联系我。

评论

支持 Markdown