在上篇文章《怎样简洁明了地说清楚产品需求？》中，我们介绍了用于描述需求的两个「结构化语言工具」，分别是「任务规格书 Job Spec 」和「任务故事 Job Story 」。本篇文章希望进一步跟大家分享：
- 语言工具三：期望成果 Desired Outcome
如何串连三个工具？
工具三：期望成果 Desired Outcome
如果很疑惑「任务故事」中的 Expected Outcome 要写什么，别想太多，直接来看 「ODI 创新流程 Outcome-Driven Innovation 」中的 Desired Outcome Statement。我觉得这是整个理论界的核心关键之一，有承先启后的作用，也给了用途理论（Jobs To Be Done，即 JTBD 理论）极大的差异性。
ODI 创始人 Tony Ulwick 可能比 Christenson 更早开始研究、应用用途理论，他口中的用途理论，跟 Christenson 有个重大差异：
任务「就是」用户在特定「场景」中，能获得「提升」。
A job is the progress that an individual seeks in a given situation.
在 Christenson 的版本中，他则说：任务「使得」（enables）用户获得提升。由此可见， Ulwick 特别注重提升，因此提出「期望成果」这个语言工具，并直接认定「提升」才能代表用户需求。
下面这张图，简洁说明了「期望成果」的结构：
Ulwick 说明 Desired Outcome Statement 是「用户定义的指标，让提升变成可被衡量、被掌握、被预测的过程」，必须透过访谈挖掘用户期待的提升，再转化成「期望成果」的语言结构。
换句话说，虽然我们难以衡量体验本身（毕竟设计与美感带有主观成分），但可以衡量「体验带来的结果」。除此之外，衡量「期望成果」和「目前成果」的差距，就成了 ODI 创新流程中的关键方法。
在 Christensen 在《创新者的用途理论》中也提出类似概念。他认为，用途理论不仅改善流程精进的方向，也会改变衡量成效的方式。它把关键的绩效标准从「内部的财务绩效指标」转变成「外部的顾客效益指标」。
我觉得上面两个说法太冗长、太绕口，改用以下方式称呼：
- 商业成功指标 Business Success Metrics：各类财务指标、生产与物流的效率指标、服务流程的漏斗转换率，通常以「优化绩效」为目标。关注这些指标的主角，大概九成以上是公司本身、或团队成员、或股东的金融分析师。
- 用户成功指标 Customer Success Metrics：以用户为主角的指标，以期望成果为代表，是用户衡量「特定场景下获得多少提升」的方法。虽然用户内心知道衡量的方式，但未必能精确表达出来，需要挖掘、萃取与转化。
这边举个例子，协助大家理解「访谈内容」转化成「期望成果」的前后对照。以「商品详细页」上的「商品评价」来说，我们在访谈中询问用户：
- 什么时候会用商品评价？
- 哪些情况，让你觉得商品评价很难用？
- 你希望商品评价如何帮助你？
我们获得了这个用户的这段话：
大概购买前都会略看评价，（用评价中的照片）看看和商品照有没有误差，特别找评分低或大串文字的评价，看看缺点。觉得评价会很大地影响购买行为，会推坑帮助下决心，也会补足商品规格的不足。觉得困扰的是常常看到不相干的商品评价，或看到评分太高等，反而让人特别担心，有时候是反指标。
当然，这只是其中一小段访谈记录。访谈过多位用户，发现了商品评价带给用户的提升，其实就是：减少顾客「发现产品不符合期待」的情况，特别在结账前一刻，或收到商品之后。
这句话是挖掘、浓缩、转化后的结果，访谈后我们必须从多位用户身上，自己辨识出这一个重复出现的期待。每位用户虽然用了不一样的描述方式，但其实都在讲相同的期望成果。
如果已经有办法浓缩出用户成功指标，「期望成果」适合用在以下情境：
- 当队友不理解产品、功能、专案对用户有什么价值时，用简短的一句话破题，开门见山地传达「用户成功指标」，然后再补充更多情境与实例；
- 放在任何需要描述「目标」的地方，例如：PRD 、产品/功能提案、专案简报、年度或季度的目标设定、OKR 中的 Key Results；
- 放在「任务故事」的 So I can (Expected Outcome) 段落。
思考：如何串连三个工具？
我们用了两篇文章，介绍「用途理论」中的三种「语言结构」（任务规格书、任务故事、期望成果），当我们下次面对三种状况时，希望能带来以下效果：
- 减少「建立方法」时「花费的时间」或「遭遇的排斥」，融入现有方法，相辅相成。
- 减少「叙述需求」时「花费的时间」，口头沟通时可浓缩成 3 句话，文字沟通时可浓缩成 1 页 A4 文件。
- 减少「依场景重置沟通素材」所「花费的时间」，可以有弹性地重组、合并、拆分。
经过前面的介绍，举例来说，我们可以这样运用：
- 口头沟通时，先传达期望成果，再用任务故事补充，厘清目标和用户需求；
- 短文沟通时，以期望成果和任务故事开头，放在 PRD 或产品/功能提案中；
- 长文沟通时，把期望成果和任务规格书融入现有的研究报告中，搭配 UX 工具箱中「浓缩研究成果的图表」，图文并茂、相辅相成；
- 在期望成果、任务故事、任务规格书中替换相同内容，善用三者类似的结构，快速重组、合并、拆分。
经过这段探索与浓缩「用途理论」的过程，我发现这套语言结构，确实有串连各种工具的能力。当然，用途理论的观念不算是跨时代的进步，因为过去也有很多领域提出类似见解，例如：用户研究、设计理论、人类学、心理学、认知科学等等。如果接触过这些知识，读用途理论时很容易有「似曾相识」的感觉，甚至觉得只不过是「老调重弹」或「旧酒新瓶装」。
我觉得用途理论的漂亮之处，就在于它提出了够简单、够简洁的「思考框架」和「语言结构」。这带来两种效果：第一是帮助许多人在没有以上前置知识的状况下，也能在实务中直接应用；第二是帮助有前置知识的人「化繁为简」，在实务中串连各领域的知识和工具，并和没有相关知识的队友沟通协作。换句话说，这是一个「把理论带向实务」的桥接工具，因为已经精简到无法再简化的程度，所以才有办法贯穿各领域的知识之墙。
除此之外，我们千万不要小看「语言工具」的力量。产品经理的工作中，有太多时间要花在参与会议、口头协商、做简报、写文件，本质上「语言」就是我们吃饭的「工具」。如果有一套好用的语言工具，可以省去我们很多麻烦，建立有效的协商默契，并维持稳定的沟通品质，实在太重要了。
再进一步，还想跟大家分享一个私人的工作秘诀，那就是：产品经理要服务非常多的「用户」，包含了密切合作的伙伴——每个合作对象都是「使用产品经理的用户」。
在合作过程中，如果我们也用「期望成果」记录每个合作对象的期待，综合比对后，再说明我们必须面对的取舍，就能很有效地「厘清问题」并「沟通目标」。有句话说，每个伟大的产品，后面都有伟大的产品经理。伟大之处，也许就在于—— TA 用心观察、细心体会了每个用户的「用途」与「期望成果」。
本文作者: Jason HOU
文章来源: Medium
了解更多敏捷开发、项目管理、行业动态等消息，关注我们的sf账号-LigaAI~ 或者点击LigaAI-新一代智能研发协作平台，在线申请体验我们的产品。