上一篇文章，我們介紹了「用途規格 Job Spec」和「用途故事 Job Story」，這篇文章，希望進一步跟大家分享：
- 渴望成果 Desired Outcome
- 串連三個工具
工具三：渴望成果 Desired Outcome
如果很疑惑 Job Story 中的 Expected Outcome 要寫什麼，別想太多，直接來看 「ODI 創新流程」（Outcome-Driven Innovation ）中的 Desired Outcome Statement。我覺得這是整個用途理論界的核心關鍵之一，有承先啟後的作用，也給了用途理論極大的差異性。
ODI 創始人 Tony Ulwick 可能比 Christenson 更早開始研究、應用用途理論，他口中的用途理論，跟 Christenson 有個重大差異：
用途「就是」顧客在特定「情境」中，能獲得「進展」。
A job is the progress that an individual seeks in a given situation.
在 Christenson 的版本中，他則說：用途「使得」（enables）顧客獲得進展。由此可見， Ulwick 特別注重進展，因此提出「渴望成果」（Desired Outcome）這個語言工具，並直接認定「進展」才能代表顧客需求。
下面這張圖，簡潔說明了 Desired Outcome 的結構：
Ulwick 說明 Desired Outcome Statement 是「顧客定義的指標，讓進展變成可被衡量、被掌握、被預測的過程」，必須透過訪談挖掘顧客期待的進展，再轉化成 Desired Outcome 的語言結構。換句話說，雖然我們難以衡量體驗本身（畢竟設計與美感帶有主觀成分），但可以衡量「體驗帶來的結果」。除此之外，衡量「渴望結果」和「目前成果」的差距，就成了 ODI 創新流程中的關鍵方法。
在 Christensen 在【創新的用途理論】中也提出類似概念，他認為「用途理論不僅改善流程精進的方向，也會改變衡量成效的方式。它把關鍵的績效標準從『內部的財務績效指標』轉變成『外部的顧客效益指標』。」
我覺得上面兩個說法太冗長、太繞口，改用以下方式稱呼：
- 商業成功指標（Business Success Metrics）：各類財務指標、生產與物流的效率指標、服務流程的漏斗轉換率，通常以「優化績效」為目標。關注這些指標的主角，大概九成以上是公司本身、或團隊成員、或股東的金融分析師。
- 顧客成功指標（Customer Success Metrics）：以顧客為主角的指標，以 Desired Outcome 為代表，是顧客衡量「特定情境下獲得多少進展」的方法。雖然顧客內心知道衡量的方式，但未必能精確表達出來，需要挖掘、萃取、與轉化。
這邊舉個例子，協助大家理解「訪談內容」轉化成「Desired Outcome」的前後對照。以「商品詳細資訊頁」上的「商品評價」來說，我們在訪談中詢問顧客：
- 什麼時候會用商品評價？
- 哪些情況，讓你覺得商品評價很難用？
- 你希望商品評價如何幫助你？
我們獲得了這個顧客的這段話：
「大概購買前都會略看評價，（用評價中的照片）看看和商品照有沒有誤差，特別找星星數少或大串文字的評價，看看缺點。覺得評價會很大地影響購買行為，會推坑幫助下決心，也會補足商品規格的不足。覺得困擾的是常常看到不相干的商品評價，或看到太多星等（很高的評價），反而讓人特別擔心，有時候是反指標。」
當然，這只是其中一小段訪談紀錄。訪談過多位用戶，發現了商品評價帶給顧客的進展，其實就是：
| 減少顧客「發現產品不符期待」的情況，特別在結帳前一刻，或收到商品之後。
這句話是挖掘、濃縮、轉化後的結果，訪談後我們必須從多位用戶身上，自己辨識出這一個重複出現的期待。每位顧客雖然用了不一樣的描述方式，但其實都在講相同的渴望成果。
如果已經有辦法濃縮出顧客成功指標，渴望成果 Desired Outcome 適合用在以下情境：
- 當隊友不理解產品、功能、專案對顧客有什麼價值時，用簡短的一句話破題，開門見山的傳達「顧客成功指標」，然後再補充更多情境與實例
- 放在任何需要描述「目標」的地方，例如： PRD 、產品/功能提案、專案簡報、年度或季度的目標設定、OKR 中的 Key Results
- 放在 Job Story 的 So I can （Expected Outcome）段落
串連三個工具
我們用了兩篇文章，介紹「用途理論」中的三種「語言結構」（Job Spec, Job Story, Desired Outcome），當我們下次面對三種狀況時，希望能帶來以下效果：
- (1) 減少「建立方法」時「花費的時間」或「遭遇的排斥」，融入現有方法，相輔相成
- (2) 減少「敘述需求」時「花費的時間」，口頭溝通時可濃縮成 3 句話，文字溝通時可濃縮成 1 頁 A4 文件
- (3) 減少「依情境重置溝通素材」所「花費的時間」，可以有彈性的重組、合併、拆分
經過前面的介紹，舉例來說，我們可以這樣運用：
- 口頭溝通時，先傳達 Desired Outcome，再用 Job Story 補充，釐清目標和顧客需求
- 短文溝通時，以 Desired Outcome 和 Job Story 開頭，放在 PRD 或產品/功能提案中
- 長文溝通時，把 Desired Outcome 和 Job Spec 融入現有的研究報告中，搭配 UX 工具箱中「濃縮研究成果的圖表」，圖文並茂、相輔相成
- 在 Desired Outcome、Job Story、Job Spec 中替換相同內容，善用三者類似的結構，快速重組、合併、拆分
經過這段探索與濃縮「用途理論」的過程，我發現這套語言結構，確實有串連各種工具的能力。當然，用途理論的觀念，不算是跨時代的進步，因為過去也有很多領域提出類似見解，例如：用戶研究、設計理論、人類學、心理學、認知科學等等。如果接觸過這些知識，讀用途理論時很容易有「似曾相似」的感覺，甚至覺得只不過是「老調重彈」或「舊酒新瓶裝」。
我覺得用途理論的漂亮之處，就在於它提出了夠簡單、夠簡潔的「思考框架」和「語言結構」。這帶來兩種效果：第一是幫助許多人在沒有以上前置知識的狀況下，也能在實務中直接應用；第二是幫助有前置知識的人「化繁為簡」，在實務中串連各領域的知識和工具，並和沒有相關知識的隊友溝通協作。換句話說，這是一個「把理論帶向實務」的橋接工具，因為已經精簡到無法再簡化的程度，所以才有辦法貫穿各領域的知識之牆。
除此之外，我們千萬不要小看「語言工具」的力量。產品經理的工作中，有太多時間要花在參與會議、口頭協商、做簡報、寫文件，本質上「語言」就是我們吃飯的「工具」。如果有一套好用的語言工具，可以省去我們很多麻煩，建立有效的協商默契，並維持穩定的溝通品質，實在太重要了。
再進一步，還想跟大家分享一個私人的工作祕訣，那就是：
產品經理要服務非常多的「用戶」，包含了密切合作的夥伴 — 每個合作對象都是「使用產品經理的用戶」。
在合作過程中，如果我們也用「渴望成果」記錄每個合作對象的期待，綜合比對後，再說明我們必須面對的取捨，就能很有效的「釐清問題」並「溝通目標」。有句話說，每個偉大的產品，後面都有偉大的產品經理。偉大之處，也許就在於 — 她用心觀察、細心體會了每個用戶的「用途」與「渴望成果」。
在工作中使用這三個語言工具，過了一段時間，我開始思考這幾個問題：
- 如何串連 Growth Hacking 或 Product Development 中常用的「假設-驗證」思維呢？
- 如何順暢的重組、合併、拆分，達成效果 (3)，減少「依情境重置溝通素材」所「花費的時間」呢？
- 有了這些工具，然後就一路暢通了嗎，還會遇到什麼問題？
- 用途理論還能串連到哪裡呢？
希望還有後續的文章，繼續分享這些主題。感謝各位讀到最後，下一篇文章預計分享「抽象層級」和「用途-產品假設」。
如果你對用途理論也感興趣，或者想繼續看到系列文章，歡迎 [留言] 或 [鼓掌] ，藉此督促我不得拖稿囉！去看「用途理論」系列文章：