Marty Cagan是享有世界聲譽的產品管理專家，曾擔任網景副總裁、eBay產品管理及設計高級副總裁。本文是他回顧自己二十多年來從事軟件產品管理工作和經驗的總結，分享了探索產品的流程和方法。

產品開發(fā)寧缺勿濫​

有沒有見過這樣的情形？開發(fā)團隊剛剛完成手頭上的項目閑了下來，可產品經理一想到程序員們自在逍遙，就怎么也坐不住了。為了讓他們馬上開始新項目，產品經理沒日沒夜地制作新項目的產品需求文檔（PRD），以求速成。這樣的事情在產品團隊里時常上演，成為產品失敗的罪魁禍首。

開發(fā)團隊就像“嗷嗷待哺”的嬰兒，胃口特別大，卻分不清哪些該吃，哪些不該吃。只要產品需求文檔到位，不論產品好壞，他們就馬不停蹄地開始新一輪的產品開發(fā)。后果可想而知。

追根溯源，這種現象的產生是因為產品開發(fā)團隊里的程序員聘金不菲，公司不樂意看到他們閑著，只有“物盡其用”，才會讓公司覺得安心。可聰明反被聰明誤，這種短視的行為，給產品的失敗埋下了禍根。這種行為還會掩蓋開發(fā)團隊真正的價值。開發(fā)團隊被公司異化成生產代碼的機器，而不是共同探索、打造出成功產品的“戰(zhàn)友”。

只讓開發(fā)人員負責軟件的開發(fā)，明顯低估了他們的價值。正確的做法是先通過產品探索定義出基本產品，確定產品是有價值的、可用的、可行的，然后再交給程序員去開發(fā)。強迫開發(fā)團隊滿負荷工作的公司，顯然是管理理念出現了問題：代碼好不等于產品好。當然，這種現象和企業(yè)文化也脫不開關系。

不可否認，好的項目經理確實能保證產品的交付進度。但不能因此就盲目地讓項目管理在公司里唱主角。進度安排合理、資源得到了優(yōu)化配置不意味著產品就能取得成功。通常，我會建議項目經理在產品探索階段安靜地坐在“觀眾席”上，等到確信設計的產品值得開發(fā)了，再粉墨登場率領團隊開發(fā)產品。采取這套方案后，收效不錯。但如果產品探索階段，團隊里缺少能一統全局的主帥，這套方案就不適用了（在今后的文章中我再討論這種現象）。

如果開發(fā)團隊閑了下來，而新一輪產品探索還沒完成，該怎么辦？其實選擇很多。

讓開發(fā)團隊利用“余量（headroom）”完善軟件架構。
讓開發(fā)團隊著手修復產品缺陷，改善產品性能。
讓開發(fā)團隊參與產品探索活動。
產品經理給開發(fā)團隊預留一個月左右的任務。這樣即使手頭的項目卡了殼（比如原型測試中，用戶的反饋意見很糟糕），在想到新方案之前，你的開發(fā)團隊都有事可做。

開發(fā)團隊無事可做，還有可能是項目團隊里開發(fā)人員和產品經理及設計師的比例失衡造成的。如果開發(fā)人員過多，那么產品設計團隊永遠跟不上進度，開發(fā)團隊必然會“檔期”不滿。

要記住，產品經理的使命是確保團隊開發(fā)有價值的產品。讓開發(fā)團隊盲目開發(fā)未經驗證的產品，也是一種浪費。

產品探索計劃

為了不讓程序員閑著，產品經理把本該花在產品探索上的時間都花在了趕寫產品需求文檔上?？蛇@樣的產品探索毫無價值。時間再緊迫，也不能犧牲那些創(chuàng)造價值的關鍵步驟。而有些公司非常重視產品探索，卻沒有對這個過程做出合理的規(guī)劃，不能保證每天做的都是有用功，自然無法快速開發(fā)出基本產品。所以，寶貴的時間就這么白白浪費了。

產品探索規(guī)劃是否詳細，取決于公司的文化氛圍和產品探索人員的能力。很多公司（特別是大規(guī)模公司）中，團隊需要一個產品探索計劃，明確項目必須實現的內容、需要的資源，并給出粗略的進度安排。

我將列出常見產品探索計劃的組成部分。但這不是模板，不要照著里面的內容生搬硬套，做些不需要做的事情。我列舉的每個部分分別解決不同的問題，你可以根據你要解決的問題，選擇合適的探索計劃。作為產品經理，你要審查這個計劃并確保團隊按計劃執(zhí)行。

核心探索團隊：確認項目的產品經理、首席設計師和主程序員，并且確保這些人員在探索產品的過程中隨叫隨到。
探索擴展團隊：誰將給這個核心團隊提供支持？你是否需要視覺設計師？你需要原型設計師的協助嗎？需要可用性測試資源嗎？需要有特定開發(fā)經驗的開發(fā)人員嗎？需要QA團隊提供人手嗎？需要市場部的人員支持嗎？
關鍵參與人員：這個項目必須得到誰的批準（即誰擁有“否決權”）？此外，還可以寫上你認為能夠對這個項目發(fā)表獨到見解的聰明人名單。
客戶發(fā)展計劃：這個項目需不需要特約用戶？如果需要的話，誰是牽頭人？如果不需要的話，你會請哪些客戶（用戶）驗證你的產品理念？
主要風險：這個項目的主要風險有哪些？你將如何解決這些問題？
用戶研究工具：這個項目需不需要創(chuàng)建一些人物角色？需要做網站檢查和商業(yè)分析嗎？
用戶測試計劃：你打算如何讓實際用戶測試產品？初步測試計劃是什么？
產品戰(zhàn)略（愿景）：是否需要在制定項目細節(jié)之前，考慮項目所在領域的長期發(fā)展？
產品原則：產品的所在領域是否需要獨創(chuàng)一些產品原則？
支持文檔的程度：核心團隊需要在以下方面達成一致意見：在這個項目中，需要哪些額外文檔、需要做到什么程度，包括用戶故事、用例、測試計劃等。
制訂計劃只是產品開發(fā)中的一步，更重要的是保證產品探索確實是朝著滿足基本要求的產品方向努力。另外，將這兩步結合起來后，什么時候能真正開始構建產品也是關鍵。這個過程的監(jiān)督工作包括兩個部分。

首先，我認為，產品的負責人（如產品經理或首席用戶體驗師）需要對這項活動盡到監(jiān)督責任，他們積極的監(jiān)督會對定義產品起到積極的作用。這里要說明一點，這里的“監(jiān)督”指的是每周至少詢問一次產品探索團隊下面這些問題。

你這周與什么樣的客戶和用戶進行過比較有效的溝通？
你從你們的討論中了解到了什么？在你了解它們的過程中，有什么事情使你感到驚訝嗎？你有了什么新的見解？
你是否遇到了潛在關鍵點？【注：參見http://www.svpg.com/your-business-plan-is-wrong】
根據你所了解到的內容，下一次你會進行哪些新的嘗試？
開發(fā)人員最后一次評估產品設計和客戶反饋信息是什么時候？
開發(fā)人員在項目可行性和可能的解決方案上有什么意見和反饋？
用戶認可這種想法的價值嗎？如果不，那么為什么他們不認可？
目前原型最主要的可用性問題有哪些？你打算如何糾正這些問題？
從可行性的角度來講，開發(fā)人員最關心原型的哪些方面？針對這些問題，你有哪些應變措施？
最后，你認為在兩周之內完成一個滿足最低要求的產品的可能性有多大？如果有困難，那么團隊是應該繼續(xù)努力還是考慮開發(fā)其他產品？
其次，產品經理也有監(jiān)督其他事務的職責，比如在項目管理方面，需要確保產品探索計劃的實施情況，做好開發(fā)的一切準備工作。具體來講，這包括保證開發(fā)團隊有足夠的資源開展工作，明白項目時間限制及做好時間管理，確保開發(fā)者、產品管理者和設計者之間的良好溝通，根據計劃從整體上推動進度，以及確保項目中的時間都被有效利用。

項目經理的確可以督促大家完成項目，但要確保先確定基本產品，而不能僅寫些開發(fā)文檔。

不管怎樣實施計劃，如果公司很開明，允許你在探索產品上花時間，而不是僅僅撰寫需求文檔，那么我希望你不要浪費產品探索中的每一天。如果你已經花了很多工夫，但仍感覺到很難開發(fā)出好產品，你應該嘗試制訂產品探索計劃。

產品探索日記

[!--empirenews.page--]​

產品經理和設計師們放棄原有的線性、瀑布式的開發(fā)流程，轉而采用我倡導的這種更具迭代性、探索性的流程后，通常需要花一些時間才能適應它的快節(jié)奏，掌握產品探索的韻律。

這篇文章將再現產品探索的情景，讓大家了解其核心內容。

因為產品的開發(fā)過程涉及的因素太多（如產品類型、投入的精力等），做這樣的概括并不容易。我盡量使用比較典型和普遍的情景。為了覆蓋盡可能多的要點，我構思了以下情景。

第一周

周一

為了明確商業(yè)目標，我和項目的主要負責人一起進行了產品的機會評估與討論。
與項目的首席設計師及主程序員開第一次討論會，制訂出產品原則。
緊接著，我們進行了頭腦風暴，想到不少好點子。
與首席設計師一起創(chuàng)建第一輪關鍵人物角色。
周二

和首席設計師繼續(xù)優(yōu)化前一天完成的用戶角色，確定主要和次要角色；討論用戶使用產品的情景，并列出主要情景和次要情景。
與用戶研究員一起明確潛在特約客戶名單；通過電話聯系特約客戶，篩選候選人。
首席設計師根據討論結果快速創(chuàng)建產品原型。
周三

我、首席設計師以及主程序員一起檢查前一天完成的產品原型，看它是否符合我們最初模擬的幾個用戶情景。討論非常激烈，原型遠比我們設想的要復雜。
我們回顧之前提出的產品原則，再一次明確了重點，之后大幅簡化了產品原型。
周四

我、設計師和項目的主要負責人一起查看產品原型。這個原型還在初期，但是已經包含了三個最重要的使用場景。通過討論，我們意識到我們和項目負責人的想法有些脫節(jié)，因為雙方對用戶的理解不同。
繼續(xù)電話聯系目標客戶，確認6家公司成為我們的特約客戶。最棒的是，他們似乎對我們的產品將解決的問題有極大的興趣，因為他們的公司都還沒有找到好的解決辦法。如果我們的產品能夠解決這個問題，那么他們會非?？春梦覀兊漠a品。
周五

我們和主程序員一起評估修改后的原型。他對主要功能的可行性持謹慎樂觀的態(tài)度，并提出了兩個重要的問題。第一，其中一項功能的開發(fā)成本可能頗高，而且執(zhí)行速度很慢。他需要點時間研究這個問題。第二，他認為我們可以省去一些收集數據的工夫，因為我們需要的數據可以從數據庫提取。
咨詢有關法律人士，向他展示原型，確保模型沒有和法律相沖突的地方。他們認為其中一處需要進行詳細評測，檢查結果會在下周給出。
第二周

周一

早上，我、首席設計師以及項目負責人一起拜訪第一個客戶，請四位潛在用戶試用產品原型。這次測試收獲頗豐?？上г偷谋憩F與我們的期望還有很大的差距。我們發(fā)現自己此前對用戶的理解還很膚淺，項目負責人的理解也不完全正確?，F在我們對用戶的理解又進一了步，而且達成了基本的共識。
回到公司后，我們立刻討論如何修改原型。我們簡化了自以為重要的場景，修改了術語，去掉了那些根本不會被用到的高級功能。
周二

主程序員在研究完高風險的技術問題后，確定他之前的擔心是有道理的。他提出了新的可行方案，可以實現同樣的效果，而且開發(fā)難度更低。于是我們根據他的意見對原型進行了調整。另外，他確認了我們本來要收集的數據在數據庫中都能找到，這就進一步簡化了原型。
下午我們拜訪了另一位客戶，請三位用戶參與了測試。今天的情況比昨天要好很多。我們仍然不確定原型的交互設計是不是足夠好，但至少用戶能夠完成主要任務了。之前去掉高級功能的這一步棋確實走對了，因為用戶并不關心它們。我很高興我們堅持了以客戶為中心的價值觀。有兩位測試用戶希望我們第一時間通知他們產品完成的消息。
周三

與首席設計師、主程序員碰頭，討論目前的成果和接下來的工作。主程序員又提出了一項針對關鍵流程的優(yōu)化建議，恰好解決了首席設計師面臨的幾個棘手的問題。
我和首席設計師向視覺設計師提出了我們對視覺設計的幾點想法。經過先前的用戶測試，我們認為必須將產品中的兩個基本概念用某種方式清晰地傳達給用戶，并且給出了關鍵狀態(tài)和用戶可能做出的動作。視覺設計師說她已經有了可以表達這些概念、提升產品價值的想法。她會在接下來的一兩天內給我們一些具體的方案，之后我們可以為這些方案提建議。
周四

我們仍然在努力定義基本產品。我們相信已經把最關鍵的功能都涵蓋在內了，但不確定到底要不要再加上一個比較酷的功能，不知道它是不是必需的。我們計劃暫時從模型中刪除這個功能，看看測試的效果如何。
下午，我們拜訪了另一位客戶，請三位用戶測試了產品原型。原型的可用性已經很棒了，但刪除了之前說的那個功能后，原型沒有得到用戶的熱烈響應。我們又展示了之前的版本，這次他們表現出了極大熱情。我們得出的結論是，這個功能確實非常重要。我們的原型中已經盡可能地刪掉了所有不需要的部分，但仍然能激發(fā)人們的購買欲望。我們去除了很多高級的功能，簡化了關鍵流程，應該能在主程序員估計的時間內完成開發(fā)任務。
周五

我、首席設計師與可視化設計師一起討論了她設計的方案，我們特別喜歡其中的一個方案。稍做調整后，我們把它用在了原型上。
主程序員根據現有（也可能是最終）的原型估計出了產品開發(fā)的周期。這個時間可以接受，并且有風險的技術問題已經排除。
第三周

周一

我們將包含最新的產品原型展示給項目負責人，并且總結了最終的產品設計（包括最新的界面設計），以及所有來自測試客戶的反饋。她很喜歡這個產品，希望旁觀下午的測試。她也想就價格和定位詢問客戶的意見。
下午，我、首席設計師以及項目負責人帶著最終原型去見另一位客戶。我們請4~5位用戶進行了測試，得到了理想的反饋——沒有遇到使用問題，對功能和價值的反響也很好。所有用戶都很期待這款產品的問世，也愿意推薦給朋友或者同事使用。
周二

繼續(xù)完善原型，并將這些天來了解到的關鍵點錄入項目維基。
向給更多的項目參與人展示了產品原型，包括法律顧問、市場部、產品管理和工程方面的副總。他們提出了一些問題，但都認可用戶測試的反饋。
周三

我、首席設計師以及主程序員碰頭，討論如何撰寫產品文檔，方便開發(fā)人員、測試人員、部署人員開展工作。
我和首席設計師分工撰寫文檔，我們將各自負責的部分寫到項目維基里，并添加了一些對產品原型的鏈接和注釋。
看完以上日記，希望你能明確以下10點。

在項目開始時，確定你對目標有清晰的理解（產品機會評估）。
從產品探索最開始時就建立和首席設計師、主程序員的密切合作。
注重真正的協作交流，而不僅僅滿足于寫那些沒人看的文檔。
迅速將關鍵的產品理念融入到原型的制作中。
設法驗證自己對產品的假設，不要紙上談兵，盡快判斷哪些假設正確，哪些不正確。
盡早反復地將產品原型提供給目標客戶測試，及早發(fā)現問題。
記住要確定基本產品。
產品探索的目標：確定產品是有價值的、可用的、可行的。
在產品探索的過程中不斷保持和相關部門的信息互通，向大家展示不斷更新的產品原型，讓他們了解進度。
不要把時間花在為開發(fā)人員寫文檔上，等到產品確定后再寫。
當然了，實際項目不一定完全與我的描述相同，我希望傳達這樣一種觀念：在把產品理念展示給真正的用戶之前，不應該花兩周時間撰寫產品文檔，更不能花三周時間制作初期產品原型。

產品探索有特定的節(jié)奏和規(guī)律，它以構思產品設計、原型制作、用戶測試，以及最重要的一點，反復學習為基礎。如果你還沒有親身體驗過探索產品的過程，那么我希望這篇文章可以讓你大致了解產品探索是什么，以及它與直接開始撰寫產品文檔的做法的區(qū)別。

Marty Cagan，作為負責定義和開發(fā)產品的高級經理人為多家一流企業(yè)工作過，親歷了個人電腦、互聯網、電子商務的起落沉浮，致力于通過寫作、演講、培訓幫助客戶打造富有創(chuàng)意的產品。