啟示錄：打造用戶喜愛的產品

好產品靠設計

富有創意的產品從不來自偶然，以下是作者總結的十條成功產品的規律：

1. 產品經理的任務是探索產品的價值、可用性、可行性。
2. 探索（定義）產品需要產品經理、交互設計師、軟件架構師通力合作。
3. 開發人員不擅長用戶體驗設計，因為開發人員腦子里想的是實現模型，而用戶看重的是產品的概念模型。
4. 用戶體驗設計就是交互設計、視覺設計（對硬件設備來說，則是工業設計）。
5. 功能（產品需求）和用戶體驗設計密不可分。
6. 產品創意必須盡早地、反復地接受目標用戶的試用，以便獲取最有效的用戶體驗。
7. 為了驗證產品的價值和可用性，必須盡早地、反復地請目標用戶測試產品創意。
8. 采用高保真的產品原型是全體團隊成員了解用戶需求和用戶體驗最有效的途徑。
9. 產品經理的目標是在最短的時間內把握復雜的市場/用戶需求，確定產品的基本要求——價值、可用性、可行性。
10. 一旦認定產品符合以上基本要求，它就是一個完整的概念，去掉任何因素，都不可能達到預期的結果。

Part1 人員

Ch1 · 關鍵角色及其職責

現代軟件產品團隊

• 產品經理：評估產品機會，定義要開發的產品。（文檔應該描述產品的功能和屬性，避免討論產品的實現方法）

• 用戶體驗設計師：用戶體驗設計團隊由多重角色組成，最關鍵的角色是——交互設計師（也稱信息架構師、用戶界面設計師、用戶體驗架構師）。負責深入理解目標用戶，設計有價值的、可用的功能，以及用戶導航和產品使用流程。與產品經理密切合作，將功能與設計相結合，滿足用戶需求，確保產品同時具有可用性和價值。

  可用性指用戶明白如何使用產品，價值指用戶對產品的渴求程度。

• 項目管理人員:負責在開發產品的過程中制訂計劃和跟蹤進度。

• 開發團隊：負責開發產品。

  IT團隊通常指的是為內部員工提供技術支持的團隊，而開發團隊指的是為外部客戶開發和維護產品的團隊。

• 運維團隊：保證服務器正常運行。

• 產品營銷人員：負責對外發布信息、宣傳產品，為拓展市場銷售渠道、組織重點營銷活動、促進產品銷售提供技術支持。

通常，每五到十位開發人員配備一位產品經理，一位交互設計師大約可以支持兩位產品經理的工作，一位視覺設計師可以支持四位交互設計師的工作。凡超過十名開發人員參與的重大項目，就應該配備專職的項目經理。

Ch2 · 產品管理與產品營銷

產品經理和市場營銷不是一回事。

產品公司常常會陷入一下三種誤區：

①由市場營銷人員定義產品。由營銷經理負責收集高層產品需求，然后直接交給開發團隊開發。

②兩人分擔定義產品的工作。營銷人員負責高層商業需求，產品經理負責底層產品需求。

③一人兼任兩項工作。營銷人員兼任產品經理的工作。

以上這些錯誤會為公司帶來很大損失。要解決這些問題，必須清晰界定產品經理和營銷人員的職責。但是，產品經理和營銷人員也應該多溝通、展開合作。

Ch3 · 產品管理與項目管理

產品管理的職責是探索（定義）有價值的、可用的、可行的產品；而項目管理則關注如何執行計劃以按期交付產品。

對互聯網公司而言，把這兩種職位分開至關重要。

作者總結的優秀項目經理的七個特點：

工作緊迫感、善于捕捉問題、思路清晰（分離問題、專注解決）、用數據說話、果斷、判斷力（何時做何事）、態度（一往無前、愈挫愈勇）。

Ch4 · 產品管理與產品設計

理解用戶體驗設計

與用戶體驗設計密切相關的分工：用戶研究、交互設計、視覺設計、原型制作。

Ch5 · 產品管理與軟件開發

定義正確的產品與正確地開發產品

Ch6 · 招聘產品經理

尋找出色的產品經理

個人素質和態度、對產品的熱情、用戶立場、智力、職業操守、正直、信心、態度、技能、運用技術的能力、注意力、時間管理、溝通技能、商業技能。

Ch7 · 管理產品經理

建設公司從建設團隊開始

管理產品經理的人通常被冠以產品總監或產品副總裁的頭銜。

建設產品管理團隊

規劃公司的產品戰略

Ch8 · 巴頓將軍的忠告

目標管理

永遠不要告訴別人怎么做，告訴他們做什么，他們自然會發揮天賦，給你驚喜。
           —— 喬治·史密斯·巴頓

產品經理收集需求時，常聽到客戶建議“如何做”產品，而不是產品應該“做什么”，畢竟思考問題的解決辦法是人類的本性。如果產品經理試著思考產品要做什么，就會驚訝地發現實現方法如此之多。

產品經理習慣于告訴用戶體驗設計師如何設計產品，卻忘了告訴他們產品要“做什么”。這是普遍存在于用戶體驗設計中的問題。

產品經理留給用戶體驗設計師和開發人員的空間應盡可能大。

Ch9 · 產品副經理

辦公室里最聰明的人

做產品要找公司最聰明的人合作。每個公司都有幾個聰明決定的人，這些人是公司的潛在資源，關鍵看我們能不能發現他們。如果有幸找到他們，就應該不拘一格地任用。我們可以把這些人看作產品副經理，甚至公開授予他們頭銜，把他們招進產品團隊。

產品經理應該接受別人來提出創意，因為更多的靈感是受別人啟發得到的。公司的目標是打造卓越的產品，所有可以借用的力量都是可取的。

Ch10 · 管理上司

十條經驗

由于管理層導致的項目波動問題是固有的，不可能完全消除，唯一能做的是緩解其影響。作者介紹了管理上司的十條經驗：

1. 為項目波動做好準備。
2. 注意溝通方式與頻率。
3. 會前溝通。
4. 多提建議，少談問題。
5. 向上司借力。
6. 充分準備。
7. 縮短郵件篇幅。
8. 多用數據和事實說話。
9. 內部宣傳。
10. 做讓領導省心的員工。

Part2 流程

Ch11 · 評估產品機會

確定待解決的問題

正常情況下，業務人員會撰寫一份論證產品可行性的市場需求文檔，描述待解決的問題。理論上，市場需求文檔只描述產品機會，不涉及具體解決方案。但是多數公司跳過了市場需求文檔，有些將市場需求文檔誤寫成產品規范文檔，有些則沒回答該回答的問題，還有些即便玩長了市場需求文檔，也將它束之高閣，不聞不問。

評估產品機會是產品經理的重要職責。評估產品機會的目的在于：淘汰餿主意，避免浪費時間和金錢；挑選合適的產品機會，團結團隊，理解產品，整合資源。

為了評估產品機會，作者希望產品經理回答如下十個問題：

1. 產品要解決什么問題？（產品價值） 較難回答。
2. 為誰解決這個問題？（目標市場）
3. 成功的機會有多大？（市場規模） 可求助于行業分析師、貿易協會、公司財務，再結合自己的分析作出判斷。評估務必謹慎，避免浮夸。
4. 怎樣判斷產品成功與否？（度量指標或收益指標）
5. 有哪些同類產品？（競爭格局）
6. 為什么我們最適合做這個產品？（競爭優勢）
7. 時機合適嗎？（市場時機）
8. 如何把產品推向市場？（營銷組合策略） 描述具體銷售方式，甚至會影響具體需求。
9. 成功的必要條件是什么？（解決方案要滿足的條件） 調研過程中發現的特殊需求，搞清楚產品的依賴因素和約束條件。比如：如果要通過系統集成商來銷售產品，對方可能會對產品的擴展性、合作方式提出要求。
10. 根據以上問題，給出評估結論。（繼續或放棄）

以上問題并不涉及具體的解決方案。機會評估只討論待解決的問題，不應涉及具體的解決方案。產品經理往往把待解決的問題和解決方案放在一起考慮，當具體解決方案遇到困難時，他們會放棄產品機會。這是典型的“把洗澡水和孩子一起潑掉”的做法。

開發新產品還是維護舊產品？

關鍵在于比較兩者的機會。產品團隊一視同仁地評估兩者的收益與成本，然后由管理團隊作出決策。此時，機會主義并不是不可取的。

很多時候，好機會就在眼皮底下，完善不盡如人意的產品特性往往事半功倍。

舉例來說，100位打算注冊使用產品的用戶最后只有9人順利完成注冊，如果設法把人數提高到18，就能讓產品的收益翻倍。這種改進往往很容易實現，只要做一些原型測試和用戶測試，很快就能找出存在的問題， 想出解決方案。

再舉一個例子，產品公司往往雇用上百人的客服團隊為用戶提供售后服務，如果能提高產品的易用性，將大幅減少客服人員的數量，降低成本，同時提高用戶滿意度和用戶凈推薦值。

這也是糟糕的產品設計和蹩腳的用戶體驗導致的結果。原有產品質量差，公司不愿意想辦法改進，反而認為開發新產品更容易，導致原有產品無法發揮潛力、產生應有的利潤。除非這些公司改變研發產品的方式，否則，新產品難免重蹈覆轍。

結交一位懂財務的朋友（財務部門的同事）能讓產品經理受益匪淺。他們能：

幫助我們了解產品，評估產品，看看公司的投入是否劃算，他們對產品的預測如何。

幫助我們了解用戶，財務部門掌握著交易記錄、支付信息、客戶數據和經營報表。獲取到我們有權獲取的信息，并利用好它們。

幫助我們確認我們的新想法在商業上的可行性。我們提供信息，他們幫我們分析整合。當我們與高管討論產品的可行性時，能得到財務部門的支持真是再妙不過了。

Ch12 · 產品探索

定義正確的產品

軟件項目可以劃分為兩個階段：弄清楚要開發什么產品（定義正確的產品）；開發該產品（正確地開發產品）。第一個階段探索產品，第二個階段則強調執行。產品經理必須在執行階段轉換工作重心，否則，產品經理自己很有可能成為產品上市的最大障礙。

作者建議的解決沖突的辦法：采用流水線方式秉性開發產品。一旦1.0版本的產品進入項目執行階段，就開始定義2.0版本的產品。一旦前一個版本進入開發階段，就把創造熱情投入下一個版本。但是，不要讓這種做法干擾正在執行的項目。

Ch13 · 產品原則

確定什么最重要

產品原則是對團隊信仰和價值觀的總結，用來指導產品團隊作出正確的決策和取舍。它體現了產品團隊的目標和愿景，是產品戰略的重要組成部分。從形式上看，它是一系列明確的、體現團隊特色的產品價值準則。

制定產品原則意味著決定什么重要、什么不重要，哪些原則是根本的、戰略性的，哪些是臨時的、戰術性的。

產品原則是否公開因公司而異，它還可以用來團結產品團隊，讓產品、開發、營銷團隊形成共同的價值觀，在認識上保持一致性。

僅僅羅列出產品原則還不夠，還要按照原則的重要性排序，總有要優先考慮的原則。

產品原則在制定時容易出現兩類錯誤：①過于空泛，失去了指導作用。②把設計原則誤當成產品原則（如：為用戶提供清晰的導航路徑（方便用戶完成下一步操作）屬于常見的設計原則，不是產品原則）。

如果我們所在的團隊還沒有制定清晰的、有關產品理念的產品原則，應該把大家召集起來，花點時間討論分析，確定團隊最看重的價值理念。

解決意見沖突

制定產品決策的過程中存在的困難著實不少，這些困難是不可避免的，因為建設性的辯論和論證是定義優秀產品的必經之路。不過即使意識到這點，與會者也很難把爭論當成一種享受。

為了鼓勵創新，改善討論效果，同時降低外界干擾，在作產品決策之前，應該先確定決策要解決什么問題，讓大家在以下幾個要點上達成共識：

1. 究竟要解決什么問題？
2. 要為哪類人物角色解決這個問題？
3. 產品要達到什么目標？
4. 每項目標的優先級是什么？

事實上，每當團隊內出現嚴重的意見分歧時，并非是大家對事實的認定有爭議，而是對目標和目標的優先級有不同的理解。

比如說，團隊首先應該確定哪個目標對用戶最重要，是易用性、響應速度、功能、成本、安全性、還是用戶隱私？只有先統一對產品目標優先級的認識，大家才能在此共識上進一步討論各種方案的合理性與可行性。

務必認真分析產品目標的優先級（從最重要到最不重要逐項排序），讓團隊達成共識。切不可囫圇把所有目標都貼上“關鍵”“重要”的標簽。

制定決策的過程和依據必須完全透明，不能讓人覺得我們只憑直覺判斷。務必告訴大家決策的依據和理由，清楚展示每一個決策環節。

激烈的會議爭論會影響大伙的斗志和工作效率。如果再出現這種情況，需要先回顧產品目標和目標優先級，確保大家達成共識。

Ch14 · 產品評審團

Ch15 · 特約用戶

產品開發伙伴

為了解決——既深入洞察目標用戶的需求，又贏得用戶對產品的推薦的問題，建議征集特約用戶（也叫用戶顧問委員會、用戶評審團）協助完成產品研發。

方法為，在項目開始階段物色至少六位積極、活躍、樂于分享的目標用戶，要求是他們在產品的目標用戶中具有一定的影響力。至于他們是否使用過公司原有的產品并不重要，只要他們認為未來的產品可以解決他們手頭亟待解決的問題就行。

成為特約用戶的好處

1. 參與構思產品創意，解決他們手頭的問題——他們最清楚產品要解決的問題，因為這些麻煩正在困擾他們。
2. 提前試用產品，越早使用產品意味著越早解決麻煩。
3. 通常，提前試用產品還可以顯著降低用戶的各種成本。

產品經理的收獲

1. 聚攏一批積極的用戶，他們可以為定義產品和開發產品提供建議和協助。
2. 提供調研便利，便于產品經理去特約用戶的工作場所調研。如果是平臺產品的話，便于產品經理去開發人員的工作地點調研。
3. 可以定期組織特約用戶進行小組討論。
4. 特約用戶第一時間試用、測試產品，迅速反饋意見。
5. 如果特約用戶滿意產品的表現，會樂意公開推薦產品。

組織特約用戶的注意事項

1. 不要向特約用戶收取參與費用，否則合作關系會變味。產品經理需要的是開發產品的伙伴，不要變成為特約用戶開發產品。如果用戶愿意，我們可以等正式產品發布后再向他們收取費用。
2. 由于可以免費試用，通常有大量申請者申請成為特約用戶。但眾多的特約用戶會消耗產品經理大量精力，而且這些用戶不一定符合要求。特約用戶人數絕不能超過十個。
3. 如果在尋找特約用戶時遇到苦難，很可能是因為產品解決的問題不像產品經理想象的那么重要，將來也很難銷售出去。這可以初步驗證產品創意是否有價值。出現這種情況，產品經理應該重新考慮產品計劃。
4. 產品經理需要確保特約用戶是產品的潛在目用戶。我們很容易把產品嘗鮮者誤當成特約用戶，他們常常能容忍產品的不足和缺陷，
5. 產品經理務必向特約用戶說明，我們要開發的是面向大眾的通用產品，不是為某家公司開發的定制產品。特約用戶也不希望出現這種情況，因為一旦產品被淘汰，售后服務也將被取消。
6. 產品經理應該把特約用戶當成開發伙伴對待，視他們為同事，互相幫助。
7. 產品經理與特約用戶的合作貫穿產品研發的每個環節：向他們展示產品原型，請他們參加測試，向他們請教產品的細節問題，讓他們幫你部署、測試待發布產品的備選版本。
8. 正式產品發布之前，一定要先請特約用戶試用，確保每個人都滿意，一旦發布，他們會堅定不移地向大眾推薦產品。
9. 產品經理還要和產品營銷團隊緊密合作。一方面，營銷團隊可以幫助我們物色特約用戶；另一方面，他們可以協助我們提高特約用戶受關注的程度。
10. 如果是平臺產品，特約用戶的作用就更突出了，只不過六個特約用戶要換成六個應用。產品經理要與特約應用的開發者緊密合作，確保在平臺上構建的應用讓用戶感到滿意，最好鼓勵應用開發者發展自己的特約用戶。

以上例子雖然多數是企業軟件和平臺產品，但同樣也適用于針對針對大眾的互聯網服務和消費類產品。如果是互聯網服務，特約用戶的人數應該增加至10-15人，不過要保證產品經理有精力充分了解每位特約用戶，以及他們使用服務的環境（家或辦公室）。

從營銷的角度來看，大眾消費者對口碑營銷的反應可能與企業采購經理的不同。大眾消費者更容易接受媒體和網站評論的影響，但是他們也希望看到真實用戶的評價。在這一點上兩者是相同的。

使用特約用戶是確保產品不偏離用戶需求最簡單有效的辦法，同時也是向潛在用戶宣傳、推薦產品的最佳手段。

Ch16 · 市場調研

理解市場調研的作用與局限性

市場調研的作用

常用的市場調研工具和方法：用戶調查、產品使用分析、數據挖掘、拜訪用戶、人物角色、可用性測試、同類產品分析。

市場調研的局限性

市場調研結果可以作為研發產品的依據和參考，但不能決定產品研發的方向，即，不能直接回答最根本的產品問題：打造什么產品？

探索（定義）產品的過程則要回答如下問題：

1. 采用什么技術來更好地解決產品要解決的問題？
2. 設計什么樣的用戶體驗？

Ch17 · 產品人物角色

理解目標用戶

創建人物角色。

Ch18 · 重新定義產品說明文檔

安息吧，紙質說明文檔

理想的產品說明文檔應該滿足以下要求：

1. 完整地描述用戶體驗——不只是用戶需求，還包括交互設計和視覺設計。
2. 必須準確地描述軟件的行為。文字和圖片的表達能力實在有限，不足以完成這項任務。
3. 必須以某種直觀的方式把產品信息和產品行為告訴所有人（產品說明文檔的受眾較廣——開發人員、測試人員、客服人員、市場營銷人員、運維人員、銷售人員、管理層等等）。
4. 應該可以修改。雖然進入開發階段后，應該盡量避免修改產品說明文檔，但總有意想不到的問題出現，需要修改產品說明文檔以適應新情況。
5. 撰寫產品說明文檔的過程中會出現許多衍生物，比如，按優先級排列的需求列表、線框圖、實體模型，但應該有一個主體來代表產品，避免混淆不清，版本錯亂。

作者認為，只有一種形式的產品說明文檔可以滿足以上所有要求——高保真產品原型。

僅有原型是不夠的，因為有些產品行為不容易用原型體現，比如業務邏輯（稅務表單和運費等）、發布要求（性能表現、可靠性、擴展性等）、平臺交交付要求（安裝要求、瀏覽器兼容性等）。用例可以作為有效的補充，用來描述重要的產品行為。

最理想的展示補充說明文檔的方法是在原型上增加注釋，如果無法做到，可以使用內部網站，團隊成員可以隨時讀到最新信息，不用浪費時間查找版本混亂的紙質文檔。網站可以定期通知大家產品說明文檔的更新情況，方便大家提問和討論，并保存所有決策記錄。

但是，產品說明文檔的主體應該是高保真原型，由他來體現產品的功能需求、信息架構、用戶體驗、交互設計、視覺設計。另外，它最突出的優勢是可以用于測試。

只有通過真實用戶的可用性和價值測試，產品說明文檔才算合格，產品才值得開發。

為了驗證各種設計思路，產品原型應該可以隨意修改，完成其任務后應該被丟棄。而開發中的產品應該以固定的原型為基礎。

Ch19 · 用戶體驗設計與實現

先定義用戶體驗再動手開發

盡管作者提倡需求調研和產品設計都要在軟件開發前完成，但是在此期間至少應該邀請一位軟件開發人員檢查設計工作，他可以幫助我們評估設計的可行性和成本，作出更明智的決策。

Ch20 · 基本產品

削減功能還是延長工期？

建議團隊放棄老式的產品設計方式。比如，不再視圖定義最終產品，轉而定義只滿足基本要求（價值、可用性、可行性）的產品，簡稱基本產品。一旦基本產品定義完成，通過了用戶測試，他就是一個不可分割的整體，去掉任何元素，都不可能獲得預期的效果。

作者建議采用的產品設計方式：

1. 產品經理與設計師合作設計產品的高保真原型，這個原型只具備實現商業目標的最基本功能要求，以及良好的用戶體驗和吸引力。只設計基本功能的產品可以把復雜度降到最低，把開發時間減到最少，因而是非常重要的。
2. 邀請一位開發人員（架構師或主程序員）參與設計原型。請他檢查原型，幫助產品經理和設計師估算各種功能的直接成本和間接成本，指出設計上的誤區，并分析、評估尚不確定是否可行的功能。等產品原型確定時，他詳細估算所有產品功能能點時間成本。
3. 請真實的用戶驗證（測試）產品原型，這一點至關重要。在產品團隊全力開發產品前，產品經理和設計師必須確信產品是用戶需要的。

一旦基本產品確定，通過了目標用戶的測試，就不可能再削減任何功能。如果還能削減，那說明我們定義的不是基本產品。

設計產品一定要考慮哪些功能是最重要的，爭取設計出只滿足基本要求的、不可刪減的產品。

Ch21 · 產品驗證

證明產品的價值、可用性、可行性

產品驗證是指在正式開發、部署產品前，驗證產品說明文檔描述的產品是否符合預期要求。

產品團隊對自己的產品往往過于自信，不愿意驗證產品，只顧埋頭開發，總想等到公開測試時再收集反饋意見。毫無疑問，到那時再想大幅修改產品是不可能了，因此許多產品剛發布時表現得非常糟糕，這也不足為奇。

產品經理向產品團隊提供最終的產品說明文檔前，需要進行以下三項重要的驗證。

可行性測試

首先要明確在現有的技術條件下，能否成功開發出產品。

可用性測試

交互設計師應該與產品經理密切合作，想方設法突出產品的功能特性，讓不同類型的用戶都能明白如何使用。

可用性測試往往能發現沒能成功實現的產品需求，如果測試得當的話，甚至能發現原本被忽略的產品需求。最好規劃多次迭代測試，確保實現最佳的用戶體驗效果。

一定要請真實的用戶來試用可用性原型，從目標用戶那里可以得到寶貴的反饋信息。

為了測試可用性，即使要模擬復雜的后臺處理過程也是值得的，關鍵是要評估用戶體驗的實際效果。

價值測試

僅僅知道產品能夠開發出來、方便使用，這還不夠。還要知道用戶是否覺得我們的產品有用，是否愿意購買，有多喜歡產品的設計。

價值測試可以和可用性測試同時進行，使用的原型也是一樣的。只不過可用性測試重在觀察用戶如何設法完成必要的操作，而價值測試重在觀察用戶是否喜歡這些功能，是否滿意功能的具體實現方式。

使用原型并非驗證產品（尤其是互聯網服務）的唯一方式，還有其他簡單有效的方法，但它們都在強調正式開發軟件前驗證產品設計，因為設計總有考慮不周、出人意料的情況。越早發現問題越好，一旦進入開發階段，修改產品設計的難度和成本會越來越高。

Ch22 · 原型測試

把產品創意呈現給真實用戶

使用產品原型的最主要原因是產品原型可以讓用戶驗證產品的創意，加深產品經理對產品的理解，避免開發團隊浪費時間和精力開發沒有把握的產品。

讓真實用戶驗證產品創意是必不可少的環節，這是產品經理最重要的工作。

物色測試者

開始原型測試前，要尋找測試者。如果把測試外包給專業團隊，他們會為我們挑選用戶、約定測試時間，節省我們的時間。如果我們自己尋找測試者，作者給出如下幾條建議。

1. 如果我們已經擁有一批特約用戶，可以邀請他們參加測試。否則，需要馬上開始物色。
2. 如果是企業及產品，同類產品的產銷會是尋找目標用戶的好去處。
3. 可以在分類信息網站上發布廣告，征集測試者。征集要求可以寫得籠統些，不必過于具體。時候打電話給我們感興趣的應征者，了解對方的意向，進一步篩選合適的測試者。
4. 如果是大眾產品，可以邀請自己的親朋好友參加測試，但要避開過去親密的人和科技行業的從業者，除非他們就是目標用戶。另外，測試者不能只局限于親友。
5. 如果手頭有用戶的電子郵件列表，可以從中篩選測試者。營銷團隊可以幫我們縮小名單范圍。
6. 可以通過公司的網站征集志愿者，主流的網站都這樣做。但還需打電話聯系并篩選應征者，避免參加測試的全是產品嘗鮮者。
7. 建議較大的公司定期開展原型測試活動，每次邀請10-20位測試者參加。讓所有產品經理自己申請時段，安排每位測試者參加測試1-2個原型。這樣可以避免產品經理為尋找測試者分心。
8. 到街頭巷尾、用戶聚集的地方，讓他們花個把小時測試產品。可以送些禮物表示謝意，注意放低身段。
9. 如果邀請測試者上門參加測試，尤其是出于商業目的，應該補償測試者為此損失的時間。如果是大眾網絡服務產品，通常送上公司相關周邊就夠了。
10. 在測試前一天致電測試者，最大程度避免測試者爽約。

準備測試

測試環境

測試原型

更新原型

Ch23 · 改進現有產品

不是一味地添加功能

改進產品不是簡單地滿足個別用戶的要求，也不能對用戶調查的結果照單全收。能提高指標的功能才是我們關注的重點。我們應該找準方向，分析關鍵指標，有針對性地改進產品。

Ch24 · 平滑部署

避免更新產品導致用戶反感

作者把合理地、審慎地更新產品版本的行為成為“平滑部署”。

為了將版本更新帶來的負面影響降到最低，可以采取以下幾種措施：

1. 加倍做好測試工作，避免新版本存在影響正常使用的隱患。比如可靠性、擴展性、性能問題。確保將來不會陷入被迫返回舊版本的窘境，為用戶增加不必要的麻煩。
2. 如果更新版本會影響大規模的用戶，應該采取并行部署或者增量部署的方式來降低風險。

平滑部署的方式有很多，比如為舊版本提供支持期限，過渡發布。另一種方式是區域性逐步部署（在某個區域內部署新版本，然后逐步擴大范圍），還有一種方式是增量部署（將更新項分割成幾個較小的部分逐步發布）。

無論采用哪種處理方式，關鍵要全面考慮更新可能帶來的“副作用”，為用戶提供便利，方便他們在空閑時適應變化，同時盡可能降低新版本帶來的負面影響。

優秀的產品和服務可以贏得用戶的好感，這是寶貴的信任，應該小心保護。不要輕易試探用戶的耐心，讓好感變成反感。

Ch25 · 快速響應階段

產品出爐后切莫虎頭蛇尾

發布產品不等于大獲全勝，交互產品后依然要保持高度警惕。

產品發布后，正是收集反饋信息、改進產品的最佳時機。急于“撤軍”是項目管理和產品開發流程中的大忌，只要稍微延長項目周期，觀察用戶對產品的反應，效果就會有天壤之別。這樣做投資小，匯報稿，絕非其他項目階段可比。

產品發布后的幾天至一周內，所有項目成員應該留出時間作為快速響應階段。這個階段的主要工作是快速響應、處理產品發布后的用戶反饋意見。

評估產品表現應該使用明確的、可量化的指標。我們最關心產品哪方面的表現，是頁面訪問量、注冊用戶數、訪問停留時間、會員轉換率、訂閱數、還是廣告收益？具體使用哪些指標取決于產品的商業目標。應該給指標分出輕重緩急，并保持關注。此外，對于什么樣的結果代表產品成功，什么樣的結果代表失敗，應該做到心中有數。

一旦問題反饋回來，產品團隊應該至少每天召開一次短會，討論問題的輕重緩急，確定最佳解決方案。

在快速響應階段，客戶服務人員、銷售人員和合作伙伴的意見也不容忽視。

Ch26 · 合理運用敏捷方法

十大秘訣

盡管敏捷方法有許多優點，但這類方法源自定制軟件領域，不完全適用于開發產品軟件。

在這里將介紹適用于產品軟件團隊，而不適用于定制軟件團隊的敏捷方法。

1. 產品經理即是產品負責人，他代表了客戶的需求，因而需要與產品開發團隊保持密切的聯系，協助督促開發進程，及時解決出現的問題。（如果產品經理和產品負責人不是由一個人擔任，通常會埋下隱患。
2. 使用敏捷方法絕不等于省略產品規劃。產品經理仍然要明白產品的方向和目標，設定衡量產品成功與否的標準。只不過在敏捷環境里，規劃周期應該適度縮短，反復迭代，采用輕量級的機會評估方法替代冗長的市場需求文檔。
3. 產品經理和設計師的工作進度應該比開發團隊領先一兩個迭代周期，確保我們有足夠的時間攻克難題。讓交互設計師和視覺設計師提前設計產品，充分發揮他們主導設計的作用，不能一邊設計一邊開發。另外，始終讓開發人員參與評估產品設計和產品原型，及時反饋關于可行性、成本、解決方案的建議。
4. 盡量把產品設計工作拆分成店里的部分，分而治之，但也不能拆得太細——好比設計建筑不能一次只設計一個房間。目標是設計出符合基本要求的產品。值得注意的是，在敏捷環境里，設計師必須加快工作進度，采用迅速制作原型的方法更能適應敏捷壞境。
5. 產品經理的主要任務是定義有價值、可用的產品原型和用戶故事，作為開發的基礎。用產品原型和用戶故事替代厚厚的產品需求文檔和功能說明文檔有三個優勢：①可以請用戶測試；②強迫產品經理全面認真地思考問題；③向開發團隊明確地描述每次迭代周期需要完成的任務。請用戶測試原型，根據反饋意見反復迭代修改原型設計，確保交給開發團隊的是有價值的結果，避免任何浪費，哪怕只是一個迭代周期。
6. 讓開發人員自主劃分迭代周期。有的功能可以在一個周期完成，有的卻需要要幾次迭代才能完成。
7. 產品經理和交互設計師必須出席每天的晨會。晨會是一天溝通過程的開始，而不是結束，關于產品的討論會持續一整天。設計師向開發人員和測試人員展示產品功能；開發人員互相展示完成的代碼，讓測試人員測試，請設計師和產品經理過目；測試人員和開發人員在制作原型的階段識別潛在的問題，協助產品經理制定更合理的決策，解決產品設計、開發的問題。
8. 除非達到了產品經理的要求，否則不要輕易發布新版本。產品經理必須確保交給用戶的版本能正常運行。過度頻繁更新版本會讓用戶感到不安。
9. 在每次迭代完成后，產品經理應該向團隊展示產品現狀，以及下次迭代的產品原型，讓大家看到工作成果，同時加深大家對產品的理解，增強團隊對這種開發方式的信心。
10. 在團隊內展開敏捷培訓。（可以聘請顧問，但要確保他理解產品軟件與定制軟件的差別。只有每位團隊成員都真正理解敏捷方法，我們才能把工作重心放在執行上，否則敏捷方法就只能停留在理論層面。

迭代初期開發的產品不能用做原型。原因如下：

1. 用一個迭代周期來驗證產品創意太長，不如用幾天時間驗證可更改的產品原型。
2. 在探索（定義）產品的階段，開發團隊還有許多重要工作要完成。這時占用他們的時間開發產品原型，會消耗他們開發正式產品的精力。
3. 一旦進入開發階段，設計出軟件架構后，再想改變產品設計思路，對開發團隊來說，無論是成本還是難度都太高了。 

Ch27 · 合理運用瀑布式開發方法

瀑布式開發方法過于理想化，以為人們能預見所有問題，全面把握需求。實踐證明除非是規模很小的項目，否則瀑布式開發方法很難順利執行。

Ch28 · 創業型公司的產品管理

關鍵在于產品探索

Ch29 · 大公司如何創新

有困難，但值得一試

20%法則

谷歌的程序員有20%的工作時間可以用來嘗試創新研究。

20%法則鼓勵普通員工自己嘗試各種想法，發揮大家的主觀能動性。

臭鼬工程

指在受限制的條件下，利用自己的時間，低調地進行創新研究。但創新研究的成果歸屬通常要看公司政策。

主動觀察

觀察和傾聽是最簡單的創新途徑。仔細觀察使用公司產品或同類產品的用戶，想辦法更好地滿足他們的需求，再找一位熟悉技術的開發人員合作，我們就可以著手改進產品了。

注意，應該選擇實際用戶作為觀察對象，不要選擇產品嘗鮮者，更不能選擇公司同事。

創新不是發現新問題，而是用新方法解決已有的問題。觀察人們對現有產品的不滿，是創新的最佳途徑。

改善用戶體驗

另一種創新途徑是跳出技術局限，完善用戶體驗。改善用戶體驗不僅要提高產品的工作效率，更要剔除多余的功能，明白哪些功能是用戶必須的，哪些是設計和開發帶來的衍生物。

每款產品都有特定的實現模型，但用戶腦子里裝的是概念模型，他們對產品要解決的問題，以及如何解決問題有自己的想法。如果實現模型與用戶的概念模型不一致，用戶就會感到失望。找到用戶失望的地方，就找到了創新，或至少是改善產品的機會。

收購小公司

建議大公司的產品經理多和業內活躍的創業型公司建立聯系，互相幫助，互相學習。這種人脈關系也許能替公司節省上百萬資金。

妥善安排收購來的新員工，讓他們繼續發揮特長，才能拓展產品線，保持市場領先地位。

Ch30 · 在大公司施展拳腳

十大秘訣

只要懂得利用資源，在大公司工作有明顯的優勢。

首先，大公司都遵循一條潛規則——盡量規避風險。其次，多數大公司都采取矩陣式的管理方式，核心部門（比如設計、開發、測試、運維、市場部門等）是共享資源，產品經理要確保爭取到足夠的資源才能研發出產品。

理解這兩點后，提出幾點在大公司施展拳腳的方法：

1. 了解公司制定決策的方式。 每家公司企業文化不同，制定決策的方式也不同，要學會融入其中。知道決策權在誰手里，我們的工作目標就很明確了。了解他制定決策的方式，他更看重原型演示、市場數據，還是客戶的承諾和評價。如果我們需要公司的支持，只需要說服他就行了。
2. 建立人脈網絡。在大公司必須與人合作，我們需要同事的協助才能完成設計、開發、發布工作。主動與各個部門的同事結交朋友，聊聊工作的事，向大家介紹我們手頭的項目，不要等到有事才去找人家。主動幫助他人，積累人脈關系。
3. 臭鼬工程。找三五個志趣相投的同事在工作之余做出產品原型來。產品原型具有超出想象的說服效果。比起枯燥的陳述，生動形象的演示更有吸引力。數不清的優秀產品是這樣誕生的。
4. 自己頂上。大公司雖然員工眾多，但真正需要幫手的時候卻總找不到人。即便是公司高管重視的項目，也難免資源不齊。遇到這種情況，我們就得自己想辦法了。實在不行，就得自己頂上。一切為了推出產品，不要計較個人得失。
5. 有選擇地據理力爭。在大公司工作，多一敵不如多一友。如果我們不滿意同事的工作，或與他人意見不同，不要隨便發脾氣，除非這件事對我們確實重要，值得我們據理力爭，撕破臉也在所不惜。與人辯論要小心措辭，不要把人逼到死角。我們的目標是完成產品，別為了一場戰役輸掉整場戰爭。
6. 會前溝通，形成默契。如果有人在重要的決策會議上，公開反對我們的提議，我們會變得非常被動。設法在會前達成一致意見。會議的主要作用是讓與會者認識到大家取得了一致意見，所以會前應該逐一找與會者聊聊，了解每個人的立場。如果有不同意見，對癥下藥及時化解，確保他們會投贊成票。
7. 合理分配時間。大公司頻繁開會，有些人忙得不可開交，產品卻毫無起色。產品經理應該重新檢查會議日程，劃掉無關緊要的會議，學會充分信任同事，讓他們自己拿主意，產品經理應該留時間完成自己的本職工作：制定產品戰略，構思產品路線圖，研究產品原型，分析競爭對手。
8. 分享信息。有舍才有得，分享信息會讓我們獲得更多的朋友和資源，作為交換，別人也會毫無保留地分享信息給我們。充分共享信息對我們自己和公司都有好處，這叫共贏。
9. 向上司借力。學會利用上司的關系，可以更好地開展工作。利用他的人脈關系，傳播我們的理念。多向他請教，了解公司文化和組織結構。如果需要上司出面說服公司高管，我們一定要事前做好充分的準備，為他提供翔實可靠的資料和信息，用實力取得他的信任，讓他放心地當我們的說客。
10. 傳播我們的產品理念。 多向同事傳播我們的產品理念，向大家描繪產品愿景，介紹產品策略，演示產品原型，分享用戶反饋信息。不要低估了內部宣傳潛移默化的作用。讓大家（包括沒有直接業務聯系的部門同事）不遺余力地支持我們。

不可否認，在大公司里工作得克服重重障礙，為產品爭取支持和資源實屬不易，但大公司也有大公司的優點，產品會獲得媒體和用戶的高度關注，這是小公司望塵莫及的。一旦我們掌握了充分利用大公司資源的方法，將會如魚得水。

Part3 產品

Ch31 · 蘋果公司給我的啟示

另類的硬件公司

作者認為在蘋果公司值得學習的經驗中，以下四點最重要：

1. 硬件為軟件服務。軟件直接服務用戶，滿足用戶需求。采用多點觸控顯示屏、重力加速器、距離傳感器這些硬件技術是為了配合軟件滿足用戶需求，而不是花哨的噱頭。僅憑華麗的硬件技術和軟件效果無法真正吸引用戶，一旦消費者過了嘗鮮的階段，就會對產品失去興趣。
2. 軟件為用戶體驗服務。蘋果公司的所有工作都圍繞著產品可用性、交互設計、視覺設計、工業設計展開。公司各個部門不遺余力地支持用戶體驗設計，蘋果公司明白用戶體驗是產品立足之本。
3. 用戶體驗為情感服務。蘋果公司比誰都清楚是什么讓消費者為產品瘋狂，他們知道怎樣抓住用戶的情感需求。人人都想擁有一臺iphone，對比其他的手機和品牌電腦，前者像是寶馬，后者像是租來的二手車。
4. 產品為真正的需求服務。手機并非蘋果公司首創，但他們挖掘出了尚未被滿足的用戶需求。市面上的手機品種成百上千，十幾年不變的語音郵件系統，不兼容的地址簿，蹩腳的網頁瀏覽器和電子郵箱，只會讓用戶抓狂。蘋果公司逐一完善這些功能，成功的產品應運而生。

Ch32 · 提防有特殊要求的產品

避免陷入困境

如：銷售代表向CEO轉達客戶的提議，要求產品增加七項功能，否則拒絕購買產品。

這種特例產品到底有什么問題呢？它混淆了客戶需求和產品需求，必然會使公司偏離正軌。

產品需求不能用戶說了算。原因為：①在看到具體的產品之前，用戶很難知道自己需要什么；②用戶不知道什么樣的產品是可行的（在目前的技術條件下可以實現）；③用戶之間缺少溝通，需求很難統一。

即便不存在以上問題，產品經理也不宜把工作重心放在特例產品上。耗費精力添加特殊功能，必然會耽誤更重要的工作，帶來的長遠損失并非這點蠅頭小利所能填補。

退一步講，即使以上問題都可以解決，特麗產品的風險仍然不能忽視。因為產品經理的任務是滿足大眾的需求——這是產品公司和定制軟件公司的區別。如果一年后市場需求發生變化，產品必須快速應對。簽訂合約后，產品就被合同綁住了，難以應變，最后會讓公司不堪重負。

但并非貶低定制軟件公司，只因商業產品軟件和定制軟件完全是兩碼事。

為回避特例產品可能帶來的危害，公司應該根據企業文化樹立自己的產品原則，關鍵時刻根據產品原則決定是否接受客戶提出的特殊要求。

無論是企業軟件還是網絡服務，產品經理都確保開發出來的產品是有價值的，盡可能滿足更多用戶的需求。

Ch33 · 新瓶裝老酒

新技術層出不窮

成功的產品往往不是什么新鮮事物，只是新瓶裝老酒，之所以成功，是因為這個“新瓶”做得更好、更方便、更便宜，改變了消費者對“老酒”的印象。

如：谷歌在搜索引擎市場幾近飽和的情況下入駐搜索領域。蘋果在市場上有上百種MP3播放器的情況下，用iPod引領市場潮流。

想要在成熟的市場搶占一席之地，精明的公司至少要有兩件法寶：

1. 對目標市場了如指掌，對鮮有產品的缺陷洞若觀火。可以通過產品可用性測試掌握產品情況（包括自己的產品和競爭對手的產品）。
2. 跟蹤最新的技術趨勢。新技術層出不窮，讓之前無法實現的方案變得可能。雖然誰都沒有把握永遠走在技術的前列，把最新的技術融入產品設計中，但是只要做到一次，我們的產品將所向披靡。

優秀的產品經理應該抓住現有技術與用戶需求的契合點。市場機遇無處不在，我們需要做的就是挖掘需求，運用新技術解決用戶的老問題。

Ch34 · 恐懼、貪婪、欲望

產品中情感的作用

消費者購買產品大多源于情感需求。企業級消費者出于恐懼和貪婪購買產品：如果不買，競爭對手會超過我，黑客會攻破我的防火墻、客戶將棄我而去；如果買了，我會賺得更多、省得更多。

大眾消費者購買產品的原因更多樣化：使用這款產品，就有機會交到朋友（化解孤獨），或者找到約會對象（滿足愛的需求），或者大掙一筆，或者展示我的照片和音樂（滿足自豪感）。

只有從情感的角度重新觀察市場上的產品和服務，我們才能體會用戶真實的感受。同一產品，不同類型的用戶還有這不同的情感需求。

每次開展原型測試，除了觀察測試者是否能順利使用產品外，還應該趁機了解測試者的情感需求（是什么驅動他使用產品），怎樣才能更好地滿足他的情感需求。

明確目標用戶情感需求后，問問自己誰還能滿足用戶的這種需求，他們才是我們真正的競爭對手。許多情況下，我們的競爭對手不是創業型公司或大型門戶網站，而是大眾的線下生活方式。

Ch35 · 情感接納曲線

技術接納曲線模型從技術角度描述了消費者對待產品的態度，但是它還不足以解釋消費者的行為。所以，可以用情感接納曲線模型對它的分類法進行補充。

根據消費者的情感特征，可以把他們分為：

• 技術愛好者（即技術創新者）：他們購買產品，僅僅因為產品采用了新技術。這類消費者容易誤導產品經理，因為他們的需求與普通大眾的不同。他們對技術本身很癡迷。
• 非理性消費者（即嘗鮮者）：他們的情感需求與大眾的相同，但是更強烈。憤怒、恐懼、孤獨這類消極情緒被放大后，會導致非理性的消費行為。在生活中，非理性消費者為了滿足情感需求，會付出大大超出解決問題本身所需要的精力和成本。
• 普通大眾：具有和非理性消費者同樣的情感需求，只是在程度上沒有那么強烈。隨著產品的完善，他們也會逐步加入消費隊伍。
• 理性消費者（即早期消費大眾）：只會購買他們認為實用、成熟的產品。他們更務實，只會購買性價比合適的產品。
• 超理性消費者（即后期消費大眾）：他們的情感需求更弱，哪怕產品有半點不合意，他們都不會掏錢。
• 觀望者（即跟隨者）：約占總人數的15%，他們同樣有需求，但只會購買公認好用的產品。

在這幾類人中，非理性消費者最值得產品經理注意，技術愛好者是最沒有參考價值的人群。

非理性消費是對不滿情緒的過度反應，是放大后的情感需求在“作祟”。非理性消費者夸大了產品的價值，產品經理如果深入了解他們的想法和感受，就能抓住這種情感需求。

非理性消費者能幫助產品經理發現產品的內在價值。他們內心彌漫著強烈的不滿情緒，這種情緒可能會慢慢減弱，但不會小時。技術愛好者并不關心產品要解決的問題，吸引他們的是產品采用的新技術。

Ch36 · 可用性與美感

兩者缺一不可

交互設計師與視覺設計師缺一不可，良好的用戶體驗是兩者合作的結果。他們共同配合產品經理定義產品。

Ch37 · 大眾網絡服務與產品

十大要點

作者總結了十條管理大眾網絡服務產品的要點，這些經驗適用范圍包括電子商務、社交網絡、搜索引擎、網絡游戲。

1. 可用性。大眾網絡服務產品必須具備良好的用戶體驗。如果用戶不清楚怎樣使用產品，或者產品性能很差（產品性能是最重要的一條可用性指標），頁面加載緩慢到讓用戶無法接受，公司都無法成功盈利。
2. 人物角色。
3. 擴展性。激增的用戶數量會帶來莫名其妙的問題。實現擴展性需要產品經理、設計人員、開發人員、運維人員的通力協作。最好利用部分開發資源和運維資源專門為系統擴展做好準備，留有余地，不到萬不得已不要滿負載運行。
4. 持續可用性。大眾網絡服務要求一刻也不能停歇。系統終止服務是件痛苦的事，但是系統出故障的時間卻不確定。在系統設計上保證持續可用性與規劃擴展性一樣重要。
5. 客戶服務。傳統的客戶服務無法應對數量龐大的網絡用戶，收費的網絡服務情況更嚴重。要想降低客服壓力，除了盡量減少系統故障和缺陷外別無他法。
6. 保護用戶隱私。應盡早樹立保護用戶隱私的意識，設置用戶資料保護機制，千萬不能辜負用戶對我們的信任。
7. 口碑營銷。如果用戶喜歡產品，就會主動向家人、朋友、同事推薦。這是宣傳產品的最佳方式。建議為用戶提供便利，方便他們向熟人推薦產品。
8. 全球化。易于本地化的產品設計可以大大節省開發成本和開發時間，避免為了語言、貨幣、文化差異大量改寫程序。這樣隨著產品業務的拓展，我們可以迅速適應當地用戶的需求。
9. 平滑部署。網站用戶數量過百萬后，任何小小的變化都會影響大面積的用戶，要三思而行。除了逐步過渡，為用戶留出足夠的時間來適應變化，還要盡量減少不必要的更新。用戶小花、吸收新事物不是件容易的事。
10. 用戶社區管理。如果用戶認可我們的產品，他們會很樂意成為用戶社區的一員，同時希望得到重視和認可。與用戶交流的方法有很多，多和他們接觸，了解他們希望如何改進產品。多用類似于“回饋用戶”的活動表達對他們的重視。讓公司上下認識到用戶的重要性，真正從行動上把用戶當上帝。

處理好以上十個問題，打造大眾網絡服務的過程會輕松許多。

Ch38 · 打造企業級產品的經驗

十大要點

介紹了打造企業基礎軟件和企業應用軟件的方法。

Ch39 · 打造平臺產品的經驗

最具挑戰性的工作

所謂平臺產品，是指一類基礎軟件，應用開發者能在其基礎上開發應用程序。平臺有很多種，例如，操作系統（Windows、Mac、Android)、運行環境（Java、Flash）、web服務（亞馬遜和eBay的集成應用程序接口）、游戲開發平臺，以及應用平臺（Facebook）。

這種工作的艱難在于要面對三種不同的客戶：

1. 應用軟件供應商 選擇你的平臺創建解決方案的公司；關心平臺開發商的生存能力，如果我們的公司突然破產，或不再為平臺產品提供技術支持，讓他們的業務受牽連。此外，他們還關心平臺產品的定價、認證情況、產品質量、技術支持能力，以及將產品國際化的難易程度等。
2. 開發人員 應用軟件供應商的雇員，由他們在平臺上開發應用軟件；關心平臺產品是否支持自己慣用的編程語言、開發工具、基礎架構，希望迅速、便利地開發出性能好、可靠性高的應用。
3. 終端用戶 應用軟件的使用者，也是平臺服務的真正使用者。只在意最終結果。如果平臺產品上沒有需要的功能和服務，或者功能和服務和想象的不吻合，他們就不會掏錢，應用軟件供應商就無利可圖。

這三方各自有著截然不同的需求。除非同時滿足他們的需求，否則我們無法打造成功的平臺產品。

很多產品經理忽略終端用戶的需求，把開發人員擺在第一位，這是普遍存在的誤區。實際上，只有讓終端用戶滿意，平臺產品才是成功的。

管理平臺產品還有其他的困難：沒有統一的交付形式（嵌入式產品、自有品牌、聯合品牌、托管服務等）；客戶的定制要求多種多樣。技術支持是管理平臺產品的另一個難點。客戶是我們賴以生存的根本，因此必須提高技術支持的服務能力和服務水平。

盡管管理平臺有很多難點，但平臺產品的潛在能量巨大，如果能夠妥善處理以上這些問題，圍繞產品會形成一個繁榮生態系統，實現各方共贏的局面。

總結

Ch40 · 最佳實踐經驗

十大要點

1. 產品管理的職責。不要把大把時間浪費在與產品管理無關的工作，如營銷管理和項目管理上。這些都不是產品經理該干的活。
2. 用戶體驗。 對大多數軟件產品來說，用戶體驗就是生命。
3. 機會評估。用方便快捷的機會評估方法取代過時的市場需求文檔。動手設計產品前，先明確產品要解決什么問題，為誰解決問題，以及評估產品的標準。
4. 特約用戶。打造優秀的產品沒有任何捷徑，只能請用戶反復試用產品，不斷改進。
5. 產品原則。產品管理工作的主要內容是制定決策。明確的產品原則可以幫助產品經理和產品團隊樹立清晰的價值標準，作出果斷的決策。
6. 人物角色。人物角色是協助產品經理制定決策的另一項工具。
7. 探索（定義）產品。產品經理的主要職責是探索（定義）有價值的、可用的、可行的產品。
8. 使用原型。使用高保真原型是探索（定義）產品的關鍵步驟。
9. 用戶參與原型測試。有了產品原型，產品經理可以方便地請用戶驗證產品創意。
10. 根據數據改進產品。改進產品不是根據客戶要求一味增加新功能，而是根據產品的實際應用情況，不斷地提升產品的各項指標，逐步完善產品。

Ch41 · 產品經理的反省清單

十大問題

出色的產品經理會時刻關注產品的現狀與未來。以下是產品經理無時無刻不在思考的問題：

1. 產品能吸引目標消費者的關注嗎？
2. 產品的設計是否人性化，是否易于操作？
3. 產品能在競爭中取勝嗎？即使是面對未來風云變化的市場，依舊有取勝的把握嗎？
4. 我了解目標用戶嗎？產品（實際開發出來的產品，而非理想的產品）是否能得到他們的認可？
5. 產品是否有別于市面上的其他產品？我能在兩分鐘內向公司高管清楚地闡明這些差別嗎？能在一分鐘內向客戶解釋清楚嗎？能在半分鐘內向經驗豐富的行業分析師解釋清楚嗎？
6. 產品能正常運行嗎？
7. 產品是否完整？用戶對產品的印象如何？銷售業績如何？銷售任務能否順利完成？
8. 產品的特色是否與目標用戶的需求一致？產品特色是否鮮明？
9. 產品值錢嗎？值多少錢？為什么值這么多錢？用戶會選擇更便宜的產品嗎？
10. 我了解其他團隊成員對產品的看法嗎？他們覺得產品好在哪里？他們的看法是否與我的觀點一致？