Pain Point Research Guide
如何在 Twitter 上发现客户痛点，而不是只收集一堆随机抱怨
Twitter 能暴露客户痛点，是因为人们会公开表达摩擦、失望、替代方案和 workaround。真正的难点在于，如何把这些零散帖子整理成团队可以信任、可以在产品和定位里使用的模式。
1. 先锁定你想理解的工作流或任务
当团队先从某个 job to be done、某个流程阶段或某个类目问题切入时，痛点发现会容易得多。
这会为你提供更清晰的边界，帮助你判断哪些帖子真的属于当前研究集合。
- 先选一个工作流、一个人群或一个任务。
- 列出抱怨用语、workaround 说法和替代词。
- 先明确输出最终是服务产品、定位还是研究。
2. 保存帖子，也保存背后的上下文
一条强痛点帖子，应该和足够的来源上下文一起保存，团队才知道是谁在经历这个问题。
因为同样的问题，来自 buyer、operator 或旁观者，意义会明显不同。
- 采信痛点前先看账号本身。
- 重要痛点簇下面都保留示例帖子。
- 当上下文会改变意义时，用 timeline 补充。
3. 把帖子聚成重复痛点主题
当团队把抱怨按 onboarding friction、定价不清、缺失集成、报表缺口或流程复杂度来分组时，痛点研究会变得更能行动。
这也更容易看出：某个问题是在扩大，还是只是偶发现象。
- 围绕问题本身分桶，而不是围绕发现日期分桶。
- 把严重阻塞和轻微烦恼分开。
- 重点追踪跨来源重复出现的主题。
4. 把主题聚类转成团队能复用的研究产物
当痛点发现最后能变成 memo、research brief 或每周更新时，它的价值会大得多，因为别的同事不需要重新打开每一个搜索标签页。
也是在这一步，Twitter 才真正从发现渠道变成研究方法的一部分。
- 总结最重要的痛点簇，并附上示例。
- 说明哪些问题是新出现的，哪些在持续重复。
- 尽量保持每次复盘结构一致，方便下次比较。
团队在发现客户痛点时最常问的问题
当痛点研究要服务产品或市场决策时，这些问题通常都会出现。
为什么只搜产品名通常不够？
因为很多有价值的痛点是通过工作流抱怨、问题语言或比较语言表达出来的，并不一定会直接提到你关心的产品名。
怎么区分重复痛点和偶发抱怨？
把相似帖子按主题、来源类型和时间聚类后，重复模式通常会比逐条浏览更清晰。
痛点报告里要放原始例子吗？
要。原始例子能保留客户语言，而这通常正是产品和定位最需要的部分。
怎么测试这条流程？
选一个目标人群的工作流，把最强的抱怨聚成主题，然后看这些结果能不能真的进入产品或 messaging 讨论。
和痛点研究流程经常一起看的页面
如果痛点发现是更大市场研究流程的一部分，从这里继续。
如果下一步是按用户分层去理解痛点，从这里继续。
如果这些痛点会进入更宽的产品研究流程，从这里继续。
如果你想看更大一层的研究框架，从这里继续。
把客户痛点整理成团队能反复使用的模式
如果 Twitter 已经在不断暴露客户抱怨和 workaround，下一步通常就是把这些信号聚类成可重复的研究流程。