基于JTBD方法论的学习思考

0 评论 5283 浏览 30 收藏 14 分钟

有效的用户调研可以让你更加深刻地洞察用户需求,从而助推产品创新。这个时候,一套合理的产品创新洞察方法论就可以排上用场了,比如本篇文章里介绍的JTBD。具体如何理解这套方法论?不如来看看作者的解读。

在进行产品创新时,合适的调研方式

乔布斯说:“消费者并不知道自己需要什么,除非你把产品展示给他们看。”

亨利福特说:“如果我当年去问顾客他们想要什么,他们肯定会告诉我,一匹更快的马。”

文章开头的名人名言想必大家并不陌生,很多人将其理解为:好的产品不是用户调研所得来的,因此用户调研并不重要。

而实际上这些名言背后所指向的问题关键应当在于:在进行产品创新时,你是否选择了合适的调研方式。产品创新不仅需要用户调研,还要区别于普通的产品需求挖掘进行更加本质的用户需求洞察,本篇将介绍一个产品创新洞察方法论:JTBD。

一、JTBD是什么

JTBD全称Jobs To Be Done,中文翻译为待办任务(或待完成工作),也有人称其为“焦糖布丁理论”。是由哈佛大学教授Clay christansen于2003年提出,一种洞察用户需求的模型及理论,被认为是颠覆性创新的理论基础。JTBD中的一些概念并不是全新的,但它确实是一个少有的可用于产品创新的系统性研究框架。

JTBD强调用户购买产品是为了完成某些任务(jobs),它的几个基本观点是:

基于JTBD方法论的学习思考

二、那Jobs和一般需求的区别?

基于JTBD方法论的学习思考

一般需求通常都是用户可以直接说的出口的需求,需要围绕着某个特定的产品,特定的功能,而jobs是用户使用某个产品的最终目的和结果,一般需求可以说是用户试图完成jobs的其中一种方式。

如上图所示,用户想要从A到B,从A到B其实有很多路径,而用户如果是面对一个卖火车票的产品,他们可能提出诸如要一张不转机的火车票这样的一般需求,而用户的最终jobs可能是:想要又快、又便宜、又舒适的到地方B去。

基于JTBD方法论的学习思考

一般需求都是为了完成用户的任务而存在的,会随着时间的迁移和环境的变化而改变,而jobs是稳定不变的。jobs反映的是更加长远和整体的用户需求,一般需求则是倾向于短期和局部的视角。

三、基于Jobs分析 vs 基于具体的产品分析?

JTBD强调基于用户的jobs去分析而不是基于用户和产品去分析,即关注用户的行为目的和结果,而不是具体的产品功能。首先需要说明的是,我个人认为要基于jobs分析还是基于具体的产品分析并不是一定要二选一的关系,而是两者结合兼顾或者基于业务场景择优应用,只是在日常工作中更多的人是在基于具体的产品分析,忽略了基于jobs分析的价值。

基于具体的产品分析,通常回答的问题或者调研结果是:

  • 用户希望这个产品在哪些方面进行优化?
  • 用户觉得这个产品哪些地方做的不太好?
  • 用户觉得这个产品哪些方面还比较好?
  • 用户希望增加功能A。
  • 用户希望产品更便宜。

基于jobs分析,通常要回答的问题是:

  • 用户使用产品产出的方案应用在什么场景?
  • 用户在这个场景中的任务是什么?(无关使用哪种产品)
  • 完成这个任务后用户可以获得哪些进步或者成就?(关键点在于让用户在哪些方面变得更好,属于用户深层需求,可以从功能层面、情感层面、社会层面综合分析)
  • 实现这个任务过程中存在哪些痛点和阻碍?(无关使用哪种产品)
  • 实现这个任务可以有哪些新的机会点?

一个基于jobs分析应用示例

项目背景:酷家乐作为toB的SaaS公司,主要服务对象为门店设计师/导购,现在需要对门店场景进行研究,为新的解决方案孵化输入信息。

下图为项目整体研究框架,其中主要包含了以下分析步骤:

  1. 首先梳理门店场景包含的主要业务流程,通常是一个定义较为宽泛的环节,作为要进行任务分析的场景。
  2. 观察场景用户(任务执行者)当前的行为/采取的解决方案,并结合用户访谈,获取行为背后的用户的子任务或者终极任务(重点不在于行为本身,而是这些行为是为了完成什么终极任务),这里的子任务包括:基本需求、情感需求、社交需求。
  3. 同时了解用户在使用当前解决方案实现子任务过程中的痛点/焦虑。
  4. 结合用户子任务、痛点、期望进行多角色共创,去探索更多新的产品/解决方案创新方向。

基于JTBD方法论的学习思考

以其中一个场景“顾客首次到店接待顾客“这个场景为例,来看任务分析的过程:

基于JTBD方法论的学习思考

本篇仅简单展示任务分析的一点思路,基于JTBD理论目前在两个研究方向上有比较系统的实践工具和流程,关于以下两个实践方法,更多完整的过程可参考相关学习资料做更系统深入的了解:

  1. 价值主张研究方法:引导定义产品和服务,明确产品/解决方案的包装方向。
  2. 用结果驱动创新:Anthony W. Ulwick(“jobs-to-be-done”理论的开拓者)基于JTBD理论发明了一个可用于战略创新的实践解决方案:Outcome-DrivenInnovation(ODI)。

四、为什么要基于jobs去分析?

1. 基于产品分析的需求可以解决问题,但缺乏想象力和创新空间

通过上面对一般需求和jobs的区别就可以明白。假设我们的产品是旅行网站,那么我们基于用户针对产品的需求所做的迭代创新就是:提供不转机的、更短的时间、连坐购买等功能。而无法提供更多可能的选择。

如果我们是基于jobs去进行分析,我们会发现,还可以提供的可以是一张飞机票,一个顺风车等。基于jobs去分析,可以提供更多创新的可能性和成功率。

2.基于产品分析的需求,不一定是用户愿意购买的

基于JTBD方法论的学习思考

JTBD理论的一个核心观点是成就用户,而不是升级产品,这一点和我们常说的客户成功是类似的道理。

消费者购买产品是为了完成待办任务,但驱动用户购买的原因不一定是因为产品本身的某个功能属性,基于产品具体功能分析得到的需求不一定是用户愿意购买的需求,如果一味地进行功能的升级,最终会变成功能的堆砌,而并不能帮助用户升级进而也就不会让用户产生购买行为。

有一个关于奶昔困境的故事案例,讲述的是某连锁快餐店为了提升奶昔销量进行了用户研究,研究发现人们并不会因为奶昔更厚、更多、更便宜或者是做的更健康而选择购买,而反倒通过提供细吸管搭配浓稠的奶昔更能提升销量,其中根本的原因是因为研究者通过对消费者购买奶昔背后的任务洞察,找到了人们购买奶昔的待办任务之一是为了打发上班路程无聊的时间,而提供一个让顾客喝更长的时间奶昔才是用户真实的需求。

这个例子也告诉我们,正如乔布斯所说,很多时候消费者并不知道自己需要什么,基于某个或者某些具体功能分析得到的需求并不能反应用户购买的真正意图,打造出来的产品可能只是功能的堆砌而并不能帮助用户完成一个场景化的目标,最终局面可能就是“叫好不叫座”,站在用户的最终目的和场景上去分析会是一个更有效的方式。

五、写在最后

1. JTBD的价值?

JTBD作为一个理论框架,价值取决于你如何使用它,可以简单的被应用在日常产品创新的用户需求了解中,也可以用于探索一个新产品的价值主张,甚至放到更大的层面可以去帮助企业定义一个新兴市场,但总的来说,它可以:

  • 帮我们找到创新的机会点,提供更多创新的可能性。
  • 帮我们分辨那些与任务无关的解决方案,放弃在不那么优的产品上耗费过多的时间。
  • 帮我们识别真正的竞争对手。竞品不仅是同类,还可以跨界,那些帮助用户实现待完成任务的产品都可能是我们的竞品。思考下:为什么说瑞幸咖啡的竞品不是星巴克而是便利店?

2. JTBD是很早的概念,但是为什么并没有流行起来?

-在了解和尝试应用JTBD方法论的过程中,我发现JTBD在理解和应用上还存在一些阻碍,这可能是导致JTBD并没有流行起来的原因:

  • 基本理念与常见的一些以用户为中心的观点类似,容易忽视JTBD的价值。
  • JTBD是一个理论框架,不是一个具体的实践方法,研究者对它延伸了多种多样的理解,较难对其进行简单明了的描述。
  • 即便JTBD有了ODI这样的实践流程,但产品创新是一件很复杂且庞大的事情,不是一个简单的调研,流程中的环节不仅需要大量专业技能还需要多角色的共创,更为关键的是需要企业决策的引领,因此要启动这样的一个创新流程并不容易。

3. 我为什么想要介绍JTBD?

JTBD服务的场景是创新,这是所有企业都比较关心的一个问题,也是最难的一个部分。虽然其中的理念似乎并不新颖(比如以终为始的用户思维),但在实际的工作中,这些理念并没有被很好的实践(大家似乎都知道,但又并没有用起来),仍然存在不少产品没有关注用户的本质需求,而进行粗放式的功能堆叠。

JTBD作为一个系统性的创新理论框架,可以让大家对创新实践有更多认识,让企业目标更加一致,专注在稳定且长期的需求洞察上,希望都能回归到用户本身,真的做长期主义。

相关学习资料:

  • 书籍:《创新者的解决方案》
  • 书籍:《创新者窘境》
  • 书籍:《创新者任务》
  • 书籍:《JOBS TO BE DONE: Theory to Practice》
  • 微信公众号:品创方略-《什么是jobs to be done?》

作者:墨一,公众号:群核科技用户体验设计

本文由 @酷家乐用户体验设计 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于CCO协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!