如何串连三个「语言工具」描述简洁清晰的需求?

在上篇文章《怎样简洁明了地说清楚产品需求?》中,我们介绍了用于描述需求的两个「结构化语言工具」,分别是「任务规格书 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 特别注重提升,因此提出「期望成果」这个语言工具,并直接认定「提升」才能代表用户需求。

下面这张图,简洁说明了「期望成果」的结构:
“Giving Customers a Fair Hearing”, MIT Sloan Management Review, 2008

Ulwick 说明 Desired Outcome Statement 是「用户定义的指标,让提升变成可被衡量、被掌握、被预测的过程」,必须透过访谈挖掘用户期待的提升,再转化成「期望成果」的语言结构。

换句话说,虽然我们难以衡量体验本身(毕竟设计与美感带有主观成分),但可以衡量「体验带来的结果」。除此之外,衡量「期望成果」和「目前成果」的差距,就成了 ODI 创新流程中的关键方法。

在 Christensen 在《创新者的用途理论》中也提出类似概念。他认为,用途理论不仅改善流程精进的方向,也会改变衡量成效的方式。它把关键的绩效标准从「内部的财务绩效指标」转变成「外部的顾客效益指标」。

我觉得上面两个说法太冗长、太绕口,改用以下方式称呼:

  • 商业成功指标 Business Success Metrics:各类财务指标、生产与物流的效率指标、服务流程的漏斗转换率,通常以「优化绩效」为目标。关注这些指标的主角,大概九成以上是公司本身、或团队成员、或股东的金融分析师。
  • 用户成功指标 Customer Success Metrics:以用户为主角的指标,以期望成果为代表,是用户衡量「特定场景下获得多少提升」的方法。虽然用户内心知道衡量的方式,但未必能精确表达出来,需要挖掘、萃取与转化。

这边举个例子,协助大家理解「访谈内容」转化成「期望成果」的前后对照。以「商品详细页」上的「商品评价」来说,我们在访谈中询问用户:

  • 什么时候会用商品评价?
  • 哪些情况,让你觉得商品评价很难用?
  • 你希望商品评价如何帮助你?

我们获得了这个用户的这段话:

大概购买前都会略看评价,(用评价中的照片)看看和商品照有没有误差,特别找评分低或大串文字的评价,看看缺点。觉得评价会很大地影响购买行为,会推坑帮助下决心,也会补足商品规格的不足。觉得困扰的是常常看到不相干的商品评价,或看到评分太高等,反而让人特别担心,有时候是反指标。

当然,这只是其中一小段访谈记录。访谈过多位用户,发现了商品评价带给用户的提升,其实就是:减少顾客「发现产品不符合期待」的情况,特别在结账前一刻,或收到商品之后

这句话是挖掘、浓缩、转化后的结果,访谈后我们必须从多位用户身上,自己辨识出这一个重复出现的期待。每位用户虽然用了不一样的描述方式,但其实都在讲相同的期望成果。

如果已经有办法浓缩出用户成功指标,「期望成果」适合用在以下情境:

  • 当队友不理解产品、功能、专案对用户有什么价值时,用简短的一句话破题,开门见山地传达「用户成功指标」,然后再补充更多情境与实例;
  • 放在任何需要描述「目标」的地方,例如:PRD 、产品/功能提案、专案简报、年度或季度的目标设定、OKR 中的 Key Results;
  • 放在「任务故事」的 So I can (Expected Outcome) 段落

思考

如何串连三个工具?

我们用了两篇文章,介绍「用途理论」中的三种「语言结构」(任务规格书、任务故事、期望成果),当我们下次面对三种状况时,希望能带来以下效果:

  1. 减少「建立方法」时「花费的时间」或「遭遇的排斥」,融入现有方法,相辅相成。
  2. 减少「叙述需求」时「花费的时间」,口头沟通时可浓缩成 3 句话,文字沟通时可浓缩成 1 页 A4 文件。
  3. 减少「依场景重置沟通素材」所「花费的时间」,可以有弹性地重组、合并、拆分。

经过前面的介绍,举例来说,我们可以这样运用:

  • 口头沟通时,先传达期望成果,再用任务故事补充,厘清目标和用户需求;
  • 短文沟通时,以期望成果任务故事开头,放在 PRD 或产品/功能提案中;
  • 长文沟通时,把期望成果任务规格书融入现有的研究报告中,搭配 UX 工具箱中「浓缩研究成果的图表」,图文并茂、相辅相成;
  • 期望成果、任务故事、任务规格书中替换相同内容,善用三者类似的结构,快速重组、合并、拆分。

经过这段探索与浓缩「用途理论」的过程,我发现这套语言结构,确实有串连各种工具的能力。当然,用途理论的观念不算是跨时代的进步,因为过去也有很多领域提出类似见解,例如:用户研究、设计理论、人类学、心理学、认知科学等等。如果接触过这些知识,读用途理论时很容易有「似曾相识」的感觉,甚至觉得只不过是「老调重弹」或「旧酒新瓶装」。

我觉得用途理论的漂亮之处,就在于它提出了够简单、够简洁的「思考框架」和「语言结构」。这带来两种效果:第一是帮助许多人在没有以上前置知识的状况下,也能在实务中直接应用;第二是帮助有前置知识的人「化繁为简」,在实务中串连各领域的知识和工具,并和没有相关知识的队友沟通协作。换句话说,这是一个「把理论带向实务」的桥接工具,因为已经精简到无法再简化的程度,所以才有办法贯穿各领域的知识之墙。

除此之外,我们千万不要小看「语言工具」的力量。产品经理的工作中,有太多时间要花在参与会议、口头协商、做简报、写文件,本质上「语言」就是我们吃饭的「工具」。如果有一套好用的语言工具,可以省去我们很多麻烦,建立有效的协商默契,并维持稳定的沟通品质,实在太重要了。

再进一步,还想跟大家分享一个私人的工作秘诀,那就是:产品经理要服务非常多的「用户」,包含了密切合作的伙伴——每个合作对象都是「使用产品经理的用户」

在合作过程中,如果我们也用「期望成果」记录每个合作对象的期待,综合比对后,再说明我们必须面对的取舍,就能很有效地「厘清问题」并「沟通目标」。有句话说,每个伟大的产品,后面都有伟大的产品经理。伟大之处,也许就在于—— TA 用心观察、细心体会了每个用户的「用途」与「期望成果」。

本文作者: Jason HOU
文章来源: Medium


>> LigaAI 往期精彩阅读 <<

怎样简洁明了地说清楚产品需求?

为什么我们总是说不清「需求是什么」

技术分享 | Javaer 如何做单元测试?

敏捷实践 | 做优先级排序时使用最多的三个模型

了解更多敏捷开发、项目管理、行业动态等消息,关注我们的团队博客或点击 LigaAI-智能研发协作平台,在线申请体验我们的产品。