現在原來的產品經理保留，而我是聚效這款產品最主要的負責人，我干脆就去和這個團隊坐在一起了。
之前的問題在于我介入不夠。只要是希望做成產品驅動的公司，老板肯定要成為這個產品的主導者，只有老板才能把運營、業務、市場的方方面面考慮到，驅動公司內外的資源。
去年下半年我們啟動第三個產品“聚合”，挖來了小艾分析創始人武凱，他非常了解電商行業、數據挖掘，也了解這個產品的戰略意圖，是一個非常適合的產品經理。我也固化了產品流程：寫完MRD、PRD，做出DEMO版本，經過產品管理委員會的審核，開始實際操作后，每個星期要有周報，每個月要有整個產品的溝通會。
我們還設置了“產品管理委員會”，由包括銷售等部門的高管組成，產品經理拿著DEMO來演示，一旦通過大家審批，之后的進程中，產品經理、項目經理、負責產品銷售的業務經理三方共同推動，各部門的資源都要給出來。
而我的角色更像“助理產品經理”，一方面，我會琢磨客戶怎么去用它，和產品經理討論每個決策；另一方面是掌握平衡，廣告公司往往會因為有一位大客戶出現而更改原本的初衷。聚合這款產品希望做到版本統一，不為誰做定制化，所以我還要提醒產品經理，不要受到誘惑，要懂得哪些該投入，哪些該拒絕。
另外我還為產品經理配備了一位項目經理。有時候產品經理把產品作為創作，追求完美，時間總是會往后拖，所以我們的產品經理不斷地在做加法。而項目經理做減法，為了在某個時間點完成任務，叮囑他舍棄一些不必要的細節。
安全寶 保證質量
受誰影響：瑞星
分頭行動
口述：CEO馬杰(曾任瑞星公司研發總經理)
2000年我去瑞星的時候只是一個普通程序員，在我的極力倡導下，成立了第一個做用戶交互的小組。我的想法是，瑞星是一款消費類產品，一定要考慮到用戶的使用方面，所以我們把按鈕設計得越來越少，又創造出那個小獅子，那還是讓廣告公司設計的。
現在安全寶的架構很簡單，有些像瑞星后期：程序員是一大組，設計是一大組，基本上都是20人左右。我讓產品、開發他們兩邊互相合作，但是又互相監督。我來提需求，他們就負責把功能做完，然后產品那邊來把這個東西改改樣子。
其他互聯網公司傾向于快速響應、試錯、讓用戶來罵，我們做企業級產品，比較注重質量，流程控制比較嚴格。所以這個結構可以讓我們更好地保證質量，讓整個流轉速度盡可能地快。我們這兩組人倒是很有趣，產品組的同事很活潑，每當他們在那聊得熱火朝天，程序員那邊總是一片寂靜。
Facebook 產品組從無到有再到無
受誰影響：扎克伯格，硅谷工程師文化
口述：王淮(曾任Facebook工程師)
Facebook從150人增長到近3200人，從所有人可以做所有的事情，到慢慢演變出產品制度，原本最大的Company Value(企業價值)是Move fast and break things，后來覺得Break things有點夸張，只剩下Move fast。
承認錯誤、迅速試錯、迅速改錯，這是我們的一個核心競爭力。我們沒有受到Myspace的影響，但是遇到Twitter的時候走過一次彎路，花了大概半年時間糾正過來了，最后達成共識：不需要太在意這些公司在做什么，但是需要注意的是，最大的威脅在于那些我們現在還不知道的創業公司。它們做有創意的事兒，而且那些人做東西的速度、試錯的速度、改正的速度非常快，大公司反而會慢。
大家都知道，硅谷的工程師本身就很產品化，但是在2007年，Facebook專門設置了產品經理這個職位。工程師在想Idea有的時候會把自己繞進去，幾乎會立刻想到實施中的難點。之所以需要產品經理，是因為他們與我們的思考層次不同，想得可以稍微遠一些。其實這個職位也要懂技術，在新兵營里都會被訓練能夠解決簡單的Bug。
我的角色是工程師經理，我們的小團隊同時并行三四個項目，每個項目的負責人要么是工程師經理，要么是產品經理，就看自己是否對這個項目感興趣。我們在座位上花了很多思考，我和產品經理挨著坐在中間，可能左邊兩個工程師最近跟我混，右邊幾個先跟他混。
工程師這邊匯報到負責技術的副總裁那里，而產品經理和設計團隊都匯報到首席產品官。產品經理更懂公司產品的大格局，而我則需要承擔對工程師的管理任務。團隊一般不超過10人，因為硅谷那邊認為一個經理管理超過10個人的時候就會出現麻煩。有一點他主外、我主內的意思，雖然往上匯報的頭兒不一樣，但是我們是很難分割開的戰斗整體。
我剛到的時候，這種團隊很少很松散，工程師經理也就兩三個，我走的時候有800多個工程師，大概有五六十個工程師經理。一個個小團隊冒出來，說明可以繞著某一個小領域，不停有創新。Security的組開始只有我一個人發起，最多的時候九個人，最后只剩了兩個，原因是我們已經利用機制把那個問題Automatic (自動化)掉了，這是最期待的結果：如果有人偷東西會自動報警，你還要保安干嘛呢？
Facebook經常考慮戰略目標，公司每六個月會定一次短期目標，我們團隊是三個月定一次，只是沒有嚴格的完成指標。需要3-6個月完成的項目，我們通常把它打碎成小一點的，如果時間長，就很難去控制，而且你現在用來做這個決定所依賴的數據跟現實，三個月之后就不一樣了。快速迭代的前提是計劃夠短，你的計劃應當是做你能夠想象的、80%的可能對的東西。
涉及到實施，我們通常會把第一個月的目標定得比較死。在立項時，想好這件事最重要的三個特性。以付賬流程為例，首先是能夠把錢付掉，第二個是步驟越少越好，再然后是怎么適應各地的支付方式。最重要的一定要盡快盡早滿足。
項目與項目之間難免會接壤，會有些混亂。我一直覺得適當地混亂是非常有必要的。像我們組會跟其他組合作，哪些事情是我們組做，哪些是他們做，這是可以協商的，把各自的成果合并起來。Facebook的理念是盡可能地共享技術，與其大家各自玩自己的東西，還不如把力量集中起來，facebook也有工具組，我們也會共用Code Base(代碼庫)，如果你建一套，我也自己建一套，太浪費了。
這里還有一個特點：Facebook主動鼓勵員工換崗，如果一位哥們在我組里待了八九個月，我就開始考慮他是否會待膩了，甚至鼓勵他換到其他組。如果你主動往某個方面去蹭，Facebook會給你很多的機會，我自己原來是工程師，后來成了工程師經理。
推薦閱讀
>>>詳細閱讀
本文標題：創業公司產品制度大起底
地址：http://www.brh9h.cn/a/04/20120709/74312.html
網友點評
精彩導讀
科技快報
品牌展示