谈一谈JTBD framework
今天想聊一聊Job-to-be-done framwork. 去年的时候我还发朋友圈diss 过这个方法论，没想到现在我还可以冷静审视之前的想法，还专门为他写一篇文章。做科技行业的人总是会倾向于越来越opinionated，要么想要推陈出新，充满嘘头地制造焦虑，要么对新事物姿态强硬，一顿乱批。新的方法来来去去，最好的方式就是不傲慢，保持开放的心态和独立思考的能力，挑选有用的东西各取所需，为了各自的目标前进着～前进着～本篇详细阅读需要 14分钟。
前言
Job-to-be-done framework是近些年来硅谷公司在产品开发中经常实践的方法论。它的哲学来源于一个简单的原理，人有需要外界帮助才能解决的问题，所以他们需要 “雇佣(hire)” 产品或服务来做这些Job。只有我们把聚焦点放在实质性的Job，而不是解决方案，我们才能真正满足用户的需求，最大程度地扩大创新的可能性。哈佛商学院的市场营销教授 Theodore Levitt这样类比到，“人们不想买四分之一英寸的钻头。他们想要一个四分之一英寸的洞。”
我一开始接触到JTBD framework的时候非常不屑，并没有觉得这个方法论有多么惊世骇俗。无论Job, use case, user story, task 等等，总感觉是新瓶子装旧酒，总离不开“定义问题”本身。直到我最近part time在公司做了一个0 → 1 的孵化器项目，一轮轮面向CXO和VP的pitch过后，我更加确定了“定义问题“真的不是一件容易的事，”创新“也常常沦为套路。这个时候我才认识到JTBD的好处。
在家工作的期间我阅读了JTBD 的重要实践者-Tony Ulwick的书：《JOBS TO BE DONE: Theory to Practice》，对JTBD有了更系统的认识。但是，这本书不乏商业策略书常见偷换概念，否定过去，标新立异的毛病，所以我只谈一些我觉得有启发的点。另外结合在Dropbox内部有关JTBD的资源和实践心得，整理出了以下内容。特此感激我司优秀的Design Research团队。
1.当前创新的两种思路
当前公司推动项目不外乎两种思路，Idea-first和Customer needs first。这两个概念都没错，但是有各自的局限性。
Ideas first
前几年我们的互联网环境还流行着Lean UX， Agile这样的概念，侧重点就是大量产出idea（解决方案），快速迭代和试错。这种务实的心态是好的，但是野蛮生长过后出现了大量资源浪费，以及盲目试错，没有足够重视可预测的增长 （predictable growth）的问题。许多前期验证也仅仅是拿着解决方案放在用户跟前，问他们“你觉得这个方案好吗？“
Customer needs first
第二种是以用户需求为中心的思路。关注用户需求本身没错，但是很多公司对于“需求”的理解是错误的。Tony Ulwick提出，
While nearly every manager agrees that the goal of innovation is to drive solutionsthat address unmet customer needs, a common language for communicating a need does not exist.”
– Tony UIwick
因为用户的表述往往掺杂了太多细节变量，我们在整理用户需求的时候常常会落入两个陷阱，
- 用户说什么就是什么。“我想让手机壳随着不同app变颜色。”
- 把解决方案当作需求。“用户需要一个搜索功能。”
用户需求的陈述应该具有哪些元素，以及表达的结构、内容和语法应该是什么，我们都知之甚少。照本宣科的用户访谈也有太多的“不可知”。有的时候你进行了一场信息量极大的用户访谈，罗列了一堆用户痛点，但仍然觉得无法进行下一步。如同一个厨师有了很多已知材料，但不知如何进行组合做出一道成功的佳肴。
近些年，广义上的用户研究已经针对上述两种思路的局限性做出了很多改进，例如运用客观的话术挖掘用户真实需求，或者更推崇一些以观察行为为主，努力去除bias的研究方法。这一点和JTBD的目标是一致的。所以我不完全赞同作者以一个市场人的角度对两种思路进行的批评和否定。但是JTBD的确提供了一个更容易的结构，与其说是对价值观（needs first, idea first or jobs first) 的颠覆，不如说是建立了一种common language进行表达。这有利于我们诊断“需求”的合理性，并且让产品开发的流程更有目的感。
2.JTBD Framework
“People buy products or services to get a job done.“
“Customers don’t buy products, they pull them into their livesto make progress.“
-Clayton Christensen
JTBD 是一个思考框架，它是以人为中心的，远离商业和技术问题，并且不描述任何UI或者产品功能。
- 它帮助你分类，定义，捕捉并且组织你所有的用户需求
- 将用户定义的“绩效”（performance metrics）和JTBD联系起来。
Job 的种类
JTBD framework主要包含了以下几种类型的用户需求
- Core functional job 核心工作
- Desired outcomes tied to the core functional JTBD 核心工作期待的结果
- Related jobs 相关工作。这一点也很重要，因为它可能会帮助平台型产品的诞生，解决用户心中的多个Jobs。
- Emotional and social jobs 情感和社会工作。用户完成核心工作后，他们期待的心理感受和社会评价是什么。
- Consumption chain jobs 消费链工作。这里涉及使用产品及服务的全流程体验，包括购买，安装，设置，学习，升级，等等。对标互联网环境，增长设计很符合这一语境。
- The buyer’s financial desired outcomes. 购买者经济期待。我为什么买A不买B。这一点适用于以付费为商业模式的产品。
不同产品会对以上几类需求有不同的侧重，例如社交产品会有对情感和社会有额外偏重，实体快消产品必须要考虑消费链工作和购买者的经济期待。但最重要的仍然是核心工作，其他类型的需求都是围绕这个核心工作展开的。那么如何衡量一个Job是否正确合理呢？
- Job是稳定的，说白了，就是“刚需”。不会随着时间发生明显变化。例如说，“听音乐”就是一个job to be done. 变化的是技术和听音乐的形式，但人类总会需要音乐。
- Job是解决方案不可知的（solution-agnostic）。当无法判断时，我们可以问自己这样的问题，这个Job是否有很多解决方案，如果答案是单一的，那么极有可能说明你已经过快进入了解决方案阶段，还没有挖掘到真正的Job。
- Job不能太大也不能太小。太小的job不仅会限制探索，并且很容易被竞品打败。如果Job太大，那么将难以执行。难点在于我们要上升至多高，总不至于上升至“人要喝水是个伪需求，真正的需求是人体细胞需要H2O。”这样的结论。所以我们可以问这样一个问题，从公司的角度，”Can and will the company address this from beginning to end over time?” 公司是否能能给从头到尾地长期为这个需求提供解决方案？
- Job不随地理位置产生变化。不同地区和文化间虽然解决方式不同，但是本质上Job应该是一样的。例如在冬天南方用空调，北方用暖气，没有暖气烧火炕，其本质目标还是“让身体保持温暖”。所以要努力找到他们之间的共性，frame出那个核心的点。
Job statement
JTBD framework最重要的一部分就是创造一个Job statement.
书中给出的格式是:
Job陈述 =动作+动作的目标+情景描述
Job statement = verb + object of the verb + contextual clarifier
在公司中，我们运用的是这样一个格式:
The circumstance people are in today(When I…), the goals they want to achieve(helpme…), the obstacles in the ways of achieving their goals(but…), and their desired outcomes(soI….)
举个例子Job statement的例子，
“当我想要准备一个汇报时，相关的指示和重要文件散落在各种app和工具里，帮助我快速搜集对我有用的材料，让我最终有一个成功的表现并且看起来很专业。”
“When I have to prepare for a presentation, but relevant conversations and files are scattered across apps, help me quickly gather key context, so I can have a successful interaction and look professional.”
3.如何得出JTBD
用户研究
用户研究是得出Job statements的重要手段，无论是创造一个新产品还是基于已有的成熟产品做出革新。除了常规的用户研究方法，还有一些得出Job statements的技巧，
- 找到那些运用“非正常手段”来达到其目的的用户（the users who hacked your products)，从他们身上你可能得出一些潜在的需求。
- 观察用户的情景和动机，从功能需求，社会需求和心理需求多方考虑。
- 把用户的【抱怨】和【行为】分开来看，进行挖掘。有些用户不抱怨不代表Job不存在；有些用户抱怨也不代表Job真的存在。
- 关注用户已经摈弃的解决方案，并且明白为什么。
- 重点关注早期或者有极强需求的用户。因为他们都是因为一些特殊的job而“雇佣”这个产品，可以给予我们灵感，刺激我们发现新的机会点。
运用数据支持
除了定性的用户研究，数据团队也可以帮助定义Job statement。如果是已经存在的产品，数据团队可以观察数据趋势来支持或证明定性研究的结论是否合理。并且Job statement一旦确定，我们可以通过和数据团队的的合作来预测机会大小，然后排列优先级。如果是全新产品，我们也可以针对市场研究和竞品数据佐证之前的假设。
4.如何运用到项目中
帮助有目标地进行头脑风暴
无论头脑风暴，小组讨论，还是设计冲刺最忌讳的一点就是没有目标，大家的点子发散又零碎。Job statments可以帮助我们有目的地进行这些活动。无论是把已经整理好的Job statement带入头脑风暴中，还是在大家一起去创造新的，每个人都可以拥有一个较高的视角，清晰地围绕着Job思考解决方案，保证最后的产出。常规的设计流程中，我们的步骤是用户旅程→痛点→ HMW，如果我们通过JTBD的framework，把痛点进行再定义，我们不仅可以过滤掉一些没有价值的痛点，还可以提炼出更广义的需求，扩大创新领域。
帮助制定长期的产品策略
运用JTBD的framework可以帮助我们思考：我们的产品因为什么而被雇佣，我们的产品将来想要因为什么被雇佣。
1. 如果你的公司已经有了一个较为成熟的产品，你必须要明白用户为什么会选择你，而不是你的竞争者。就算你没有“产品”上的竞争者，消费者也会有其他方式达成他们的目的。
明白你的产品现在因为什么Jobs而被雇佣可以帮助你：
- 继续发展那些用户依赖的Jobs，并且不断提升体验。
- 不要围绕不存在的Jobs设计新功能。
- 了解你的主要竞争者，明白你在市场的位置，然后努力制造辨识度和竞争点。
2. 如果你有一个长期的愿景和发展方向，那么就需要定义你的产品在哪些Jobs上“不是一个strong hire”，并关注那些把你PK下去的产品。就如同我和其他人一起面试一个新岗位，面试官好比用户，我没有得到这个职位，但是其他人得到了，那我需要认真了解，优胜的面试者在哪方面做的优秀。这样我就大概得出这个岗位真正需要的是什么，去弥补这个缺口。
JTBD 增长策略
Tony Ulwick在书中提到了，如何对JTBD有策略地进行调整来达到商业目的。
这个矩阵图表明了公司可以基于JTBD，创造以下四种产品和服务，
- 更好更贵 （赢得未满足需求的用户）- 区分型策略
- 更好更便宜 （赢得所有用户）- 主导型策略
- 更差更便宜 （赢得有限选择的用户）- 离散型策略
- 更差更贵 （赢得过度满足的用户）- 破坏型策略
- 变化不明显（维护当前已有用户）- 保持型策略
在书中作者对这几个策略进行了非常详尽的解释，这里不做赘述。大家有时间可以去翻翻这一章节。
帮助制定优先级
核心的Jobs确定后还可以帮助我们排列优先级，科学地做出取舍。当遇到设计平台型产品时，往往用户需要很多Jobs。这个时候我们可以把设计的功能进行分类，然后检验，我们的方案是否覆盖了所有的核心Jobs，是否缺口还没填埋就在垂直领域投入过深。这个过程可以帮助我们制定优先级，确保整体的增长和商业影响。
最后的最后，JTBD只是一种方法，并不是任何时间都需要用它，不要简单问题复杂化，只有当你有需要的时候才值得你投入时间去创造或总结Job statements。
JTBD的framework尤其适合审视需求的合理性，以及构想0→1 的创新项目。也可以作为一个日常用的批判性思考方式：如果我有一个idea，用户雇佣我的idea，我的核心工作是什么，用户会买账吗，我是否还囿于已有的解决方式里，还是围绕核心问题进行了创新？
引用：《JOBS TO BE DONE: Theory to Practice》https://strategyn.com/jobs-to-be-done/jobs-to-be-done-theory/
原文：https://mp.weixin.qq.com/s/zlhMPsT0SAeDFy2IDjcozw
既然来了，说些什么？