a.確定待解決的問題
評估產品機會的目的：淘汰餿主意，避免浪費時間和金錢；挑選合適的產品機會，團結團隊，理解產品，整合資源。
評估產品機會需要回答的問題（不涉及具體的解決方案，機會評估只討論待解決的問題）：
產品要解決什么問題——產品價值
為誰解決這個問題——目標市場
成功的機會有多大——市場規模
怎樣判斷產品成功與否——度量指標或收益指標
有哪些同類產品——競爭格局
為什么我們最適合做這個產品
時機合適嗎——市場時機
如何把產品推向市場——營銷組合策略
成功的必要條件是什么——解決方案要滿足的條件；指的是在調研過程中發現的特殊需求，不是要描述解決方案，而是搞清楚產品的依賴因素和約束條件，例如要通過系統集成商來銷售產品，對方可能會對產品的擴展性、合作方式提出要求。
根據以上問題，給出評估結論——繼續或放棄
b.開發新產品還是維護舊產品：評估兩者的收益與成本，然后由管理團隊做出決策。
c.錢花在哪兒：認識財務部門的同事
幫助你了解產品：了解產品經濟學、產品的收益模式、產品的成本、產品的具體收益
幫助你了解用戶：了解用戶的交易記錄、支付信息、客戶數據與經營報表
確認商業上的可行性
a.定義正確的產品
軟件項目分為兩個階段：弄清楚要開發什么產品，即定義正確的產品；開發該產品，即正確地開發產品
探索產品階段——探索出兼具功能性與設計性的產品：分析各種創意，廣泛收集用戶需求，了解如何運用新技術，拿出產品原型并測試，從全局視角思考產品方向，兼顧短期需求和長期規劃。
開發階段：切換重心，重心在于開發、測試、發布。確保大家集中精力，捕捉軟件開發不可避免的問題并迅速解決，不輕易修改產品定義。
采用流水線方式并行開發產品：一旦1.0版本進入項目執行階段，就開始定義2.0版本。
b.探索產品的進度可控嗎
首先，產品經理應該探索是否有用戶需要產品，也就是尋找市場，讓用戶驗證你的構思；其次，產品經理要探索能夠解決問題的產品方案，設計有價值的、可用的、可行的解決方案，請用戶和開發團隊來驗證。
定義產品本質上是創造性的工作。
確定方案后，才能全面進入執行階段。
a.確定什么最重要
產品原則是對團隊價值觀和信仰的總結，用來指導產品團隊做出正確的決策和取舍，是一系列明確的、體現團隊特色的產品價值準則。例如，某電影網站的產品原則是相信社區用戶比專業用戶的影評更有價值。
僅僅羅列出產品原則還不夠，還要按照重要性排序，例如易用性與可靠性哪個為先。
容易出現的兩類錯誤：原則過于空泛，失去了指導作用；把設計原則誤當為產品原則。
b.解決意見沖突
建設性的辯論和論證是定義優秀產品的必由之路。
作出產品決策前要達成的共識：
究竟要解決什么問題
要為哪類人物角色解決這個問題
產品要達到什么目標——易用性、響應速度、功能、成本、安全性、用戶隱私等等
每項目標的優先級是什么
將共識在討論前再次強調，作為評估方案和制定決策的確切依據；制定決策的過程必須完全透明，清楚展示決策的依據。
a.制定更及時、更可靠的產品決策：成立產品評審團是及時做出明智的產品決策的最好解決途徑。
b.產品評審團的工作目標：決定產品戰略方向，從宏觀上監督產品研發流程，合理配置資源。在給定的商業戰略的條件下，提出與之相匹配的產品戰略。
c.產品評審團的人員組成
首席執行官/首席運營官/部門總經理
產品管理總監/副總監
用戶體驗設計總監/副總監
市場總監/副總監
開發總監/副總監
網站運營總監/副總監
客戶服務總監/副總監
確保每個關鍵部門都有代表參加；人數控制在10人以內；選一個人代表其部門陳述觀點
d.產品評審團的職責：監督產品研發流程，制定關鍵決策，根據研發產品的四個里程碑來評審產品。
評審產品戰略和產品路線圖，啟動產品評估的工作，即選擇值得投入精力的產品，請產品經理開始評估產品機會。
根據評估產品機會的結果，決定是否開始定義產品的解決方案。
評審產品原型、用戶測試結果、成本估算明細，決定是否開始開發產品。
評審最終產品、產品品質、發布計劃、社會效應，決定是否發布產品。
e.注意事項
小公司的評審團通常負責評審公司所有產品；大公司則需要根據業務單位的大小，設立若干個產品評審團。
評審團不負責評審對產品細節的更新或修正。這是為了加快對細節問題的處理，保證業務運行流暢。
評審團不負責具體的產品設計工作。若產品存在缺陷，應由產品團隊處理，再提交評審。
在2號里程碑處，不可憑直覺估算產品的成本，至多只能估計大致的項目規模（小型、中型、大型三級）；在3號里程碑處，應仔細估算開發時間和成本。
盡量避免評審團討論具體執行策略。
開會頻率取決于具體產品的進度。
評審團還應該回顧、分析產品上市后的表現，可在發布3-6個月后，請產品團隊匯報產品的市場業績表現，反思之前決策是否明智，今后如何調整。
最好由產品經理匯報產品的進展情況，需要準備充分、提前逐一向評審團成員做簡要匯報。
f.何時估算項目成本
在評估產品機會時做粗略估算，根據最終的產品說明文檔做詳細估算。
在定義解決方案過程中，產品經理和交互設計師需要一位開發人員協助評估不同解決方案的成本，根據結果調整方案。完整的產品說明文檔形成后，根據文檔細節生成詳細可靠的成本估算結果。
a.產品開發伙伴
產品經理既需要深入洞察目標用戶的需求，又需要贏得用戶對產品的推薦。建議征集特約用戶（用戶顧問委員會/用戶評審團）協助完成產品研發。
在項目開始階段物色8-10個用戶，從中篩選出至少6位積極、活躍、樂于分享的目標用戶。要求他們在產品的目標用戶中具有一定影響力。
b.成為特約用戶的好處
參與構思產品創意，解決他們手頭的問題。
提前試用產品，顯著降低用戶的各種成本。
c.產品經理的收獲
聚攏一批積極的用戶，為定義產品和開發產品提供建議和協助。
提供調研便利。
可以定期組織特約用戶進行小組討論。
特約用戶第一時間試用、測試產品，迅速反饋意見。
如果特約用戶滿意產品的表現，會樂意公開推薦產品。
d.組織特約用戶的注意事項
不要收取參與費用。
人數要控制在10人以內，才能有時間與精力進行深入溝通。
如果尋找特約用戶時遇到困難，很可能是因為產品要解決的問題并沒有預想中那么重要。這可以初步驗證產品創意是否有價值，應該重新考慮產品計劃。
確保特約用戶是產品潛在的目標用戶，而非產品嘗鮮者（early?adopter），嘗鮮者常常能忍受產品的不足和缺陷。
務必向特約用戶說明，要開發的是面向大眾的通用產品，而非針對某公司開發的定制產品。
應將特約用戶當成開發伙伴對待。
合作貫穿每個環節：向他們展示產品原型、請他們參加測試、向他們請教產品的細節問題、讓他們幫你部署、測試待發布產品的各種版本。
正式產品發布之前，一定要請特約用戶先試用，確保每個人都滿意。
產品經理要和產品營銷人員合作。他們可以幫忙物色特約用戶，協助你提高特約用戶受關注的程度。
如果是平臺產品，6個用戶要換成6個應用。產品經理要與特約應用的開發者緊密合作，確保在平臺上構建的應用讓用戶滿意，最好鼓勵應用開發者發展自己的特約用戶。
e.該不該與用戶交流
產品經理應該盡可能地親自拜訪用戶，與用戶交流，參加每一次的可用性測試和特約用戶研討會。
產品經理必須與用戶充分溝通，挖掘每個人的潛在需求，捕捉產品創意。
產品經理應該充分利用公司的可用資源，如尋求用戶研究部門、營銷人員、主程序員的幫助。
與用戶打交道的過程中，會發現一些富有洞察力、善于思考的用戶，應設法與他們保持聯系，他們是最佳候選人。
a.理解市場調研的作用與局限性
常用的市場調研工具和方法：
用戶調查：設計調查問卷需要技巧和經驗，要結合具體情景，仔細設置問題；調查結果為獲得解決方案提供了一條途徑，但不是解決方案本身。
產品使用分析：在產品中使用分析工具記錄用戶的行為。應該明確告知用戶分析工具的用途，聲明只收集統計數據，不涉及用戶隱私。
數據挖掘：新的數據分析工具。
拜訪用戶：前往用戶使用產品的場所實地考察。
人物角色：務必找出若干種用戶類型，深入了解他們，弄清哪些是當前的用戶，哪些是潛在的用戶。
可用性測試：盡早、反復地進行可用性測試，觀察用戶使用現有產品的反應，收集反饋意見，了解他們的真實想法。從用戶的視角重新審視產品，不光閱讀反饋信息，更要記錄用戶的行為和反應（如興奮、沮喪）。
同類產品分析：找出競爭對手的優勢，學習對手的成功經驗。
合理地利用市場調研工具和方法可以回答以下幾個關鍵問題：
誰是目標用戶？
用戶會怎樣使用產品？
用戶能想明白怎樣使用產品嗎？障礙在哪里？
用戶為什么選用你的產品？
用戶喜歡產品的哪些特點？
用戶希望如何改進產品？增加哪些功能？
市場調研的局限性：
市場調研不直接回答最根本的產品問題：打造什么產品。市場調研可以作為研發產品的依據和參考，但是不能決定產品研發的方向。探索產品的過程則要回答以下問題：采用什么技術來更好地解決產品要解決的問題；設計什么樣的用戶體驗。
成功的產品基于以下兩點認識：深入理解用戶需求；明白什么樣的解決方案在現階段是可行的。
b.關于用戶研討會
雖然組織用戶研討會可以面對面了解目標用戶對產品的看法，但不可能討論出成功的產品。因為用戶不知道什么樣的想法是可行的，多數用戶對技術一無所知；沒見到實際產品，用戶很難憑空想象自己需要什么。
用戶研討會的其他弊端：
人群聚集時容易沖動，相互影響。
除非讓用戶實際試用產品，否則他們不清楚自己想要什么。
需要主持人熟悉組織技巧，能隨機應變，還得掌握產品領域的知識，擅長引導話題，才能獲得預期的效果。
a.理解目標用戶
人物角色又稱為用戶特征記錄（user?profile），是指通過與用戶溝通交流，確定典型的目標用戶類型，在理解各類目標用戶的特征的基礎上建立的人物原型。人物角色是合理地描述用戶特征的人格化虛擬原型，重點關注用戶的行為、態度、目標。
為了發掘潛在的人物角色，產品經理必須深入參與創建人物角色的工作，尤其要親自參加用戶交流、用戶調查、產品可用性測試。與交互設計師、用戶研究團隊緊密合作，抓住一切機會與用戶交流，深入了解目標用戶。
人物角色的主要用途：
篩選重要的產品功能。人物角色既有助于決定誰是目標用戶，也有助于決定誰不是目標用戶。面面俱到的產品往往一無是處，使用人物角色可以避免犯這種錯誤。
避免產品團隊將自己的需求當成用戶需求。
許多產品的用戶類型不止一種，使用人物類型有助于對用戶類型的優先級進行排序，識別需要重點考慮用戶體驗的地方。
方便向團隊描述產品的目標用戶是誰，他們怎樣使用產品，他們關心產品的哪些方面。
幫助團隊成員達成共識。
人物角色的注意事項：
每個發布周期，可以集中精力關注一類關鍵人物角色，把產品的優勢發揮到極致。
創建前需要花時間與用戶面對面交流，不能基于憑空想象和刻板印象。
邀請用戶參加產品原型測試，不僅僅要邀請關鍵人物角色，建議邀請多樣化的用戶參加。
a.安息吧，紙質說明文檔
理想的產品說明文檔應該滿足以下要求：
產品說明文檔應該完整地描述用戶體驗——不只是用戶需求，還包括交互設計和視覺設計。
產品說明文檔必須準確地描述軟件的行為。
產品說明文檔的受眾較廣：開發、測試、客服、市場營銷、運維、銷售、管理層等等。因此，產品說明文檔必須以某種直觀的方式把產品信息和產品行為告訴所有人。
產品說明文檔應該可以修改。進入開發階段后應該避免修改，但意想不到的情況出現時需要修改產品說明文檔以適應新情況。
撰寫產品說明文檔的過程中會出現很多衍生物，比如按優先級排列的需求列表、線框圖、實體模型，但應該有一個主體來代表產品，避免混淆不清，版本錯亂。
只有一種形式的產品說明文檔可以以上滿足要求，即高保真產品原型?！案弑Ｕ妗钡暮x是原型應該真實地體現用戶體驗，盡可能地體現產品細節——包括所有的頁面和主要的用例。如業務邏輯（稅務表單和運費等）、發布要求（性能表現、可靠性、拓展性等）、平臺交付要求（安裝要求、瀏覽器兼容要求等）不容易用原型體現，可以使用用例作為有效的補充，描述重要的產品行為。
可以用wiki或網站實時更新展示的說明文檔，文檔的主體應該是高保真原型，由它體現產品的功能需求、信息架構、用戶體驗、交互設計、視覺設計。
高保真原型突出的優勢是可以用來測試，讓真實用戶體驗，觀察他們是否清楚如何使用、是否渴望使用；高保真原型可以大大縮短產品上市時間。
a.先定義用戶體驗再動手開發
需求調研與產品設計可以同步展開、軟件開發與產品測試也可以交叉進行，但用戶體驗設計與開發不能放一起進行，原因如下：
一旦產品進入開發階段，再修改設計思路是非常困難的，越往后成本越高。因為開發團隊必須根據確定的用戶需求和產品定義設計軟件架構，然后進行開發。前期的架構決策極大地制約著后期的開發工作。
用戶體驗設計要保證產品同時具有可行性和價值，必須盡早、反復地驗證設計思路。驗證設計思路必須使用高保真原型。
盡管開發可以分成多次迭代（降低風險、提高質量、便于產品集成），用戶體驗設計卻不能拆分。設計師必須全面、連貫地看待用戶體驗，考慮以往用戶的使用習慣。讓用戶放棄不可用的軟件很容易，讓他們放棄使用習慣卻很難。
用戶體驗設計不一定是最費時間的工作（像軟件開發一樣，取決于具體的方法、特定的產品需求、從業者的技能和經驗），但至少需要一兩周的時間。
如果兩者同步展開，一方面，開發人員等著設計師的結果無事可做；另一方面，設計師飽受壓力，倉促了事。
敏捷方法里有個概念叫第零次迭代（sprint?zero），產品經理和用戶體驗設計師利用這段時間先完成產品設計工作，然后交由開發人員開始迭代開發，這需要更詳細地定義開發任務（backlog），但團隊工作會更愉快，產品也會更好。
只有在開發人員需要開發大量后臺基礎軟件的情況下，兩者才能并行展開。
盡管需求調研和產品設計都要在軟件開發前完成，但在此期間至少要邀請一位開發人員檢查設計工作，協助評估設計的可行性和成本，做出更明智的決定。
a.削減功能還是延長工期？
老式的產品設計方式：產品經理制作了完善的產品說明文檔，詳細標注了各項產品功能的重要等級，然后開發部門根據這份文檔估算開發成本和開發時間。估算得到的結果往往超過產品經理的預期，于是不得不削減功能、縮小測試范圍、減少公開測試時間、雇傭額外的開發人員，最后開發出來的產品完全不是有機的整體。
建議采用另一種產品設計方式：
產品經理與設計師合作設計產品的高保真原型，這個原型只具備實現商業目標的最基本功能要求，以及良好的用戶體驗和吸引力。只設計基本功能的產品可以把復雜度降到最低，把開發時間減到最少。
邀請一位開發人員（比如架構師或者主程序員）參與設計原型。請他檢查原型，幫助產品經理和設計師估算各種功能的直接成本和間接成本，指出設計上的誤區，并分析、評估尚不確定可行的功能。等產品原型確定時，詳細估算出產品功能的時間成本。這樣一來，各項功能孰去孰留已經明了。
請真實用戶驗證、測試原型。一旦通過，就不再削減任何功能。如果還能削減，說明你定義的不是基本產品。
如果估算過于樂觀，只能延長工期，不能再削減，因為你已經沒有東西可以削減了。因此設計產品時一定要考慮哪些功能是最重要的，爭取設計出只滿足基本要求的、不可刪減的產品。
a.證明產品的價值、可用性、可行性：產品驗證是指在正式開發、部署產品前，驗證產品說明文檔描述的產品是否符合預期要求。
b.可行性測試：首先要明確在現有的技術條件下，能否成功開發出產品。邀請架構師和開發人員深度參與技術調研，尋找可行的方案。
c.可用性測試
交互設計師應該與產品經理密切合作，想方設法突出產品的功能特性，讓不同類型的用戶都能明白如何使用。
可用性測試往往能發現沒能成功實現的產品需求，最好規劃多次迭代測試，確保實現最佳的用戶體驗效果。
一定要請真實的用戶來試用可用性原型，從目標用戶那里可以得到寶貴的反饋信息。
為了測試可用性，即使是要模擬復雜的后臺處理過程也是值得的，關鍵是要評估用戶體驗的實際效果。
d.價值測試
目的是要知道用戶是否覺得你的產品有用，是否愿意購買，有多喜歡產品的設計。
可以和可用性測試同時進行，使用同樣的原型。只不過可用性設計重在觀察用戶如何設法完成必要的操作，價值測試重在觀察用戶是否喜歡這些功能，是否滿意功能的具體實現方式。
a.把產品創意呈現給真實用戶：讓真實用戶驗證產品設計，是產品經理最為重要的工作。
b.物色測試者
如果已經擁有一批特約用戶，可以邀請他們參與測試。
如果是企業級產品，同類產品的展銷會會是尋找目標的好去處。
可以在分類信息網站發布廣告征集測試者，征集要求不必太過具體。事后打電話給感興趣的應征者，進一步篩選。
如果是大眾產品，可以邀請自己的親朋好友參加測試，但要避開過于親密的人和科技行業的從業者，除非他們就是目標用戶。測試者也不能只限于親友。
如果手頭有用戶的電子郵件列表，可以從中篩選，營銷團隊可以幫你縮小名單范圍。
可以通過公司網站征集志愿者，但還需要打電話聯系篩選，避免參加測試的全是產品嘗鮮者。
較大的公司可以定期開展原型測試活動（比如兩周一次），每次邀請10-20位測試者參加。讓所有產品經理自己申請時段，安排每位測試者參加測試一兩個原型。
到街頭巷尾、用戶聚集的地方去。開發電子商務產品，應該去大的商品賣場尋找測試者；開發體育產品，就到體育酒吧?？梢运托┒Y物表示謝意，注意放低身段。
如果邀請測試者上門參加測試，應該補償測試者為此損失的時間。如印有公司標志的帽子、電子購物券等。
在測試前一天致電測試者再次確認約定的測試時間，防止測試者忘記這件事。
c.準備測試
事先擬定測試內容。比如產品是電子郵件客戶端，用戶必然要完成寫郵件、讀新郵件、歸檔郵件之類的操作。你應該著重測試主要項目——用戶大部分時間執行的操作。還有一些不那么重要的項目，可以等到時間有富余再測試。
你只有一次機會了解測試者未接觸產品原型之前如何解決產品要解決的問題。如果是點評餐館服務的網站，先不要讓測試者登錄產品原型的界面，只提供空白的瀏覽器，看他們會訪問哪些點評網站，習慣按地點、菜式還是價格來搜索。原型設計多少有些假設的內容，直接讓測試者使用原型，就無法獲取這些寶貴的信息了。
測試原型前還有一件事要做，就是觀察測試者能否從原型首頁看出產品要解決什么問題，哪些地方最能吸引他們。一旦他們進入測試任務，就不會再有首次訪問的感覺。首頁的設計極大地影響著實際使用效果與用戶期望之間的差距。
待測試者完成測試任務、了解產品用途后，通過聊天進一步收集信息。比如，他是否使用過同類型產品，習慣借助網絡解決這個問題還是另有方法，原型是否比他常用的產品好。也可以問一下凈推薦值：他有多大可能性向朋友推薦這款產品。
為每個問題的答案打分（如0-10分），或者干脆讓測試者用數字來回答問題，以此記錄每個階段產品原型的表現。用打分的方法便于跟蹤記錄產品原型的總體表現，為完善產品設計提供參考。
不必等到完整原型完成后再測試，可以先測試主要項目，即使某些功能空著也沒關系。如果測試者遇到功能上的死胡同，問問他們，接下來希望發生什么。測試者試用已有功能前，也可以問這個問題，看看實現方式與測試者的期望是否一致，往往能獲得寶貴的意見。
d.測試環境
配有單向透明鏡和閉路監控以及多個攝像機同時拍攝用戶和顯示屏的正規測試實驗室，或者簡單的桌椅加電腦，都是可以的。
用戶的辦公室也是上佳的測試場所。熟悉的辦公環境可以讓他們充分展示日常工作中的使用習慣。另外還能觀察用戶的辦公室：顯示器多大、電腦處理能力如何、網速多快、如何與同事溝通等。
遠程測試無法觀察用戶細微表情和肢體動作，不能替代面對面交流。
產品經理應該親自參加每次原型測試，第三方的測試收集難免遺漏信息。
理想情況下，應該安排一人主持測試，一人記錄?？梢匝堄脩粞芯咳藛T、開發人員、交互設計師、視覺設計師甚至是高管一同參加原型測試。
e.測試原型
測試前不宜與測試者交談過多，簡單寒暄幾句，遞上一瓶水即可開始測試，告訴測試者等測試完再深入交談。
寒暄之后務必告訴測試者，這只是初步的產品創意，不是正式產品；請說出真實看法；被測試的對象是原型而非測試者。
測試時，盡量讓測試者保持平和的情緒，避免進入吹毛求疵的狀態。測試的重點是測試者能否輕松完成產品任務，以及是否喜歡產品的功能。如果測試者提出頁面的元素難看應該換掉，就跑題了。多觀察他們的操作，少聽他們的抱怨。
測試時盡量保持安靜，不要給測試者提示。
通常有三種結果：在沒有提示的情況下順利完成測試項目；遇到麻煩，但通過反復嘗試，最終完成了；受挫，最終放棄。
一般來說，盡量避免提示測試者，更不能引導他。如果他上下滾動頁面，可以問問他想找什么，這類信息很管用。但不要讓用戶不停地說想做什么，這容易讓他變得吹毛求疵，不是一種常態。
主持人不妨使用自言自語的技巧，這可以避免引導用戶。如果測試者很安靜，可以口述他們正在做的事，比如：我看見你正在瀏覽右側的列表。測試者接著會告訴你他想做什么，諸如此類。
測試的作用是理解目標用戶如何看待產品要解決的問題，發現原型和用戶期望不一致或不相容的地方，也就是不符合用戶直覺和習慣的地方。只要能發現這些問題，通常都不難解決，從而極大地完善產品。
肢體語言和語氣可以透露許多有用的信息。
f.更新原型
要對測試反饋迅速做出響應，只要有兩三個用戶反映了同一個問題，就動手解決吧。如果有連續6位測試者欣賞和理解產品的價值，而且能完成關鍵的測試項目，就算完成了原型測試任務。
如果你發現沒法讓測試者對原型產生興趣，或是無法讓原型變得足夠簡單易用，讓測試者理解其價值，應該立馬收手，放棄這個產品創意。
推薦書目：《點石成金：訪客至上的網頁設計秘笈》（Steve?Krug）
a.不是一味地添加功能
很多情況下，添加新功能不僅不會為產品增色，反而會讓產品性能變得更糟糕。
開發新產品的第一步是要明確目標。例如投保網站關注注冊率等指標，產品經理就應該時刻關注這些指標，與交互設計師、用戶研究人員、主程序員密切合作，分析改善產品的可能性，還可以進行網站分析，請用戶測試產品，向客服人員、銷售人員了解情況，做盈虧分析，估算凈推薦值。通過分析這些數據改進產品。
改進產品不是簡單地滿足個別用戶的要求，也不能對用戶調查的結果照單全收，能提高指標的功能才是你關注的重點。你應該找準方向，分析關鍵指標，有針對性地改進產品。
a.避免更新產品導致用戶反感
毫無征兆地更新不必要的版本會令用戶產生反感，不是所有用戶都喜歡更新：
事前沒收到更新通知，用戶感到措手不及。
用戶沒時間學習、適應新版本，產品公司也沒有提供舊版本供用戶在過渡階段使用。
新版本無法正常運行。
新舊版本不兼容，例如新版本無法訪問舊版本的數據。
用戶認為新版本添加的功能和特性毫無必要。
應付接二連三的版本更新，用戶感到疲憊。
新版本修改了用戶已經習慣的使用方式和操作流程，用戶不得不重新調整適應。
不能因為用戶可能反感就放棄更新產品，但是更新產品必須謹慎、理智：
通過公告、群郵、在線教程等方式提前通知用戶，但很多人可能既沒時間也沒興趣看，所以效果有限。
加倍做好測試工作，避免新版本存在影響正常使用的隱患，如可靠性問題、擴展性問題、性能問題。確保將來不會出現回退的窘境，為用戶增加不必要的麻煩。
如果更新版本會影響大規模的用戶，應該采取并行部署或者增量部署的方式來降低風險。
平滑部署的方式很多。比如發布兩個并行的版本，邀請有興趣有時間的用戶試用新版本，如果新版本運行正常，大部分用戶習慣之后，再將新版本設置為默認版本，同時將舊版本保留一段時間，公示為舊版本提供支持的最后限期。另一種方式是區域性逐步部署，首先在某個區域內部署新版本，再逐步擴大范圍。還有一種方式是增量部署，將更新分割為幾個較小的部分逐步發布。
a.產品出爐后切莫虎頭蛇尾
產品發布后的幾天至一周內，所有項目成員應該留出時間作為快速響應階段，處理產品發布后的用戶反饋意見。
評估產品表現應該用明確的、可量化的指標，如頁面訪問量、注冊用戶數、訪問停留時間、會員轉換率、訂閱數、廣告收益等。具體使用哪些指標取決于產品的商業目標，應該給指標分出等級并保持關注。此外，對于什么樣的結果代表產品成功，什么樣的結果代表失敗，應該做到心中有數。
一旦問題反饋回來，產品團隊、主程序員、客服人員、營銷人員等應該至少每天召開一次簡短會議，討論問題的輕重緩急，確定最佳解決方案。如通過網站發布補丁、發表聲明公示處理辦法等。
a.十大秘訣
敏捷方法（scrum和極限編程）源自定制軟件（custom?software）領域，不完全適用于開發軟件產品（product?software）。
以下訣竅針對產品軟件團隊，不適用于定制軟件團隊：
產品經理即是產品負責人（product?owner），他代表客戶的需求，因而需要與產品開發團隊保持密切聯系，協助督促開發進程，及時解決出現的問題。
使用敏捷方法絕不等于省略產品規劃。產品經理仍要明白產品的方向和目標，設定衡量產品成功與否的標準。只不過在敏捷環境里，規劃周期應該適度縮短、反復迭代，采用輕量級的機會評估方法代替冗長的市場需求文檔。
產品經理和設計師的工作進度應該比開發團隊領先一兩個迭代周期，確保你們有足夠多的時間攻克難題，不能一邊設計一邊開發。另外，始終讓開發人員參與評估產品設計和產品原型，及時反饋關于可行性、成本、解決方案的建議。
盡量把產品設計工作拆分成獨立的部分，分而治之，但也不能拆得太細，目標是設計出符合基本要求的產品。另外，設計師采用迅速制作原型的方法更能適應敏捷環境。
產品經理的主要任務是定義有價值、可用的產品原型和用戶故事（user?story），作為開發的基礎。用產品原型和用戶故事替代厚厚的產品需求文檔和功能說明文檔有三個優勢：可以請用戶測試；強迫產品經理全面認真地思考問題；向開發團隊明確地描述每次迭代周期需要完成的任務。請用戶測試原型，根據反饋意見反復迭代修改原型設計，確保交給開發團隊的是有價值的結果，避免任何浪費，哪怕只是一個迭代周期。
讓開發人員自主劃分迭代周期。有的產品功能可以在一個周期內完成，有的需要好幾個周期。好的原型可以提高估算工作量和開發時間的精度。開發團隊必須考慮產品的質量、性能、擴展性。
產品經理和交互設計師必須出席每天的晨會。設計師向開發和測試展示產品功能，開發相互展示完成的代碼，讓測試人員測試，請設計師和產品經理過目，測試和開發在制作原型的階段識別潛在的問題，協助產品經理制定更合理的決策，解決產品設計、開發的問題。
除非達到了產品經理的要求，否則不要輕易發布新版本。
每次迭代完成后，產品經理應該向團隊展示產品現狀，以及下次迭代的產品原型。
在團隊內開展敏捷培訓。
b.迭代初期開發的產品能用做原型嗎？
對定制軟件或許可以，對產品軟件行不通：
用一個迭代周期來驗證產品創意時間太長。用幾天時間驗證可更改的產品原型效率更高。
在探索產品的階段，開發團隊還有許多重要的工作要完成，占用開發團隊的時間開發產品原型，會消耗開發正式產品的經歷。
一旦進入開發階段，設計出軟件架構后，再想改變產品設計思路，成本與難度都太高了。
c.敏捷方法可以用來開發產品軟件嗎？
敏捷方法同樣適用于產品軟件的開發，只要進行適當的調整即可。唯一不適合的地方是在架構設計方面，敏捷方法鼓勵開發人員相信簡單重構和快速重新設計架構的優勢，對于產品軟件并不是如此。
a.揚長避短
瀑布式開發方法也叫持續改進方法、里程碑式開發方法。
基本原則：
采用階段式開發軟件。開發過程被事先分成固定的幾個階段：撰寫書面的需求說明文檔、設計高層軟件架構、設計低層細節、編寫代碼、測試、部署。
采用階段式評審。每個階段結束后，對該階段提交的成果進行評審，評審通過后才進入下一個階段。
瀑布式開發方法讓產品經理頭痛的地方：
產品驗證嚴重滯后：產品經理必須等到開發的尾聲，才能看到可以運行的軟件。所以在進入開發階段之前，產品經理必須確保交給開發團隊的產品設計是可行的、有價值的。
變更計劃代價不菲：如果需求發生變化，或者前期設計有缺陷，修改起來成本與時間代價都很大。不過有問題要及時修改，早改肯定比晚改好。
無法適應快速的市場變化：一方面要確保產品設計的正確，另一方面要在發布后以最快的速度修補產品。
因此，使用瀑布式開發，交付時間通常會比預期的晚，而且用戶常常發現產品存在缺陷，開發團隊還要花費大量時間和資金修補、完善。
如果使用瀑布式開發方法，產品經理應該設法規避這些問題。首要的工作是在探索產品階段，制作產品原型，請目標用戶試用，確保產品設計是有價值的、可用的、可行的。只有這樣才能提高產品成功的幾率，同時節約開發團隊的時間和成本。
a.關鍵在于產品探索
建議創業初期只設置三個職位：產品經理、交互設計師和原型開發人員，對應產品管理、交互設計、原型制作三項工作。
產品設計流程：
創建體現用戶體驗的高保真原型。
邀請真實的目標用戶驗證產品原型。
迭代設計產品原型
在迭代設計產品原型的過程中，通常會產生很多版本。隨著迭代的深入，產品會趨于完善。確定產品原型后，再招聘程序員進行開發。
a.有困難，但值得一試
有兩大因素影響著大公司的創新氛圍：企業文化和老板的觀念。
b.20%法則
讓工作人員利用20%的時間從事創新研究。
若公司不同意在工作時間創新，那我們只好私下開展“臭鼬工程”了。
c.臭鼬工程
原指秘密軍事行動，現在指在條件受限的情況下，利用自己的時間，低調地進行創新研究。
在大公司里，普通員工很難憑空獲得允許從事創新研究。如果你能拿出階段性的成果來，獲得許可會容易許多，在這種情況下，只要不耽誤本職工作，管理層通常會支持你的做法。
d.主動觀察
觀察和傾聽是最簡單的創新途徑。仔細觀察用戶使用公司產品或同類產品的一舉一動，留心觀察他們欣喜和失望的表情，假以時日，你肯定能想出辦法更好地滿足他們的需求。注意，應該選擇實際用戶作為觀察對象。
創新不是發現新問題，而是用新方法解決已有的問題。觀察人們對現有產品的不滿，是創新的最佳途徑。
e.改善用戶體驗
另一種創新途徑是跳出技術局限，完善用戶體驗。改善用戶體驗不僅要提高產品的工作效率，更要剔除多余的功能，明白哪些功能是用戶必需的，哪些是設計和開發帶來的衍生物。
每款產品都有特定的實現模型，但用戶腦子里裝的是概念模型，他們對產品要解決的問題，以及如何解決問題有自己的想法。如果實現模型與用戶的概念模型不一致，用戶就會感到失望。找到用戶失望的地方，就找到了創新的機會，至少是改善產品的機會。
a.十大秘訣
大公司都遵循著一條潛規則：盡量規避風險。因此創新更容易發生在小公司里。在大公司工作，首先要面對的就是公司現有的流程、規定和條條框框。
多數大公司都采取矩陣式的管理方式，核心部門（如設計、開發、測試、運維、開發等部門）是共享資源，產品經理要確保爭取到足夠的資源才能研發出產品。采用這種組織結構不是因為它的效率高，而是為了節約公司運營的成本。
在大公司施展拳腳的方法：
了解公司制定決策的方式：知道決策權在誰手里，工作目標就更能明確。
建立人脈網絡：主動向大家介紹你手頭的項目；主動幫助他人，積累人脈關系。
臭鼬工程：找三五個志趣相投的同事在工作之余做出產品原型來。
自己頂上：一切為了推出產品，不要計較個人得失。
有選擇地據理力爭：多一個敵人不如多一個朋友。如果你不滿意同事的工作、或者與他人意見不合，不要亂發脾氣。與人辯論，要小心措辭，做到對事不對人。切記目標是完成產品。
會前溝通，形成默契：設法在重要的決策會議前達成一致意見，會議的主要作用是讓與會者認識著大家取得了一致的意見。
合理分配時間：重新檢查會議日程，劃掉無關緊要的會議；學會充分信任同事，讓他們自己拿主意。產品經理應該留下時間完成自己的本職工作：制定產品戰略、構思產品路線圖、研究產品原型、分析競爭對手。
分享信息：分享信息讓你獲得更多的朋友和資源，作為交換，別人也會分享信息給你。
向上司借力：學會利用上司的關系。利用他的人脈關系，傳播你的理念，多向他請教，了解公司的文化和組織結構。如果需要上司出面說服公司高管，你一定要事前做好充分的準備，為他提供翔實可靠的資料和信息，用實力取得他的信任。
傳播你的產品理念：多向同事傳播你的產品理念，向大家描繪產品愿景，介紹產品策略，展示產品原型，分享用戶反饋信息，為產品爭取支持和資源。
——著作權歸原作者所有——
