好的產品經理和差的產品經理（好的團隊和差的團隊）

轉自《用戶故事地圖》Marty Cagan序 http://www.tup.tsinghua.edu.cn/booksCenter/preface.html?id=06102901

原做者：Ben Horowitz（本·霍羅威茨）

原文叫<好的產品經理和差的產品經理>我的感受這篇文章叫<好的團隊和差的團隊>更好。

===華麗的分割線，如下是正文。=====================================================

好的團隊，有引人入勝的產品願景，懷着傳教士般的熱忱在工做。差的團隊，像是由僱傭兵組成的，當一天和尚撞一天鐘，靠混的。

好的團隊，從關鍵業務指標獲得啓發，經過觀察用戶的痛點和分析用戶使用過程當中產生的數據，不斷嘗試新技術解決現實問題。差的團隊，從銷售人員和用戶那裏收集需求。

好的團隊，理解誰是主要干係人，干係人所受的約束，承諾引入解決方案，方案對用戶和客戶有用，同時也知足業務上的約束條件。差的團隊，只知道從干係人那裏收集需求。

好的團隊，掌握大量的技術手段，這些技術手段能夠快速驗證哪些產品創意是值得開發的。差的團隊，召集會議來制定路標和排列優先級。

好的團隊，喜歡和公司內有想法的主管展開頭腦風暴和討論產品。差的團隊，在團隊以外的人膽敢提議他們作任何事的時候，會以爲本身受到了冒犯。

好的團隊，產品經理、交互設計師和開發工程師坐在一塊兒，對功能、用戶體驗、技術可行性達成一致看法。差的團隊，各自坐在小格子間裏，沒有文檔和會議安排，就不會主動響應其餘人的請求。

好的團隊，持續嘗試新想法以求創新，過程當中會注意保護公司利益和品牌。差的團隊，仍然坐着等待開始嘗試的指令。

好的團隊，對於創造出成功產品所需的技能頗有信心，好比強大的交互設計能力。差的團隊，甚至壓根兒就不知道交互設計爲什麼物。

好的團隊，保證開發工程師天天有時間參與產品原型的討論，爲作好產品獻計獻策。差的團隊，在迭代計劃會上展現原型，一心只爲了估出工做量。

好的團隊，每週直接和用戶交流，以更好地理解用戶訴求，並試探用戶對最新的產品創意的反饋。差的團隊，覺得他們本身就能表明用戶。

好的團隊，清楚地知道盡管他們很喜歡本身在產品上的創意，但這些創意中的很大一部分用戶並不見得會接受，即便有一些被用戶接受了，也須要通過多個迭代的打磨才能達到預期的效果。差的團隊，只開發路標上規劃的內容，能按時交付，只求不出重大質量問題就阿彌陀佛。

好的團隊，理解速度和快速迭代對於產品創新的價值，更知道速度來自於正確的方法，而非強制加班。差的團隊，抱怨同事工做不夠努力，速度太慢。

好的團隊，在評估方案，確承認行並對用戶和業務有實際價值後，共同作出承諾。差的團隊，抱怨本身公司是一個受銷售驅動的公司。

好的團隊，使用工具，以便快速瞭解用戶是如何使用產品的，並基於數據作出判斷。差的團隊，認爲統計分析是無關緊要的。

好的團隊，持續集成和發佈產品，由於他們知道持續的小發布能爲用戶提供了穩定可靠的解決方案。差的團隊，在通過痛苦的集成聯調以後，手工測試，一次性發布全部功能。

好的團隊，專一於用戶。差的團隊，專一於競品。

好的團隊，在關鍵業務目標重大影響達成後慶祝。差的團隊，在終於發佈產品以後慶祝。