這篇文章我翻譯於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. 一個產品能成功，是因為它為人們解決了一個問題。這聽起來非常基礎，但這是理解設計優秀產品唯一最重要的事情。

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協議