共计 2895 个字符，预计需要花费 8 分钟才能阅读完成。
在上篇文章《怎么简洁明了地说分明产品需要？》中，咱们介绍了用于形容需要的两个「结构化语言工具」，别离是「工作规格书 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- 新一代智能研发合作平台，在线申请体验咱们的产品。
