接上篇：產品沒有價值，開發團隊再優秀也無濟于事
本文是寫《啟示錄》的讀后感。《啟示錄》作者：Marty Cagen、譯者：七印部落。作者曾經是eBay最出色的產品經理 。《啟示錄》主要圍繞 “ 如何打造用戶喜愛的產品 ？”來闡述一些內容。作者認為好產品具備三個基本條件：價值、可用性、可行性，三者缺一不可。
書中給出解決以下問題的一些方法：
** - 如何挑選有潛力的產品？**
** - 如何證明產品設計符合用戶需求？**
** - 如何確認產品設計滿足三個基本條件？**
** - 如何運用敏捷方法管理產品？**
** - 如何協調公司高管、客戶、營銷人員、開發人員、設計師的要求和意見？**
《啟示錄》分為三個主要部分：人員、流程、產品 ，本文是寫第二部分** “流程” **的讀后感想。后面會以系列文章的形式寫完三部分。
第二部分 流程
這一部分主要是寫了作者在產品開發過程中反復應用的流程和成功的經驗。相比較上一部分的人員篇，這一篇可以說是干貨滿滿，從產品最開始的評估一直到產品的開發、上線都做了詳細的介紹。可以說是本書的精華所在，也是作者筆墨最多的一個部分。
評估產品機會
市場會給予新的產品很多機會，即使是在很成熟的市場也不例外。新的想法、新的創意、新的技術總能在市場上攪起浪花。不斷有舊人淘汰，新人登場。但并不是所有的產品創意都可以轉化成一個落地產品，翹起一個很大的市場，或者是適合自己的市場。有些需要資源、有些需要時機，產品創意最終能否落地，還需要做很多很多。** 評估產品機會是產品經理的重要職責。評估產品機會的目的在于：淘汰餿主意，避免浪費時間和金錢；挑選合適的產品機會，團結團隊，理解產品，整合資源。** 怎么做評估呢？作者給了一些問題其實比較好：
** 1. 產品要解決什么問題？（產品價值）**
** 2. 為誰解決這個問題？（目標市場）**
** 3. 成功的機會有多大？（市場規模）**
** 4. 怎樣判斷產品成功與否？（度量指標或收益指標）**
** 5. 有哪些同類產品？（競爭格局）**
** 6. 為什么我們最近適合做這個產品？（競爭優勢）**
** 7. 時機合適么？（市場時機）**
** 8. 如何把產品推向市場？（營銷組合策略）**
** 9. 成功的必要條件是什么？（解決方案要滿足的條件）**
** 10. 根據以上問題，給出評估結論。（繼續或放棄）**
這些問題并不一定要有解決性的回答，但是在進行評估產品機會的時候，產品經理或者是對產品有決定權的人要把這些問題考慮清楚。相信經過完善的評估產品機會后，會大大提高的產品成功的可能性。
產品探索
這一部分作者要傳達的是：在產品探索階段要定義正確的產品。弄清楚要做什么，在產品領域顯得尤為重要。在模糊不清的狀態下，倉促上馬一個產品，指望著后面的“亡羊補牢”是錯誤的。產品經理在探索產品的階段要：**負責分析各種創意，廣泛收集用戶需求，了解如何運用新技術，拿出產品原型并加以測試，從全局的視角思考產品方向，兼顧短期需求和長期規劃。總而言之就是探索出兼具功能性與設計行的產品。 **
產品原則
產品原則我個人覺得是比較重要的一個點，他是決定一個產品靈魂的基準。為什么的微信發展到今天仍然還是努力的控制著產品的復雜度。就是它的產品原則在起作用。
作者的定義非常好：產品原則是對團隊信仰和價值觀的總結，用來指導產品團隊做出正確的決策和取舍。它體現了產品團隊的目標和愿景，是戰略的重要組成部分。從形式上看，它是一些列明確的，體現團隊特色的產品價值準則。
在我經歷的幾個項目中也是遇到產品需求不確定的情況，原因大都是由于產品的目標客戶，他們會提出不同的產品需求，甚至有些需求是嚴重背離產品最初的功能設計的。尤其是在摻雜了市場人員，領導的個人主管因素后，產品需求的“晃動”非常嚴重。這個時候作為產品經理應該如何處理，產品原則的重要性就體現在這里了。清晰的產品原則對解決意見沖突非常重要。
產品評審團
- 產品評審團的目的是決定產品的戰略方向，從宏觀上監督產品的研發流程，合理配置資源。在給定的商業產略下，定義與之匹配的產品戰略。
- 產品評審團通常由各個部門的管理者組成。各種O，總監，經理等。
- 產品評審團主要職責是監督產品研發流程，制定關鍵決策。
如果當前的公司制定產品決策的效率太低，應該考慮組織產品評審團，產品評審團可以代替之前的各種低效的決策會議，大大縮短決策時間，制定明確、及時、透明的產品決策。當然作者也提到有一些需要在產品評審過程中需要注意的事情，書中都做了詳細的介紹，可去原書查看。
特約用戶
作者定義的特約用戶是，項目在開始階段選擇一些積極、活躍、樂于分享的目標用戶來協助完成產品開發。讓他們在產品的開發過程中充當一定的角色，對產品提出合理的建議。使用特約用戶是確保產品不偏離用戶需求最簡單有效的辦法，同時也是向潛在用戶宣傳、推薦產品的最佳手段。
市場調研
對于市場調研的作用，市場部門和產品部門往往存在意見分歧。主要是市場調研工具和市場調研方法在探索產品中所起的作用。作者認為的工具和方法包括：用戶研討會、用戶調查、產品使用分析、拜訪用戶、可用性／現場測試、同類產品分析。 其實市場調研有它的作用和局限性。市場部門往往會夸大市場調研的作用，而產品部門往往只看到它的局限性。個人認為，市場調研的結果可以用于完善產品精益求精，但是他不會告訴你怎么做，具體還是要出正確的產品探索。
產品人物角色
書中定義：** “人物角色又稱為用戶特征記錄（user profile），是指通過與用戶溝通交流，確定典型的目標用戶類型，在理解各類目標用戶的特征基礎上建立的人物原型。” **我的理解也就是目標用戶，進行產品設計時確定目標用戶也很重要，目標用戶可能是一類人，也有可能是幾類人。只有確定好目標用戶后，在進行產品設計時才能站在目標用戶的角度去思考產品，才能做出用戶真正需要、真正喜愛的產品。
重新定義產品說明文檔
作者用“安息吧，紙質說明文檔”作為標題來表明自己的觀點。確實是，紙質的產品說明文檔會讓人眼花繚亂。產品需求文檔、市場需求文檔、業務需求文檔、功能規格書等等。不僅內容質量良莠不齊，連格式也是差別很多，有的是word文檔，有的是excel表格，有的又是pages和numbers，各種混亂。產品文檔，要向UI設計師解釋一遍，又要跟開發人員解釋一遍，還要跟領導解釋一遍。如果做了些許變動，那個文檔的更新同步簡直要命。
“高保真”的原型圖，一定程度上能迎面解決這些問題。現在制作“高保真”的原型圖工具也很多。當然在一些業務邏輯、發布要求、平臺交付要求方面，“高保真”的原型搭配文字性的用例或者說明更加好一點。
用戶體驗設計與實現
先定義用戶體驗再動手開發，需求調研和產品設計（用戶體驗設置）是相互影響的，應該同步展開。
- 一旦產品進入開發階段，再修改設計思路非常困難，越往后修改成本越高。
- 用戶體驗設計要保證產品同時具備可用性和價值。
- 驗證設計思路必須使用高保真原型。
- 用戶體驗設計不能拆分迭代，設計師必須全面地、連貫的看待用戶體驗，考慮以往用戶的使用習慣。
- 用戶體驗設計的時間要留夠，不能倉促完成。
需求調研和產品設計中都需要軟件開發前完成，但是至少邀請一位軟件開發人員檢查設計工作，協助評估設計的可行性和成本，做出更明智的決策。
基本產品
削減功能還是延長工期？ 做產品的過程中大家有可能碰到過類似的場景。產品經理制作了完善的產品說明文檔，詳細標注了各項產品功能的重要等級。然后，開發部門根據這份文檔估算開發成本和開發時間。雖然剔除了開發團隊力不能及的功能，但得到的進度表還是比產品經理設想的多幾個月時間。于是雙方開始協商，先是爭論估算是否準確，然后不得不削減功能，縮小測試范圍，減少公開測試時間，要求雇傭額外的開發人員......不知不覺時間已經流逝。最后開發出來的產品完全不完整，產品經理不滿意，開發人員不滿意，用戶更不會滿意。很多團隊把這種情況看成是理所當然，不可避免的，其實這是不合理的流程造成的。
所以作者建議定義產品的基本功能，確定基本產品。然后進行目標用戶的產品測試。由于開發的是基本產品，一旦進入軟件開發環節，產品經理就不能再隨意修改設計。
產品驗證
產品驗證是為了證明產品具備價值、可用性、可行性。產品驗證就是要在正式開發、部署產品前，驗證產品說明文檔的產品是否符合預期要求。
產品驗證主要是進行：可行性測試、可用性測試、價值測試。
原型測試
這里才是為什么作者一直提倡使用“高保真”原型作為產品展示的最基本方式。比起紙質的產品說明文檔，產品原型更能向用戶展示產品的創意。同時也能加深產品經理對產品的理解，避免開發團隊浪費時間和精力開發沒有把握的產品。
作者也花了很大的篇幅去介紹如何讓開展原型測試的方法。主要包括：
- 物色測試者
- 準備測試
- 測試環境
- 測試原型
- 更新原型
每個步驟書中都有很詳細的做法，感興趣的讀者可去原書中仔細研讀。
改進現有產品
改進產品不是一味的添加功能，不能只是功能加工廠，修補缺陷。改進產品不是簡單地滿足個別用戶的要求，也不能對用戶調查的結果照單全收。能提高指標的功能才是應該關注的重點。應該找準方向，分析關鍵指標，有針對性的改進產品。
平滑部署
避免更新產品導致用戶反感。毫無征兆地更新不必要的版本會令用戶產生反感。有件事情大家可能覺得不理解，但的確是事實。不是所有用戶都喜歡新版本的產品。我們從產品、開發者的角度出發，覺得新的產品在功能、體驗上都會好很多，所以我們會去主動更新我們手機里的App。但是，在普通用戶眼里可能會覺得更新App又要重新下載，又要占內存，好麻煩等等原因不愿意更新他們的App。有相當一部分用戶在用慣了一個產品后，不是那么喜歡變化。他們并不想改變已有的使用習慣。但是，我們不能因噎廢食，為了更好的為用戶完善產品功能，提供新的價值。我們還是要更新迭代我們的產品。但是一定要謹慎、理智的去迭代更新產品。
平滑部署有很多辦法，譬如并行發布兩個版本，邀請一部分內測用戶先試用新版本，如果新版本使用可以的話，再把新版本上線，同時保留一段時間的舊版本。還有可以先區域性的部署，然后再逐步擴大范圍。或者采取增量更新的形式。總之、不要輕易試探用戶的耐心，讓用戶的好感變成反感。
快速響應階段
產品出爐后切末虎頭蛇尾。發布產品并不等于大獲全勝，交付產品后依然要保持狀態。一方面是為了應對隨時出現的意外情況，確保上線以后的產品不會有致命的失誤。同時，此時正是手機用戶反饋信息，改進產品的好時機。要抓住這一時期的用戶反應，進行分析。這些對后面的產品迭代更新也是非常的有幫助。
合理運用敏捷方法
敏捷方法，我之前在一個很棒的技術團隊中參與過一段時間，感覺非常的高效。敏捷開發是一個適合高速迭代、小型開發團隊的一個工作流方法。殊不知在產品設計方面也可以采用敏捷的方法來開展工作。關于敏捷方法如何在產品方面使用書中也給了詳細的介紹。關于敏捷開發的相關文章，網上也有很多。大家可以去搜一下，敏捷相對來說是一個不錯的工作流模式。
合理運用瀑布式開發方法
瀑布流開發模式已經有很多年了，也有其他很多叫法，比如，持續改進方案，里程碑式開發方法等等。瀑布流有一定的缺點，如果是采取的這種開發方式，產品經理要學會揚長避短。
瀑布流式開發的基本準則是
- 采用階段式開發
軟件開發過程被事先分成固定的幾個階段；撰寫書面的需求文檔說明書、設計高層軟件架構、設計底層細節、編寫代碼、測試、部署。 - 采用階段式評審
每個階段結束后，對該階段提交的成果進行評審，評審通過后才能進入下一個階段。
瀑布式開發流程具有可預測性，比較受領導喜歡。因為是階段性的開發和審核，各種文檔，圖標都比較詳細。無論是客戶還是管理層都比較放心。所以這種模式才能這么多年還被很多團隊使用著。
但是，從產品經理的角度出發，瀑布式存在不少問題。
- 產品驗證嚴重滯后
- 變更計劃代價不菲
- 無法適應快速的市場變化，尤其是瞬息變化的當今互聯網時代。
創業型公司的產品管理
創業型公司的產品關鍵在于產品探索。創業意味著打造新的產品。目前流行的研發模式是：創業者想到一個好的點子，得到啟動資金后，馬上招聘程序員開發產品。由于創始人最清楚做什么，因此，他通常會扮演產品經理和產品設計師的角色，開發團隊則按照他的想法實現產品。這些創業公司一般在“秘密狀態”下運行，很少與用戶互動，另外由于產品需求和創意往往邊做邊變化，開發進度相對較慢。
通常需要半年左右的時間。創業型公司才能開發出可以內測的產品。這個版本往往漏洞百出，開發團隊不得不繼續修修補補。雖然開發團隊沒日沒夜的工作，但效果并不明顯——資金漸漸耗盡，產品依舊未能完成。除非天上掉餡餅，獲得額外的投資，否則成功的機會很渺茫。
——書中原文這段話真的是倒出了很多創業團隊的血淚教訓呀。
作者給出的另外的產品方法。初期只設三個職位：產品經理、交互設計師和原型開發人員。通過“高保真”的產品原型邀請真實的用戶去驗證。然后根據用戶的返回去迭代、修改產品的原型。待原型確定后，再招聘程序員進行開發。這樣可以節省很多資金和時間等，產品成功的機會會增加很多。真心是很有用，建議有想從事產品創業的朋友可以思考采取這種辦法。
大公司如何創新
作者給了一些建議，僅列出標題，詳細還需查看原書。
- 20%法則
- 臭鼬工程
- 主動觀察
- 改善用戶體驗
- 收購小公司
在大公司施展拳腳
這一章也是描述了一些在大公司工作注意的地方，也僅列出標題。
- 了解公司制定決策的方式
- 建立人脈網絡
- 臭鼬工程
- 自己頂上
- 有選擇的據理力爭
- 會前溝通，形成默契
- 合理分配時間
- 分享信息
- 向上司借力
- 傳播你的產品理念
附：標題、文中粗體字部分摘自《啟示錄-打造用戶喜愛的產品》，不作具體標注。
附：轉載請聯系作者。
