本文編譯自First Round Review，他們準備的文章既講故事，同時還向創業者提供可操作的建議，以助力打造優秀的公司。這篇文章為我們介紹了流媒體音樂服務 Pandora 廣告產品主管 Jack Krawczyk 的團隊管理法則。原文篇幅較長，將分段刊載。
Jack Krawczyk 曾就職於 StumbleUpon 和 Google，有著豐富的工作經驗。2013 年 Krawczyk 加入網路電台服務公司 Pandora，負責廣告產品團隊的管理。他的工作不僅是要推出聽眾認可的智慧廣告產品，還需要帶領團隊快速地成長。
Krawczyk 認為，領導一支產品管理團隊首先做到以身作則。他在接手後立即投入到產品一線，參與到 Pandora 廣告嵌入邏輯的重構。他說：「這個過程不僅讓我更好地理解了產品如何運作，也讓我認識到 Pandora 整個開發環節是怎樣的。」
Krawczyk 曾見證過許多創意演變成為真實的產品，也遇到過不少難見天日的失敗品。他的團隊經常能拿出創意十足的解決方案，但也有不少項目以失敗告終。在這些經驗的基礎上，Krawczyk 總結出 6 條具體的策略，幫助產品主管開發優秀的產品並培養傑出的產品經理。
- 第一，了解團隊的鄧巴係數
上世紀 90 年代，英國人類學家羅賓·鄧巴提出一個理論：由於人類平均腦容量所導致的認知局限，一般人只能與 150 人維持穩定的社會關係。Krawczyk 在管理中也運用這一理論，使每個人不需要處理與太多人的關係，確保同事之間交流的廣泛而深入。
Krawczyk 說：「我認為每個好的產品經理本質上都是領導者，只是沒人向你直接匯報。但是產品經理必須激勵那些並不算自己下屬的工程師，同時還要滿足公司其它利益相關方的需求。」
管理產品經理的人則必須成為領導的領導，並且深入理解公司內部業務關係架構。以下是負責一支快速成長的產品管理團隊時需要注意的幾個關鍵點：
·工程師搞好關係，讓他們不僅知道該做什麼，還知道為什麼要這樣做
Krawczyk 說：「對於早期團隊來說，工程師和產品經理數量的黃金比例通常是 5:1。這個比例有利於產品經理和工程師保持足夠親密的關係，也讓產品經理知道如何與工程師交流，如何激勵他們，如何帶來最大的產出。」
隨著團隊擴大，職能會變得更加分散。這時，PM 和工程師之間的數量比就沒那麼重要了，取而代之的是雙方關係的緊密程度。工程師不僅需要知道工作是什麼，還要理解每個產品功能背後的決策過程。對於一支交叉職能的團隊來說，了解一項工作的前因後果非常重要。Krawczyk 說：「如果產品經理能夠清晰表達出需要做的工作及其原因，那麼他們最終就有可能會開發出驚豔的產品。」
·5 塊美金決策體系：小團隊需要更緊密的聯繫
Krawczyk 建議，當一個產品團隊在 10 人以下時，應該充分利用這種小規模的優勢，盡可能讓所有人聚在一起，開工作計劃會議時可以邀請工程師和設計師也參與進來。在 Pandora，這種方式不僅增進了同事之間的關係，也讓產品經理在會後能對各方面情況有更加全面的了解。
在 Pandora 早年，前 CTO 兼執行副總 Tom Conrad 為所有參與 Pandora 產品開發的員工建立了一套「美元決策體系」(dollar-decision-making system)。每次季度會議上，來自公司各部門的參會者將討論 Pandora 最重要的產品和創新點。為了確保員工的參與度，並對工作的優先級進行排序，每個參會者都會收到 5「美元」，用於投資他們認為最關鍵的領域。儘管錢很少，但這種形式卻促使人們仔細權衡自己手中的籌碼。
對於很多團隊不大的創業公司來說，這個方法都非常有效。儘管 Pandora 現在人數不斷增多，但依然在使用這套「美元決策體系」，只不過是在各個產品團隊內部，比如廣告產品團隊用「美元決策」的方式來製定產品發展的路線圖。歸根到底，還是要加強團隊內部各個部門的充分交流和溝通，推動公司的不斷成長。
·大團隊需要重視流程
Krawczyk 說：「我遇到的最大挑戰之一，就是如何保持 Pandora 早期形成的合作機制，同時又不斷調整，適應不斷成長起來的專業化團隊。」在 Pandora 人數不到 500 時，我們可以把所有負責產品的人召集到一起開會。但現在，公司有超過 1600 名員工，包括 25 個產品經理和主管，如果還用老辦法只會導致混亂，有些話題被重複討論，有時候部分參會者與會議內容毫不相干。
當你不得不為產品會議準備更大的會議室時，你就需要關注到決策流程了。
2013 年 Krawczyk 加入 Pandora 時，只有 3 名 PM 負責廣告產品。短短兩年，PM 的數量已經增加到了 12 人，其中既有產品管理的新手，也有具備十幾年經驗的老將，和他們一起工作的工程師還有 55 位。這些人都在 Krawczyk 的管理之下。
在產品經理數量接近兩位數時，為了保持隊伍的緊密聯繫和高效率，Krawczyk 建立了一套「產品組經理」(group product manager) 匯報製度，將 12 個產品經理分成 3 個功能組，覆蓋到廣告產品的各個方面：聽眾廣告體驗、廣告分發技術、廣告購買體驗。每個組設置一名產品組經理，每組中有 4 名 PM，每個產品都有專人負責。
這個結構使得團隊行動更快，每次開會的內容更有針對性，將來 PM 團隊進一步擴大也不用擔心。Krawczyk 說：「如果有很多人向你直接匯報，那你就沒法對某一項具體事務做到深入理解，交流效果也會大打折扣。而且在這種工作方式下，作為管理者的你總會為工作增加障礙。你工作本應是為大家消除障礙的，而不是增加它們。」
- 第二，把所有工作落實到文字——然後進行分類
Krawczyk 說：「把想法組織成語言，再形成文字，然後根據文字進行討論並不是一件容易堅持的事情。很多人認為把想法寫下來是重複性的工作，即使寫也是草草記錄一下。這種觀念實際上是錯誤的，團隊的人越多，就越要做好文字工作。」
Krawczyk 之所以得出這樣的結論，是因為有時候他發現在開完每週例會之後，產品經理、工程師、營銷人員和執行團隊看起來對會議所作決定的理解完全不同。在隨後和員工的交流中他發現人們的觀點確實存在偏差。
如果每次開完會是這樣的結果，那集中在一間屋子裡開會還有什麼意義？想要解決這個問題，團隊管理者就必須經常與員工交流，確保他們對於手頭工作的理解是統一、清晰的。
在某次無果的會議之後，Krawczyk 團隊中一位產品經理想出一個辦法：把相關信息提煉出來整理成一個分類文檔。
有一天，Krawczyk 團隊中的一位產品經理注意到，開會討論時，一邊是工程師拿著他們的產品需求文檔（Product Requirement Document, PRD）在陳述觀點，談論的都是各種預測和用戶故事；而另一邊，營銷團隊則在解釋他們自己的策劃案。雙方的信息是不對稱的。為了彌合這種斷層，這位 PM 決定把 PRD 中與營銷有關的信息摘錄出來，單獨形成一份文檔，保留原有形式，方便查找原文。通過這種方式，他給出了一份對雙方來說都有用且比較熟悉的文檔。
Krawczyk 發現了這一方法，於是就把它運用到了整個團隊中。他說：「要想成為一名強大的產品主管，關鍵並不在於你自己能提出多少想法，而在於傾聽團隊的聲音，發現最優的工作方式，並決定如何將其運用到整個團隊中。 」經過一段時間的發展，現在 Krawczyk 的團隊主要利用 4 種類型的文檔來保持團隊中信息對稱（按照從基礎性到拓展性的順序）：
·執行總結 (Executive Summary)：關於產品團隊在做什麼的一份總結性、概括性的文檔。是對產品的高度概述，讓人們能夠以最快速度了解產品。
·Wiki 頁面 (Wiki Pages)：由各個產品部門編寫，在內網流通，居於核心地位，是對每個具體領域的高度概括，包括工程進度以及要實現的里程碑。Wiki 頁面有每個分支部門 的工作進度圖以及按季度劃分的時間線。
·產品需求文檔（Product Requirements Documents）：一份全面的產品規劃文檔，包括產品標準，產品特性，用戶案例研究等。是一站式、細緻的產品計劃。
·發布計劃文檔 (Lauch Plan Document)：一份包括所有執行計劃的綜合性文檔，用來協調產品、銷售、營銷和開發等各個團隊之間的工作。這是兩年多以前由於 Pandora 團隊規模擴大而新增的文檔。
Pandora 的 Wiki 頁面模板
在這 4 類文檔中，Krawczyk 特別強調了 wiki 頁面對於團隊的重要性。產品經理可以通過 wiki 頁面說明自己的工作內容，設定季度目標，其它人也可以通過這些頁面來了解產品的發展歷程。那麼，一個高效的 wiki 頁面應該如何完成呢？以下是一些實用的原則：
透明性和可見性。wiki 這個詞本身指的是「由用戶群共同維護、允許所有用戶添加或修改內容的網站或數據庫」，基於這個特性，我們的 wiki 頁面是由大家合作完成的，公司內所有人可見。在每季度和管理層進行的業務總結會議上，我們就可以通過 wiki 頁面清晰地看到我們的團隊做了哪些工作。
簡明的總結和清晰的表達。「每個 wiki 都鏈接到一份執行總結，讓所有的參與者能夠實時能保持信息對等。」此外，PM 還需要簡單說明他們正在做的工作，以及做這項工作的原因，在和領導、同事或者顧客交流的時候可以快速引用，非常有幫助。
季度目標的設定。「我們不會具體到這個季度要做的每件事。因為在公司快速發展過程中隨時會有變化，比如某個季度可能新招來二三十位新成員。因此，我會建議產品經理逐步把這一季度中所有的測試、項目里程碑或者新產品上線寫出來。當然，產品開發週期常常超過 3 個月，通過 wiki 的方式可以促使 PM 把大項目切分成小的版塊和階段。」
明確定義下一步要做什麼以及不做什麼。「在每組的 wiki 上，會有產品發展規劃，列出了即將開發和發布的所有產品功能。同時我們也要求寫出不准備開發什麼。這樣可以在將來避免模棱兩可，導致開發出一些本不想開發的功能。」
如果說文檔對於產品經理可以用「關鍵」來形容，那麼對於產品經理的領導來說，文檔就是「不可或缺」的。
Krawczyk 把自己看做整個產品團隊的產品經理，這個團隊就是他在開發的產品。「不論是說明公司的價值主張 (value proposition) 還是我對產品的修改意見，我都需要向團隊解釋我的理由，讓 PM 理解決策過程非常重要，這樣，他們才能在充分了解各方面信息後完成艱難的工作。因此，這些文檔對我非常有用。」
- 第三，做好團隊溝通的組織者
作為產品經理，你需要清楚別人是否真正理解了你們所達成一致的內容。你不僅要讓大家完全理解該做什麼，還要讓他們知道所做的事情與最終目標有著怎樣的關係。
當 Krawczyk 和一位產品經理意見不一時，他會先質疑是不是自己的理解出了問題。他說：「我發現很多時候我不同意某個方案是因為我對於問題本身的理解不夠清楚。這時，我會向 PM 坦言我可能理解不到位。但是如果我認為我沒有錯，是 PM 提的方案不合適，那我會進一步分析，消除 PM 對於我所做決定的疑慮，最終達成一致。整個討論的注意力都是放在問題本身，而不針對這個人。」
然而，如果團隊還是不理解你，那就是你的錯了。你是團隊交流過程的組織者，你需要確保大家在某些問題上達成一致的，也可以選擇一些問題讓大家各自保留意見。
尋求最適合團隊溝通的方式，確保每個人都能理解關鍵信息。「人們在提產品需求時常常只說『我要你做這個。』實際上，接下來非常重要的一步就是說明為什麼要首先做這些。」
幾個月以前有一次，Krawczyk 在一個部門的 wiki 頁面提出了一些新的要求，但是這個部門的產品經理看起來很困惑。於是他又進一步做出了解釋，說明了之所以提出這些要求的完整背景。他說：「說明做出某個規定的原因比反復強調新規定的內容要容易得多，在大家充分理解之後，我們就能行動得更快。」
網路新創公司蓬勃發展，政府也期待透過創業促進產業轉型，但開公司不能單靠熱血和創意！創業者與企業管理者需要知道的 Know-How，實則都與「法務和財務」相連，管理也是一門專業，趕緊來練財法務基本功！
★ 報名前 20 位學員，將贈送勤業眾信出版《創業時代》一書
坊間買不到的好書，要搶要快喔！
[kktix]kktix.com/tickets_widget?slug=financial-and-legal1030[/kktix]
- 延伸閱讀
想升職卻差臨門一腳？不同位置你該換不同腦袋！
新創公司財務總體檢：5 個簡單小測驗，看看你是不是燒錢燒太兇？
別讓法律成為財務黑洞，創業家律師教你 3 招
（本文轉載自合作夥伴《36Kr》、《36Kr》2；圖片來源：tec_estromberg，CC Licensed；未經授權，不得轉載）
