JTBD 路径聚类法
解决什么问题
访谈收集了一堆客户故事之后,常见做法是按人口统计学或主题标签做"分群(segment)",但这样容易丢失"哪些因素是绑定在一起共同起作用的"这层信息,导致产品同时想满足互相冲突的多种诉求。
核心内容
Bob Moesta 的分析方法不是"分群(segment)",而是**"聚类成路径(cluster into pathways)":把访谈得到的推力、拉力、焦虑、习惯、取舍标准、"雇佣与解雇标准(hire and fire criteria)"放在一起看,找出哪些推力总是和哪些拉力一起出现——即"有这些推力的人,就会想要这些拉力;没有这些推力的人,就不想要那些拉力"。这样得到的不是人群标签,而是行为路径(pathway)**。
由此得出的关键推论:大多数产品其实同时被"雇佣"来完成 3-5 个互相冲突的不同工作——比如一部分人要"更快",一部分人要"更周全",而"更周全"往往意味着"更慢",于是想要快的人会因为你做得更周全而拒绝你。不先把这些路径拆开看,就无法看清冲突出在哪、该怎么取舍。
案例——Intercom:研究发现客户"雇佣" Intercom 是为了四个截然不同的工作。Intercom 没有为此做四个独立产品,而是保留同一套产品,按路径把无关功能关掉:面向"获客(acquire)"路径的客户,只保留转化相关能力,这个配置直接和 HubSpot 竞争;面向"支持(support)"路径的客户,配置对标 Zendesk——因为 Zendesk 对他们来说"太重太贵",HubSpot 又"派不上用场",Intercom 借此把自己定位成两者之间"恰到好处的下一步"。靠这套按路径拆分产品和定价的打法,Intercom 成长为估值超过 20 亿美元的公司。
适用边界
这个方法要求前一步(访谈)已经获得足够丰富的、包含推拉焦虑习惯的原始故事,而不是简单的满意度评分或功能投票;聚类出的"路径"数量通常在 3-5 个左右,如果分出的路径过多,往往说明访谈样本或提炼粒度有问题。
关键引述 · 原话
"Most companies or most products are hired to do 3, 4, 5 different jobs and they're in conflict with each other... instead of building four different products, they literally took their product and turned off the features that were not relevant to the pathway." — Bob Moesta
关联卡片
建立在《jtbd-customer-interview-technique》采集到的原始故事之上;与《jtbd-four-forces-of-progress》共用推力/拉力/焦虑/习惯这套语言体系,是从"单个用户的故事"到"产品/定价策略"之间的分析桥梁。
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast（2019–2026）。本站为个人学习用途的二次创作，与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2