第21章：產品驗證
證明產品的價值、可用性、可行性
- 可行性：主要是技術可行性驗證，評估技術成熟度，做技術預研，確保技術可行。比如當前最火的AI產品，語音、圖像識別的技術日漸成熟。
- 可用性：建議拿產品原型給用戶使用，發現用戶體驗的問題，有時候也發現新的需求。產品經理和交互設計師共同完成。
- 價值：三個方面，產品是否有用，即解決了用戶問題/滿足了用戶需求；用戶是否愿意付錢；用戶是否喜歡?？梢杂泻芏喾N方法進行驗證，比如原型。越提前越好。
第22章：原型測試
把產品創意呈現給真實用戶
- 爭取用戶研究團隊和可用性測試團隊的支持很重要，目前很多公司有這樣的角色。
- 產品可用性測試和價值測試同樣重要
物色測試者
- 特約用戶，不是早期嘗鮮者
- 企業產品可以去同類產品展銷會
- 分類信息網站發公告
- 親朋好友，注意排除科技從業者、過于親密的人，不能只是親友
- 郵件列表，求助營銷團隊幫助篩選
- 公司官網，注意區分嘗鮮者
- 大公司定期組織的測試
- 走出公司，到用戶聚集的地方，比如賣場，注意準備禮物
- 邀請用戶上門，注意賠償用戶時間損失
- 測試前提醒，注意電話、語音留言等
準備測試
- 準備測試內容，用戶大部分時間做的操作
- 看用戶未接觸產品原型前是如何解決問題的
- 看用戶是否能從首頁看出產品要解決什么問題，哪些地方最吸引他們
- 完成測試后通過聊天進一步了解收集信息
- 給每個問題打分
- 不用所有功能開發完成才開始測試，了解測試者的期望和實際實現的差距
測試環境
- 準備一個可以讓用戶放松的環境，實驗室，星巴克都可以
- 在用戶的辦公室也可以，可以更加接近用戶使用場景，環境，比如顯示器大小，網速等
- 面對面測試必不可少，因為可以觀察用戶表情和肢體動作
- 產品經理應親自參加測試，可以獲取很多第三方測試遺漏的細節
- 產品經理和交互設計師應該承認產品不完美
- 最好一個人主持測試一個記錄
- 可以邀請交互設計師，技術開發，高層等其他角色共同完成測試
測試原型
- 測試前不要說太多話，避免透露太多細節，最好五分鐘內就進入測試
- 告訴測試者這個只是原型不是正式產品。說出真實想法，不管好壞
- 讓測試者保持平和心態，不要陷入吹毛求疵。不要引導測試者，比如你覺得界面上哪三個元素沒用
- 保持安靜，讓測試者自己嘗試，不要提示
- 通常有三種測試結果，順利完成，受到挫折努力后完成，放棄，測試失敗
- 避免提示，可以問測試者在想什么，但不要太多
- 向鸚鵡學習測試主持技巧，自言自語，重復測試者提問，描述他們做的
- 測試的目的是理解目標用戶如何看待產品要解決的問題，發現產品原型不符合用戶直覺和習慣的地方。
- 從測試者的表情和語氣里可以發現很多有用的信息。
更新原型
- 如果兩個測試者提出同樣問題，即可快速完善原型。如果連續六個用戶認可產品價值并完成關鍵測試，即可結束測試
- 如果發現無法讓用戶認可產品價值或者讓產品足夠簡單用，放棄產品產品創意。
第23章 改進現有產品
不是一味的添加功能
- 開發產品的第一步是要明確目標，考慮產品的一些關鍵指標。
- 考慮從哪些方面改進用戶體驗
- 產品經理應該時刻關注指標，和各個角色一起通過各種分析來改善指標
- 改進產品不是滿足個別人的需求，提高指標的功能才是好的改進。
第24章 平滑部署
避免更新產品導致用戶反感
不是所有用戶都喜歡更新，原因可能：
- 用戶學習、更新成本高，更新頻繁
- 新版本有問題、不兼容等
- 無用的新功能更新
- 用戶習慣改變
降低版本更新影響的措施：
- 提前做好更新通知
- 做好質量管理
- 并行部署或者增量部署
--同時保持新舊兩個版本，用戶接受了新版本再全部更新
--分多次更新避免一次帶來很大的沖擊
--分地域部署
第25章 快速響應階段
產品發布后切莫虎頭蛇尾
- 產品發布后不要急于撤出資源進入下一個項目，保留一段時間快速解決用戶反饋的問題和意見
- 評估產品表現，最好的方法是通過量化的指標，用什么指標取決于商業目標
- 可以通過網站分析工具、用戶問卷調查、郵件組、現場測試等各種方式收集反饋。
第26章 合理運用敏捷
十大秘訣
定制軟件（custom software）vs產品軟件（product software）
- 產品經理就是產品負責人，敏捷不會讓他更輕松
- 使用敏捷同樣要做產品規劃，明確方向和目標，只不過是短周期、迭代的、輕量級的
- 產品經理和設計師的工作領先一兩個迭代，不能一邊設計一邊開發。讓開發人員參與設計和原型評審，獲取成本、可行性、解決方案相關意見。
- 設計工作也要拆分成獨立的部分，加快速度配合敏捷節奏，但不能拆的太散
- 產品經理的主要任務是定義可行的、有價值的產品原型和用戶故事。以此替代文檔的好處：1）可以請用戶測試原型；2）強迫產品經理全面認真的思考問題；3）明確描述每輪迭代內容，避免浪費
- 讓開發人員自己劃分迭代周期，有的需求一個迭代可以完成，有的要跨迭代，還要考慮產品的質量、可靠性、擴展性等。
- 產品經理和交互設計師必須參加每天的站會。關于產品的討論會持續一天。
- 產品經理驗收通過才能發布新版本，避免頻繁更新
- 每次迭代后產品經理向整個團隊展示成果，及下一輪迭代的原型。
- 開展敏捷培訓，確保團隊成員都理解敏捷方法。
迭代初期的產品能用作原型嗎？
- 用一個迭代周期開發原型太浪費了
- 產品定義階段還有很多重要工作，都來開發原型會影響其他投入
- 一旦進入開發，再調整產品設計就很難了
敏捷方法可以用來開發產品軟件嗎？
- "原始"的敏捷方法源于客戶定制軟件開發，認為客戶了解自己的需求，不需要產品經理和用戶體驗設計?？焖俚尶蛻舾绲目吹阶约憾ㄖ频漠a品，也讓開發團隊更早獲取反饋，省去了文檔的麻煩，等等
- 產品軟件必須盡量完美才能贏得市場，滿足廣大用戶的需求、完整的用戶體驗設計等。
- 敏捷軟件開發需要考慮產品的發布和部署、考慮用戶體驗設計，同樣試用產品軟件開發。很多敏捷方法里面并沒有提到產品經理和用戶體驗設計師的工作。
- 敏捷里面的重構和快速調整產品架構對簡單的客戶定制軟件可行，對復雜的產品軟件不可行。
第27章 合理利用瀑布式開發方法
揚長避短
傳統瀑布式開發理念：
- 采用階段式開發：需求、高層設計、低層詳細設計、編碼、測試、部署。
- 采用階段式評審
瀑布式方法為什么經久不衰 - 只要精確定義需求，項目就是可預期的
- 詳細的文檔讓人安心
瀑布式方法讓產品經理頭痛的地方： - 驗證嚴重滯后：應該盡可能做原型測試，確認用戶需求。提前確定產品可行性。
- 變更計劃代價不菲：及時跟蹤需求，早變更比晚變更好
- 無法適應快速的市場變化
第28章 創業型公司的產品管理
關鍵是產品探索
前期只設置三個角色，產品經理（可以由創始人兼任）、交互設計師（可以由原型人員兼任）和原型開發人員
1） 創建體現用戶體驗的高保真原型
2） 邀請真實的目標用戶驗證產品原型
驗證產品原型后，再招聘開發人員進行正式產品開發。
第29章 大公司如何創新
有困難，但值得一試
兩大影響大公司創業氛圍的因素：企業文化和老板的觀念。
大公司創新方法：
- 20%法則：留出20%的工作時間
- 臭鼬工程：利用自己的時間，偷著干
- 仔細觀察：觀察用戶使用產品的表現。創新是用新方法解決現有問題
- 改善用戶體驗
- 收購小公司
第30章 在大公司施展拳腳
十大秘訣
首先了解兩大規則：盡量規避風險和矩陣管理
- 了解公司決策的方式，誰決策，他的習慣是什么，說服他
- 建立人脈網絡，主動幫助別人
- 臭鼬工程：找三五同行
- 自己頂上：自己做，不要等
- 有選擇的據理力爭：對事不對人
- 會前溝通，形成默契
- 合理分配時間：產品經理流出構思產品路線圖、分析產品原型、研究競爭對手的時間。
- 分享信息：共贏
- 向上司借力
- 傳播你的產品理念
