Marty Cagan是享有世界聲譽的產品管理專家，曾經擔任網景副總裁、eBay產品管理及設計高級副總裁。本文是他回顧自己二十多年來從事軟件產品管理工作的總結和經驗分享，描述了產品開發需要遵循的產品原則以及成立產品評審團的必要性。

產品原則

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

每次加入新團隊，我要做的第一件事都是制定產品原則。這意味著要決定什么重要、什么不重要，哪些原則是根本的、戰略性的，哪些是臨時的、戰術性的。

產品原則不是產品功能的清單，不依賴于任何單獨的產品，而是整個產品線的戰略指南和公司的價值宣言。好的產品原則還可以激發設計產品的靈感。制定產品原則的過程也是學習的過程，可以從中了解新公司的企業文化，以及公司創始人設立的企業目標。產品原則是一套價值判斷的框架，幫助公司作出正確的決策。

舉例來說，某電影網站的產品原則是相信社區用戶的影評比專業人士的影評更有價值。當某家制片廠想借網站發表評論時，產品團隊就可以根據這條產品原則決定是否采納。產品原則是否公開因公司而異。它既可以用做團隊內部的指導工具，如產品戰略文檔，也可以公開給客戶、合作伙伴、投資人，用于向公眾宣傳公司的理念。此外，產品原則還可以用來團結產品團隊，讓產品經理、產品設計師、開發團隊和營銷團隊形成共同的價值觀，在認識上保持一致。這是任何產品說明文檔都做不到的。注意，只羅列出產品原則還不夠，還要按原則的重要性排序。所有產品都要既易于使用又安全可靠，但總有需要優先考慮的原則。最重要的究竟是易用性，還是可靠性？

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

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

解決意見沖突

不少產品經理向我抱怨，他們受夠了沒完沒了的會議（既無議程也無結果），以及會議中的那些爭論和沖突。公司高管還時不時打斷會議進程，扔下沒頭沒腦的意見，拂袖而去，留下他們丈二和尚摸不著頭腦。

這種情況在產品決策過程中經常發生，原因主要有以下幾點。

•每位同事對產品都有自己的看法。
•大家都非常在乎產品，明白公司盈利得靠用戶，只有產品才能吸引用戶。
•許多人以為自己比其他人了解目標用戶，事實上并非如此。
另外，產品團隊大多不必向產品經理匯報工作，產品經理沒有管理產品團隊的實權。在需要產品團隊的配合時，產品經理只能擺事實、講道理，不能強制執行。所以產品經理總覺得施展不開拳腳，非常沮喪。

有時大家各持己見，僵持不下，只能請高管出面定奪。出現這種局面，說明溝通方式有問題。產品創意在辯論中可以得到完善，但前提是大家形成一致意見。請高管出面決策、解決沖突會激化團隊內部矛盾，得不償失。

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

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

•究竟要解決什么問題？
•要為哪類人物角色解決這個問題？
•產品要達到什么目標？
•每項目標的優先級是什么？
在我看來，每當團隊內出現嚴重的意見分歧時，并非是大家對事實的認定有爭議，而是對目標和目標的優先級有不同的理解。

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

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

我常被請去解決產品決策中出現的爭議，發現多數團隊跳過了這關鍵的一步。由于缺少基本評估標準，每個人對目標和優先級的理解都不同，大家往往情緒激動，在細枝末節上爭執不下。

即使大家已經達成共識，也應該在討論開始前再次予以強調，最好把目標按優先級順序寫在白板上，這樣每位同事都可以看到評估方案和制定決策的確切依據。

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

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

制定更及時、更可靠的產品決策

即使對小公司來說，制定決策通常也是既耗時又費力的。產品公司需要一套機制讓決策者和相關人員及時作出明智的產品決策。我認為成立產品評審團是最好的解決途徑。

我通常不熱衷于出席會議或參加各種委員會，但產品評審團除外。產品評審團讓所有決策者坐到一起，為把產品推向市場共同制定決策，可以有效地加快研發產品的速度。

組織產品評審團的難點在于既要為高管制定產品決策、監督產品流程提供透明的信息，又要避免高管干預產品團隊的具體工作，如參與產品設計。不少公司都有類似的組織，但我認為最早提出這個概念的人是eBay前COO Maynard Webb。多年來，我一直在實踐中不斷規范產品評審團的具體職責，完善其流程。

產品評審團的工作目標

成立產品評審團的目的是決定產品戰略方向，從宏觀上監督公司產品的研發流程，合理配置資源。產品評審團不制定公司的商業戰略，而是在給定商業戰略的條件下，提出與之相匹配的產品戰略。產品評審團的決策直接影響企業的運營。

產品評審團的成員組成

產品評審團由公司各個部門的管理者組成。雖然各個公司的情況不同，但通常都包括以下人員。

•首席執行官/首席運營官/部門總經理
•產品管理總監/副總監
•用戶體驗設計總監/副總監
•市場總監/副總監
•開發總監/副總監
•網站運營總監/副總監
•客戶服務總監/副總監
產品評審團的工作效果很大程度上取決于會議組織者的技巧。他必須不受干擾，善于闡明問題、促成決策。大公司里，組織者通常由公司的產品負責人擔任；小公司里，則由老板擔任。要確保每個關鍵部門都有代表參加產品評審團，但最好把人數控制在十人以內。如果有的部門不止一人參加評審團，應該選一個人代表部門陳述觀點。例如，銷售總裁代表市場部發言，質檢（QA）主管代表開發部門發言。

產品評審團的職責

產品評審團并不是設計和開發產品的團隊，它的職責是監督產品研發流程，制定關鍵決策。

它根據研發產品的四個里程碑來評審產品，制定決策。

1. 評審產品戰略和產品路線圖，啟動評估產品機會的工作，即選擇值得投入精力的產品，請產品經理開始評估產品機會。

2. 根據評估產品機會的結果，決定是否開始定義產品的解決方案。

3. 評審產品原型、用戶測試結果、成本估算明細，決定是否開始開發產品。

4. 評審最終產品、產品品質、發布計劃、社會效應，決定是否發布產品。

注意事項

•小公司的產品評審團通常負責評審公司所有的產品；大公司可能需要根據業務單位的大小，設立若干個產品評審團。
•產品評審團不負責評審對產品細節的更新或修正。這是為了加快對細節問題的處理，保證公司業務運作流暢。
•產品評審團不負責具體的產品設計工作。如果產品存在缺陷，應該由產品團隊著手處理，然后重新提交產品評審團評審。
•在2號里程碑處，由于產品解決方案尚未形成，不可憑直覺估算產品的成本，至多只能估計大致的項目規模；但在3號里程碑處，應該仔細估算開發時間和成本，讓公司上下做好準備。
•盡量避免產品評審團討論具體執行策略，討論這些問題非常耗費時間。如果必須討論，則一定要控制好時間，不要影響產品評審團監督產品流程的主要工作。
•產品評審團開會頻率取決于具體產品的進度，可以每月開一小時會議或者每周開兩小時會議。
•產品評審團還應該回顧、分析產品上市后的表現?？梢栽诋a品發布3~6個月后，請產品團隊匯報產品的市場業績表現，產品評審團可以反思之前的決策是否明智，今后應該如何調整。
•每次評審會議，最好由產品經理向產品評審團匯報產品的進展情況。由產品經理的直接領導指導產品經理準備陳述內容，確保產品經理準備充分。在會議召開前，產品經理最好逐一向產品評審團成員做簡要匯報，存在疑問應及時解決，避免在匯報過程中措手不及。
如果公司制定產品決策的效率太低，應考慮組織產品評審團。它可以替代以往各種冗長的決策會議，大大縮短決策時間，制定明智、及時、透明的產品決策。

何時估算項目成本

盡管軟件行業早就有估算成本的傳統，但直到今天仍然容易出現混亂的估算結果。我認為混亂的原因在于管理層總是希望盡早獲悉成本信息，但開發人員往往要較晚才能精確估算成本（至少要等到具體的解決方案出爐）。結果，要么過早估算導致結果與實際出入很大，要么結果雖然準確，但遠遠超出預算，讓管理層難以接受。

這里要介紹的估算方式雖然源自我提倡的產品研發流程，但同樣能解決大多數公司的問題。

開始研發產品前，應該先評估產品機會。評估產品機會的目的是看產品創意宣稱要解決的問題是否有價值。此時，解決方案尚未出爐，手頭僅有產品創意和待解決的問題，所以產品團隊只能先大致估算項目的規模（建議分成小型、中型、大型三個等級），再根據項目規模粗略估算項目成本。雖然這種估算與實際情況會有出入，但通常不會出現跨級別的誤差。

確認產品機會有價值，粗略估算的成本也可以接受，管理層才能允許項目組著手定義產品解決方案。理想情況下，詳細的產品解決方案還應該包含可供用戶測試的高保真原型。

在定義解決方案的過程中，首先產品經理和交互設計師需要一位開發人員的協助來評估不同解決方案的成本。然后產品經理和交互設計師根據評估結果進一步調整解決方案。待完整的產品說明文檔形成后，即可根據文檔細節生成詳細、可靠的成本估算結果。

此時，手頭有了詳細的產品說明文檔、可信的成本估算結果，管理層可以很方便地決定是否開始開發產品。如果解決方案有問題或成本估算結果超出了預算，管理層可以馬上叫停。如果決定開發產品，產品團隊就可以在充分了解產品定義與成本細節的條件下全力開始工作。

總而言之，我建議分兩個階段進行成本估算。在評估產品機會時做粗略估算，根據最終的產品說明文檔做詳細估算。