這篇文章我翻譯于17年5月12日，但是在工作中，我還是常常會把它再讀一遍，每次總有新的收獲，對手頭在做的一些項目起到指導意義。后來，我索性把它的鏈接加入到了公司wiki的PRD的默認模版中，讓團隊中每位產品經理寫下PRD前都看一遍。

這篇文章我翻譯于17年5月12日，但是在工作中，我還是常常會把它再讀一遍，每次總有新的收獲，對手頭在做的一些項目起到指導意義。后來，我索性把它的鏈接加入到了公司wiki的PRD的默認模版中，讓團隊中每位產品經理寫下PRD前都看一遍。

最近公司內部發起了一個產品社團，有幸加入其中，作為成員任務的一部分，我們決定翻譯一些外網優質的內容。從此自己的英文技能點也不再局限于給開關命名（諸如：login_switch），算是一大幸事。

本篇原名“Building Products”由Julie Zhuo（Product design VP @ Facebook）撰寫于Meduim，主要根據她的工作經驗，從“籌備階段、執行階段、衡量成果、團隊建設”四個角度，總結了一些她認為行之有效的產品設計原則。

我讀后，覺得有的和我過往的經驗很契合，有的有助于目前我遇到的一些問題。希望也可以給各位帶來一些收獲。

有一定英文基礎的同學，建議直接在Medium上搜Julie Zhuo。

點擊查看原文

最近，我參與了一場TNW Europe的訪談，探討我們在Facebook應用的產品設計方法論。參與這次訪談，讓我回想起以往在打造成功產品時所沉淀下的經驗。

以下這份產品設計check list，既不完整，也不絕對。如果世上能有一份完美的指引手冊（第一步：獲取靈感；第二步：？？？；第三步：賺錢了?。?，那我們早可以花錢把它買下，然后一邊拍著同伴的背，一邊看著神奇新穎的產品如雨后春筍般冒出。

這里列出的僅僅是很小的一部分經驗，我們需要更多的探索和學習。

籌備階段

1. 一個產品能成功，是因為它為人們解決了一個問題。這聽起來非?；A，但這是理解設計優秀產品 唯一最重要的事情。

2. 設計新產品的第一步是去理解： 你為誰，解決什么問題。這一點，在你開始著手設計任何方案前，必須非常清晰。

3. 你問自己的第二個問題，應該是：“為什么這個特殊的問題 值得被解決？”。

4. 如果你的目標用戶群體的定義是非常窄的，那么你可以嘗試依靠自己的 直覺去引導產品設計決策。如果不是，那么你需要依賴 調查和數據來支撐你的決策；

5. 如果你是0到1創建一個產品，把目標用戶群定位得更加狹窄，會讓你的路走得更順一些。等產品吸引到一些注意之后，再嘗試擴大你的目標用戶群體。

6. 你解決的問題，應該很容易用 一兩句話解釋給你的目標用戶。如果不能做到，預示著一盞大紅燈亮起。

執行階段

7. 好的執行的定義： 在最短的時間里得到最可信的結論。

8. 壞的執行的定義：嘗試某件事情，失敗了，但是： a)從失敗的結果里無法得出經驗教訓（因為你不清楚到底為什么失敗了）或者 b）它耗費了你一年的時間，但其實有一條更聰明的辦法可以在三個月內解決。

9. 辨別團隊是否成功，并不是它們做的事情是否失敗了，而是他們在多大程度上能 持續地保持好的執行力。

10. 當你嘗試解決一個問題時， 先發散，再聚焦。在作出決定前，先頭腦風暴10個、20個、50個方案。前5個方案，會是比較明顯的能想到的。創造力開始在第11個、第20個或第50個方案。

11. 如果你在演示一個方案的時候，別人問到：“你有想過X方案嗎？”，如果你的答案是“沒有”，意味著你的對解決方案的探索遠遠不夠。

12. 使用 實證分析方法（empirical evidence）幫助你縮減頭腦風暴得出的方案。（例如，選擇前N個大家認為最好的方案，做出高保真的原型，放在用戶面前看實際效果）。

13. 一旦你決定了你想執行下去的方案，把它表達成一種預期： 如果你真的把它做出來了，預期會發生什么結果？（比如：我希望解決的問題是確保每個居民都能知道本地的周末活動信息。我們的預期是：通過郵件列表，可以觸達X%的居民。）

14. 你應該 持續尋找方法來檢驗你的假設。你可以嘗試在街上隨便問一個人，看你的方案是否能被理解。你可以嘗試做一份調查，看是否有足夠的人對你的想法感興趣。你可以創建一個并非盡善盡美的原型，嘗試快速得到一個明確的結論。

15. 一旦你的方案上線后獲得一些積極的信號，不要想著需要馬上鋪開全量（擴大用戶范圍）。做方案優化時，全量鋪開的標準需要不斷調整。測試和全量的檢驗標準應該有所不同。

16. 如果你的項目范圍非常大，涉及到非常多的改動，嘗試是否能把它 拆解成更小的、可獨立測試的里程碑。不要陷入這種陷阱： 改了5個地方，得到不好的結果，卻不知道哪一個改動出了問題。

17. 每個項目結束后，不管成功與否，都做一個組內回顧。從這個項目你個人學習到了什么？團隊學習到什么？將來你會做出什么改變？然后把這樣的經驗分享給全公司。

衡量成功

18. 你 如何衡量成功對團隊的長期產出非常重要，因為這是大家關注的核心。要確保給這件事情足夠的時間和關注。（甚至，大于你在思考解決方案的時間）。

19. 你需要 在產品發布前，定義成功。否則，如果在產品發布后，你試圖從結果進行解釋，證實性偏見（confirmation bias）會造成不客觀的解讀。

20. 使用“魔法球方法“幫助你找到衡量成功的正確方式：問自己 “如果我能知道任何人使用我的產品，我希望聽到什么”，來告訴我我的產品是否成功？”（通常你獲得的回答不會是“某個按鈕的點擊率”，而是更為抽象的，比如“多少人通過使用我的產品，從中獲益”）。然后， 從你獲得的答案，反過來想你可衡量的成功矩陣應該是怎樣的。

21. 你的目標應永遠建立在 最新的有效信息之上。如果你在朝著一個早已定義好的目標前進，途中獲取了一些改變你想法的新的信息，你應該考慮是否根據這些信息來調整你的目標。

22. 如果你發現你的團隊無法理解或認同衡量團隊成功的方式，你應該點出這個問題。更早地暴露這種問題，可以從根本上提高效率和創造好的成果。

23. 如果你發現自己經常跟團隊對于產品方向產生爭論，根源的問題很可能是各自認為的理解衡量成功的方式不同。你可以嘗試提出建議以其他的方式來衡量團隊的成功。

24. 如果你想弄明白你的產品是否符合市場需求，最好留意產品的 用戶留存率（有多少用戶愿意當回頭客），而不是盯著獲取更多的用戶。

團隊角度

25. 僅按照自己的角色（產品經理應該做什么？程序員應該做什么？）來思考，會限制你的影響力。而應該換一種角度，以 “我能做什么來幫助自己的團隊成功”來思考自己在團隊中的角色。

26. “喜歡挑戰問題”的團隊，會比“喜歡特定解決方案”的團隊獲得更多的成功。這是因為，即使失敗了很多次，值得被解決的問題仍會持續地激勵著團隊繼續走下去。

27. 對待團隊成員，要永遠 懷揣善意。我的意思是，其實任何人都想做一些偉大的事情。也許這樣做，偶爾不會有好的回報，但你還是會因此省去很多不必要的麻煩。

28. 你需要知道自己擅長的是什么，還有你的團隊成員各自擅長什么。然后把最合適的人安排在最合適的位置。

29. 良好的溝通是保持團隊健康的關鍵保證。任何成員都應該覺得可以很自由地發表自己的觀點（盡管有的觀點可能存在局限）。有多樣化的想法才能幫助團隊獲得好成果。所以，不要害怕表達你的想法，不要害怕當別人可能沒有聽清或理解你的想法時進行復述，還有，要盡最大努力為其他團隊成員維護這種安全感的氛圍。

作者：張路，微信公眾號“PathsVIVI”

本文由 @張路 翻譯發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議