[譯] 如何避免拍腦殼想出的產品優先策略

• 原文地址：How to avoid opinion-based product prioritization
• 原文做者：Tamzin Taylor
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：Yuze
• 校對者：Yuhanlolo, geniusq1981

在看老闆的臉色以外，其實咱們還能夠利用數據來作出更好的決策

產品決策是一件很難的事情。在大部分的公司裏，作決定有時候還須要考慮到不少其餘的因素。有時候會有組織內部競爭者的意見，團隊領導或是老闆我的的見解，甚至有時候是本身想試試新的方案。有時候阻止你作出理性決策的最大障礙來自你的 CEO 或 CFO，由於他們的想法一般你很難拒絕。

既然這是個常見性的問題的話，那麼，成功的 app 開發者們是如何應對那些拍腦殼想出的產品決策的呢？

我採訪了大約 20 個頂尖的開發者，他們當中有來自 Google 的工程師，產品經理，以及成長總監。從這些簡短的採訪中，他們身上都展示了三個重要的特質：

• 他們都會經過實驗來不斷拓寬選擇的可能性。
• 數據是整個過程當中最重要的一環。
• 他們在公司文化中傳播數據的價值以及信息共享的重要性。

在這篇文章中，我會用 2 個例子來展現頂尖的開發者們是如何解決這些問題的。在第一個例子裏面，我很榮幸有機會採用 Google 內部常用的產品優先策略，而且將這個方法應用到了 1tap 這個產品上。第二個例子裏，我很是幸運，能夠內部跟蹤 2017 年最佳應用 Memrise 開發過程當中使用的決策流程，獲得他們團隊對這個方法論的見解。

1tap 和北極星方法

北極星方法 源於硅谷，而且已經有相對悠久的歷史。在 Google 內部，Youtube 團隊和 Gmail 團隊常常用這個方法來幫助他們決定哪一個特性應該被優先開發。根據我對他們的採訪，我發現這樣的方法論對於整個團隊來講都是卓有成效的。咱們在 Google 有專門的這麼一支專業團隊，因此我就順水推舟地讓他們和 1tap 團隊合做來執行這個方法論。

說了這麼久，這個方法論究竟是什麼呢？從概念上講它 很是簡單，只有 4 個部分：一個指北系統，一個用戶流的圖，一個增加模型，還有一個簡單的電子表格。畢竟，全部的數據模型都須要一個電子表格來做爲載體。

那麼接下來就讓咱們一塊兒看看這 4 個東西是如何互相合做來幫助 1tap 解決問題的吧。

設置一個指北系統

對於產品來講，這個系統相似於 KPI 的概念。它所衡量的指標包括該產品獲取用戶，並保持用戶的參與率，轉化率，以及留存率的能力。好比說咱們在作一個旅館預訂應用，那麼這個指標就是用戶預訂數。若是咱們在作一個即時通信應用，那麼這個指標就是發送的信息數。

1tap 的願景是爲了讓自我僱傭變的更加簡單一個團隊。他們在 Google Play Store 上有 2 個應用：用於自動提供自動數據提取和簿記功能的 1tap receipts 以及用於經過收據和帳單來自動計算稅務的 1tap tax。

這一次，咱們用 1tap receipts 來練習這個方法論。咱們很快就決定了此次的指標是交易數量相關的內容。然而，1tap 的首席增加官告訴咱們：「首先，咱們須要搞清楚產品的目標是在鼓勵個體用戶上傳多份收據，仍是吸引更多隻上傳少許收據的用戶呢？」 若是咱們仔細審視 1tap 爲用戶提供的價值，那麼顯而易見地，個體用戶上傳的收據越多，1tap 便能更好地幫助他們管理我的稅務。從這個角度來看，北極星系統所衡量的核心價值是關於個體用戶的，而且每一個用戶上傳的收據越多越好。

定義你的用戶流

實現這個目標主要須要兩步。首先，確認你開發的應用可以收集用戶的反饋。第二，檢查你的指標而且肯定你用戶在通過每一步流程的時候，產品所發揮的效果。這個過程很是簡單，只要：

• 定義你應用裏的關鍵事件。
• 畫出不一樣事件之間的流是如何運做的。
• 運用統計學來觀察用戶們在每一個流停留的比例。

你會發現這個圖有 3 個主要的部分：你對新用戶的獲取，舊用戶的迴歸率，以及整個產品的關鍵事件流。

新用戶的獲取主要就是用戶經過什麼樣的途徑來下載你開發的應用。只要你確保你正確的設置了 UTM 標籤在全部投放的連接之下，而且關聯你的 AdWords 帳戶，你就能從 Google Play 的控制檯裏輕鬆看到你的新用戶獲取途徑。

不過每一個產品的用戶流都是根據具體狀況而定的。可是通常都會包括登錄，上線，轉化率（若是這是個付費產品）。大部分的時候，對於一個app來講會有一個你特別關注的神奇的時刻，也就是關鍵事件流。這個東西不少時候就表明了這個指標，也就是參與率和轉化率指標，因此咱們務必要包含它在指標裏邊兒。

最後，還有重複流，也就是引導用戶返回 app 的東西。

當流程圖完善的時候，整個團隊裏面的成員們就可以以一樣的方式談論這個產品，而且理解用戶和產品之間的交互 — 從用戶獲取、參與、轉化到返回是如何運做的。這個就是北極星指標的影響力。

在 1tap 這個例子裏，這個圖是這樣的：

你會發現他們沒有任何用戶流的分析。對於 1tap 這個應用和團隊來講，認識到讓用戶感受到驚豔的那個時刻纔是最重要的。也就是用戶激活階段。Jon 說：「讓用戶能當即看到自動提取出來的信息，這個就體現了產品的價值，也讓不少用戶被咱們 OCR 技術的準確程度驚豔到了。」

最終的用戶流圖是在迭代了 10 個版本以後才產生的。Jon 認爲初版的這個圖簡直就是一團糟。太過於細節致使整個圖看起來很混亂。而後整個團隊才一塊兒努力簡化那張圖，而且把精力都放在重要的方面。更棒的是，整理這張圖還讓 1tap 的應用去除了不少冗餘的功能。「若是這不是個關鍵點的話，咱們也不必放在 app 裏面吧」，Jon 如是說。

整理了圖以後，1tap 團隊發現他們在用戶流中出現了一個斷點。問題是主要出在用戶在導出數據的時候。如今，他們雖然仍然處在試驗階段，可是保存這些報告的作法已經有效的幫助他們提高了用戶留存率。

構建一個增加模型

下一步就是構建增加模型了。咱們會須要以前在北極星方法中找到的指標來決定咱們應該怎麼樣去發揮咱們的優點以及彌補咱們不夠完善的地方。

就像以前在構建用戶流的圖的時候同樣，1tap 初版的增加模型很是的複雜，有大概 16 頁紙那麼長。可是，經過聚焦重要內容，一個直接可行的成長模型應運而生。成長模型歸納以下：

這裏的關鍵是每一個用戶添加的收據，這就是北極星指標。能夠把它分解成每月活躍用戶（MAU）提交的收據。反過來，它也能夠繼續分解成每一個經過不一樣途徑添加收據的用戶 — 掃描，電郵，手動輸入 — 以及新用戶和回頭客。

當他們剛開始編寫 1tap 這個應用的時候，他們以前花了不少心思在數據分析上，幾乎吧用戶在這個應用上全部行爲都進行了分析，而且這也是他們團隊應覺得傲的一點。然而，Jon 表示，他們的團隊其實不少時候就是由於這個緣由致使不知道從何處開始理解用戶。由於能夠參考的數據維度實在是太多了。可是這個增加模型可以很好的幫助他們經過找出北極星指標來作到這一點。

可是就如 Jon 所說的那樣，這個增加模型的重點是可以幫助向 CEO 解釋月活用戶是從何而來的，也能幫助 CFO 思考利潤是從何而來的。此外，產品還能經過使用這個體系來作更好的決定。

建立一個電子表格

這整個流程的最後一步就是把模型轉化成一張電子表格，而且幫助咱們評估咱們的機會，從而觀察這些機遇是如何幫助咱們的產品增加的。

你也許早就已經發現 1tap 的增加模型會變成一張巨大的電子表格。可是這種狀況下，表格的尺寸是很重要的，下圖就是 Jon 和他的團隊稱做「計算器」其中的一部分。

有了表格以後，1tap 開始探索了十幾天各類活動對於用戶平均收據數量的影響。Jon 發現這麼作的好處就是他們能看到微小的改變給團隊帶來的好處。好比當下載到註冊的轉化率提高 2% 的時候，收據總數翻了一番。對比之下，從註冊到激活到轉化的提高對於總數的影響只有 75%。

隨後，1tap 團隊決定把更多的精力放在讓用戶在使用過程當中更早的發現驚喜時刻（就是註冊階段），而不是簡單的經過花錢去拉攏新用戶。

因此這個流程和模型爲 1tap 帶來了什麼呢？

首先，這些東西讓他們團隊明白了他們在作什麼，什麼是重要的。CEO Nick 不再須要天天都問月活是從哪裏來的以及咱們如何才能增長月活。一切都明明白白的寫在模型裏了。此外，產品對於以後的需求也更加明確，知道如何制定優先級。如今全部決定都由這個「計算器」來作。CFO 也能知道經過增長收入咱們還能提高用戶的留存。基本上每一個人都對團隊下一步的動做能有所感知。

另一個重要影響就是明白瞭如何去增長新用戶。過去他們是不可能有這樣的機會的。如今他們明白了經過和第三方合做去作一些登錄能有效的大量提升用戶獲取，而且提升用戶留存。

最後，Jon 還表示，這個模型還幫助了他們團隊知道何時應該要僱用什麼樣的人。過去他們經常在錯誤的時間僱用不適合的人致使團隊發展緩慢。

Memrise

Memrise，做爲一款語言學習應用，擁有 3500 萬的用戶，而且能過爲他們提供超過200種語言的教學。Kristina Narusk，他們的首席增加官，認爲這家公司的成長路徑是很是幸運的。他們有 Ed Cooke 這樣同時具有創新能力又能很好的運營團隊的人做爲 CEO。Ed 常常有各類各樣的奇思妙想，可是同時，分辨這些想法中哪些能爲產品真正帶來增加也是很是有挑戰性的事情。

舉個例子，Kristina 告訴我三年前的一天，她收到一條來自 Ed 的短信。內容是說他在英國買了一輛雙層巴士，決定在歐洲環遊而且錄下不一樣國家的不一樣語種母語人士說一些話的方式。這是一種很是罕見的事情，因此咱們整個團隊不得不提出各類方案來面對這種奇葩的想法，而且把它和應用的增加結合起來。

Memrise 提出了一種六維驗證法來過濾這些奇妙的想法：

1. 必須是能夠迭代的。咱們可以從一個簡單的 MVP 開始不斷迭代直到完善。
2. 有立竿見影的效果。當新的想法實現的時候須要能給咱們帶來直觀的改變。
3. 有長遠的效果。這個想法須要能在長期幫助咱們的用戶，而不是三分鐘熱度。
4. 必須能夠量化。咱們須要能夠量化產品對用戶的影響。
5. 能夠本地化，可以儘可能覆蓋大量的應用市場。
6. 和產品相關，而且是能夠理解的。

在探索將來新特性的時候，他們團隊會用這個法則來決定開發什麼而不開發什麼。

就像 Kristina 所說的那樣，咱們須要將這個具備創造性和實驗性的思惟方式逐漸灌輸到團隊和公司中。Memrise 把產品的開發週期分爲 4 個階段：探索，定義，開發，和跟進。

在探索階段的時候，產品團隊會畫出 PRD，而且會有用戶來測試這個新的想法。試驗嚐嚐會包含好比設計，用戶體驗，內容方向相關的創新。舉個例子，團隊會找許多路人來測試，亦或者是一些在線的測試或者一些長期用戶來測試新的特性。整個團隊，包括設計師，語言學專家，以及開發者們。然而，Kristina 發如今測試產品的時候，很難讓開發人員們保持冷靜。他們老是會對用戶不能正確打開新的特性而表示不爽。

在 Memrise Membus 這個案例中（就是上面開車環遊歐洲的那個），在探索階段的時候，大巴先開去了牛津拍了些視頻來測試想法是否可行。而不是直接在整個歐洲拍攝。在牛津拍攝英語的視頻就是這個想法的原型。而後發現那個視頻的想法對整個產品帶來的好處很是明顯，並且成本很低。最後咱們就敲定了這個方案。

當這個想法探索完畢以後，咱們就到了定義的階段。這一階段，咱們會明確這個新的想法的功能以及如何和用戶交互。同時，也會明確測試的細節好比：

• 測試的平臺
• 目標用戶
• 目標語言
• 測試周期長度
• 須要關注的東西
• 分析看板應該包括的東西

數據團隊也參與其中。他們幫助確保該功能的構建是爲了捕獲正確的數據點，以便產品團隊能夠評估該功能的影響。這些視頻用於建立高級學習模式，並做爲專業版訂閱的一部分。所以，瞭解將此模式添加到英語課程中對專業版用戶轉化率的影響是很重要的。在階段結束時，整個團隊充當用戶，對產品構思和預測結果提供反饋。

當全部的東西都準備好以後，咱們就會進入開發的這個階段。由於開發團隊早就以及參與了探索和定義的階段，因此在開發的時候就很是直接了，你們也知道開發特性的緣由會是什麼。

當開發結束以後，須要產品經理決定要不要正式啓用這個特性，這樣用戶就能夠發現什麼被更新了，而且開始測試這些新的特性。

當應用的新版本被髮布的時候，咱們就到了跟進這個階段。在這個階段的時候，團隊會傾向於回答問題好比 KPI 怎麼樣？用戶的初次反饋是什麼？新的特性對於應用的評分有什麼樣的影響？理想狀況下，按照 Kristina 說的那樣，這個時刻是很是享受的，由於咱們能夠看到結果是如何產生的。

YouTube 視頻連接：https://youtu.be/e2RPXKi4e90

在 Memrise，他們爲每一個實驗都有一套標準和圖表。「發佈後的次日，你會發現咱們一直在刷新這個頁面，」 Kristina 說：「看看這個功能和新想法的表現如何。就咱們團隊來講，咱們看到出來的結果很興奮，並且讓咱們知道咱們作的東西是否成功是否被人們所喜好，仍是須要回到白板面前再從新思考。」Memrise 最終決定爲全部語言添加視頻以及對應的學習以及本地模式。

結論

在這篇文章開始的時候我就已經說過作決定是困難的。遠離拍腦殼作決定也許更加難。然而，經過分享這兩個不一樣的作決定的方式，我但願我能幫你在爲產品作決定這件事上有新的觀感。不管流程是怎樣的，必定要讓團隊裏的人都參與到這個流程裏面來，在數據的支持下找到合適的改變，亦或是合適活動讓用戶參與進來。

---

你的想法？

若是你對決策制訂以及優先級分級你本身的想法的話，歡迎你在下面評論，或者在推特上給咱們留言，而且關注咱們分享的最新信息。

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。