創業公司產品制度大起底 產品先拆分後組合

來源:互聯網
上載者:User

仲介交易 SEO診斷 淘寶客 雲主機 技術大廳

  

這些「小嘍囉」需要向騰訊、Facebook等產品巨頭學習什麼?

文 | 曲琳

自從微信為騰訊打下又一局漂亮仗,騰訊副總裁、騰訊廣州研發部總經理張小龍就成為了國內IT圈的紅人。 前段時間他在「知乎」上回答了問題「什麼是好的使用者體驗?」 被不少同行轉載。 其實,「產品經理」早已是知乎上人氣最高的話題之一,從這個「職位」橫空出世開始,關於產品經理的經驗分享就從未停止過。

在公認技術門檻越來越低的今天,想讓產品脫穎而出,無疑是越來越難了。 新產品總會遇到同質化競爭,於是互聯網創業者將目光聚焦在一位位明星產品經理的身上。 這些人貌似手持金鑰匙。

但我們想討論的問題是產品制度,即通過怎樣的架構、流程來進行產品驅動與執行,或對產品經理等產品負責人進行督導。

在《創業邦》針對「產品制度」的調查中,絕大部分創業者都提到,從羽量級小團隊,過渡到需要建立明確產品線、增加產品數量、增加團隊人員、進行專業化細分的時候,總有那麼一個時間點(甚至是很長一段時間),會糾結于產品制度的問題:

究竟怎樣的產品機制才適合自己的團隊?

CEO本人是否應當是產品經理?與產品負責人如何打配合?

建立產品制度是否要輔以公司文化的傳承?

Facebook、谷歌等跨國巨頭的產品制度是否是過於理想化的?

擁有無數產品經理的騰訊,在制度上有哪點可以借鑒?

......

這是個因公司而異的話題,幾乎每一家都在探索中,幾乎每一家都走過自己的彎路。 因此,我們尋訪了一些創業者,其中有些曾任職于互聯網大公司,成為它們產品制度中的一枚棋子;有些是產品經理出身,創業之後卻堅決不設置產品經理職位。

從他們各自的產品制度中,我們可以歸納出以下幾個切入點:

是將新專案設置為專案組,其中包括設計師、工程師、產品負責人,五臟俱全,還是以職能部門來劃分,每個新產品都由整個團隊流水線作戰,這是個很基礎的問題。 很多公司會以此辟出一些「公共資源」,例如共用的設計師團隊,共用的「代碼庫」或一些研發成果,可以做到一次開發,一勞永逸。

不同業務公司會使用不同的制度方式,但前提是對產品的切割能力。 大公司如Facebook,看起來是一個整體產品,其實是將其拆分為各個小功能,每個功能的切分、更新也被作為新產品,重新進行部署。 這些小更新、大功能是很容易接壤的,而CEO需要面對的挑戰是,清楚地瞭解這些產品的界限,以及整盤棋的部署與變化。

移動時代到來,移動端的開發成為標配,單獨做「移動」小組,還是把移動端的任務拆開分配下去?很多創業公司都曾經或正在面對這個疑問。

為什麼要設置產品制度?三個最主要的目的是,根據「敏捷開發」(一種強調切分專案達到快速反覆運算的開發方法)的指導思想,使產品快速反覆運算;提高產品驅動力,使每個位置上的同事都能驅動創新;產品先拆分後組合,讓整個產品更立體化, 業務更有聯繫。

豌豆莢 技術與設計雙驅動

受誰影響:谷歌,Facebook 特點:專案組形式,變「產品經理」為「產品設計師」

口述:聯合創始人王俊煜(曾任谷歌中國前端工程師)

谷歌的產品制度中,專案的主要驅動者是工程師,但是谷歌與Facebook的工程師文化還不一樣。 Facebook的工程師思維蠻產品化的,使用者需要這個事情,如果有這個技術就去實施;谷歌工程師是技術能達到就去做,即使專案看上去不是特別靠譜。 金融危機之前谷歌全球有各種奇怪的專案,類似無人駕駛汽車,2008年以後開始砍掉一些,但是還會有新的冒出來。

谷歌的每個專案組有不同的搭配,大家的角色不像國內公司那樣分明,我就曾被帶到不同的專案,不停地輪換,兼任各種角色。 只有工程師是流動性不強的,他們是專案真正的主心骨。

對於豌豆莢來說,核心競爭原則是「做得好不好用」,所以我希望創新驅動不僅來自技術,也要來自設計。 這種情況下,兩者的界限就很模糊了,所以我們乾脆就把這兩者的職責合併到同一個人身上:產品設計師。 目前公司有六七個產品設計師,他們有一定的設計背景,還有比較好的產品決策能力。

每個專案的主要負責人並不是指派的,而是自然而然形成的。 有些專案,類似于改進手機跟電腦之間連接的成功率,產品設計師幫不上太多忙,自然會有一個工程師來負責;有些功能例如照片同步,是從產品設計的角度去考慮的,產品設計師會更擅長來帶隊。 我們沒有設產品經理,是因為不希望有「經理」這個會被看做是高人一等的Title。

產品制度這個事情對我們蠻重要的,不僅是對產品的分工,還涉及整個公司的結構。 我們想做一個設計與技術結合的公司,這種情況下就需要一個制度上的保證。 制度慢慢推行之後,大概一個季度能有多達二十幾個的新專案發佈,其中有五六個比較大的專案。 平時我會負責斃掉一些新專案,或者歸到另外的組去。

我們不希望分工太細,把每個人都框在自己的範圍裡面,之外的事情就不能碰。 為什麼大家的招聘會那麼嚴格?你招的不是這個人的體力,而是他的腦力。 你可以把不同的人腦想像成不同的CPU,需要調度這些CPU來完成指定的工作,如果你限制了他的腦力發揮,他就喪失了自己獨立判斷的能力,對整體的生產力來說是個損害。

但是,這個制度的前提是保證透明度。 例如我們按照媒介來分成幾條產品線,PC端、安卓端、伺服器端等,經常會有一些產品需要三個媒介一起來做。 公司越來越大,資訊不對稱也會比較嚴重,我的任務是,讓大家明白我們的主線是什麼,在想Idea的時候不要太發散,提高內部合作的效率。

例如,有一個專案組現在嘗試在牆上貼一大堆卡片,來告訴所有同事專案進度;我們每週會有一個全體大會,回答大家提的各種問題;設計團隊每週會做兩次設計討論,看公司其他不同的產品,貢獻關於設計方面的意見。 我們的郵件也用得蠻猛的,以後可能會嘗試用一下週報。

另外,我們不想成為谷歌、騰訊這種多產品的公司,更想成為Facebook或者說Twitter這種產品主線很明確的公司。 以前我們的每一個專案都叫「豌豆莢xxx」,也有子品牌,如「豌豆莢手機精靈」、「豌豆莢守護精靈」,去年我們把後面的這一塊兒去掉了,都叫「豌豆莢」,對使用者是簡化,對公司內部也是簡化,希望大家不要覺得自己在做一個獨立的產品。 #p#副標題#e#

今夜酒店特價 為了快速反覆運算

受誰影響:新蛋,Facebook 特點:職能部形式,前後台迅速聯動

口述:CEO鄧天卓(曾任新蛋美國商業分析師、資料運營產品經理)

我們的第一版產品上線非常快,一個月搞定,那段時間是想到一個功能就立刻上,所有人都撲過去。

後來很快發現問題:酒店後面的定單執行是非常複雜的系統,需要在短時間內構建一套完整的電商體系,結果系統只能支撐上10家酒店,一下子上了100家,使用者一打開超級慢,所有酒店都出不來。

我覺得創業公司在小規模的時候,做任何事都可以非常快,但是會犯無數的錯誤。 沒有好的架構,也沒有好的分工,一旦業務上有任何變化,系統都跟不上,而且根本不知道問題在哪裡。 這是一個痛苦的階段,所有事情都是緊急的,永遠都在打補丁。 在我理解,任何性能問題都是架構問題,想提升性能就要全部推翻。 我們索性踩刹車,業務我寧可不推了,把只用一個月時間搞定的第一版的所有錯誤,用4個月補了回來。

將前臺邏輯挪到後臺的時候,我們第一次意識到產品團隊需要細分。 所以目前我們是這樣的架構:

軟體部分被稱作「產品實施部」,幾大塊的負責人都是產品經理:安卓、iOS、WP7、WAP這4個系統由兩個產品經理負責;另一個產品經理負責所有後臺CMS系統,相當於進銷存系統,它能決定公司的軟體能力;一個產品經理負責使用者研究 ;最後兩位分別負責交互設計和UI設計。 每一個部門都可以驅動新專案,另外有一個領導來負責協調他們、控制產品節奏,相當於專案經理。

這套架構是一個保證執行力,保證整體效率的捷徑,是我們摸索8個月的結果。 橫向按照功能或者實施路徑來分,縱向按照前臺、後臺來分。 制度的核心目標是快速反覆運算,而且每次更新都要讓使用者看出來。 現在互聯網行業對反覆運算的要求太高了,你三個月前用微博的玩法和現在一樣嗎?人們對於一成不變的東西已經很少有依賴感了。 做互聯網應用應當像拍美劇,為什麼最快也要每週更新一集呢?因為每播出去一集就要儘快做調研,在下一集把需要的元素補進來。

另外我們把要銷售的酒店也作為產品,稱為「商業產品組」。 我的工作相當於連接商業產品和軟體產品,產品制度已經走得很順了,基本上我現在要什麼東西,兩周以後一定能拿到,任何決策後面都連著一串變化,但是新想法的驅動點又很多,於是壓力又轉移到決策這裡。

所以,這套體系還需要有—套價值觀,什麼專案是公司最應該集中力量去做的,要做優先排序。 我們的標準是:可以提高轉化率的是第一位,修理App上的Bug(漏洞)是第二位,再往後是提升使用者的決策和效率、提升我們的運營效率、減少人力的投入、縮減成本等。 專案的主要決策人是那位專案經理,其實這一套制度是在他的主導下建立的,他是我原來在新蛋的老闆。 新蛋的產品制度非常複雜,流程非常長,我每個星期要開20多個專案會,但是速度非常快,專案在一個月裡就能完成。

這個制度還有一個好處:不容易被挖走。 實際上,我的產品經理不是一個人,而是一個組織,別人挖我的人都沒有用,你挖了我一個,我立刻培養出一個一樣的。 我認為所謂「全能產品經理」都是偽命題。 我想這套體系未來還會變化,也許下個月的此時又得進行微調了。

下廚房 避免官僚化

受誰影響:豆瓣

特點:不設產品經理,直接分工

口述:CEO王旭升(曾任豆瓣產品經理)

「下廚房」是一個小團隊,並沒有設置產品經理這個崗位。 如果負責技術、運營、前端的工程師各有一些對產品的新想法,我們要評估一下是否值得,學習成本不高我們就自己摸索,如果學不了,也許去外面招人,也許請一些兼職或者顧問。

其實這相當於把其他公司產品經理的職能拆分到每個人身上,忘記Title,直接去想要做什麼事。

我一直以來的觀點就是不要產品經理。 這個職位在國內會引發一些爭議,尤其是在一些大公司裡面,產品經理聽起來像是一種權力,可以決定做什麼或者不做什麼,如果設崗設得不對,很容易形成辦公室政治。

為什麼那麼多人很嚮往去豆瓣做產品經理?因為豆瓣整個團隊的產品意識非常好,很少聽到「彙報」兩個字,經常跨層級溝通。 豆瓣的產品經理比較開放,任何運營和技術都能參與到裡面,學到的東西很多,技術人員也會教你怎麼從資料裡看到一些產品層面的問題。 而作為產品經理,你要說服的是一群非常有智慧、對產品非常有想法的技術人員,挑戰很大,而且他們是善意的,基本上也不會介意你的Title。

亞馬遜 人少好辦事、資源分享

口述:林承仁(無覓網創始人,曾任亞馬遜美國工程師)

亞馬遜每一個團隊的制度都不一樣,不過人數都有限制,少到兩個人就能形成一個組,美術設計師、UI設計師等是共用資源。 經理只負責管理和流程式控制制,產品可能是產品經理或者一個團隊領袖來負責。 我當時處於個人化團隊,下面有三四個小組,我們經常針對點上推薦做一些新的演算法,亞馬遜鼓勵我們申請專利,有律師直接幫忙去遞交專利。

亞馬遜做產品的思想也是敏捷開發,還有一個理念是雲服務。 亞馬遜內部也是雲服務的,我們擁有的一些功能放在雲上,其他團隊可以直接調用,相當於提供一個介面。 資源重用的概率就可以高很多。 但是中國一些大公司不是這麼做的,我猜想可能是因為人力便宜吧。 #p#副標題#e#

聚勝萬合

為了推出更「互聯網」化的產品

受誰影響:好耶

特點:制度因產品而異,CEO等同于或無限接近于產品負責人

口述:CEO楊炯緯(曾任好耶總裁)

大部分廣告公司都是以服務來驅動的,使用者要什麼就賣什麼,但是我們希望能夠以技術、產品來帶動發展。 我的產品經驗都是東聽一耳朵、西聽一耳朵,自己吃苦頭後得來的。

第一款產品相當於原來好耶廣告系統的延續。 開發過程相對來說是比較野蠻的。 開始沒有產品經理,後來招了一個,我以為這個職位是負責介面設計的,第一件事就是讓他把之前程式師設計的難看介面換掉。

開發第二款產品「聚效」的時候,我瞭解產品經理的職責了,就把任務全權交給他,但是在產品出來時,和我想的不太一樣。 他在專案進度把控上很不錯,但是他沒有做過網路廣告。 我們當時也沒寫MRD(市場需求文檔),因為開發團隊都組建完畢了,迫在眉睫,就跳過MRD直接做PRD(產品需求文檔),可是PRD這種東西又很難看懂,最後造成他的認知跟我有偏差。 不能怪他,我做了10多年的網路廣告,我都不清楚的事兒他怎麼可能清楚?

現在原來的產品經理保留,而我是聚效這款產品最主要的負責人,我乾脆就去和這個團隊坐在一起了。

之前的問題在於我介入不夠。 只要是希望做成產品驅動的公司,老闆肯定要成為這個產品的主導者,只有老闆才能把運營、業務、市場的方方面面考慮到,驅動公司內外的資源。

去年下半年我們啟動第三個產品「聚合」,挖來了小艾分析創始人武凱,他非常瞭解電商行業、資料採礦,也瞭解這個產品的戰略意圖,是一個非常適合的產品經理。 我也固化了產品流程:寫完MRD、PRD,做出DEMO版本,經過產品管理委員會的審核,開始實際操作後,每個星期要有週報,每個月要有整個產品的溝通會。

我們還設置了「產品管理委員會」,由包括銷售等部門的高管組成,產品經理拿著DEMO來演示,一旦通過大家審批,之後的進程中,產品經理、專案經理、負責產品銷售的業務經理三方共同推動,各部門的資源都要給出來。

而我的角色更像「助理產品經理」,一方面,我會琢磨客戶怎麼去用它,和產品經理討論每個決策;另一方面是掌握平衡,廣告公司往往會因為有一位大客戶出現而更改原本的初衷。 聚合這款產品希望做到版本統一,不為誰做定制化,所以我還要提醒產品經理,不要受到誘惑,要懂得哪些該投入,哪些該拒絕。

另外我還為產品經理配備了一位專案經理。 有時候產品經理把產品作為創作,追求完美,時間總是會往後拖,所以我們的產品經理不斷地在做加法。 而專案經理做減法,為了在某個時間點完成任務,叮囑他捨棄一些不必要的細節。

安全寶 保證品質

受誰影響:瑞星

分頭行動

口述:CEO馬傑(曾任瑞星公司研發總經理)

2000年我去瑞星的時候只是一個普通程式師,在我的極力宣導下,成立了第一個做使用者交互的小組。 我的想法是,瑞星是一款消費類產品,一定要考慮到使用者的使用方面,所以我們把按鈕設計得越來越少,又創造出那個小獅子,那還是讓廣告公司設計的。

現在安全寶的架構很簡單,有些像瑞星後期:程式師是一大組,設計是一大組,基本上都是20人左右。 我讓產品、開發他們兩邊互相合作,但是又互相監督。 我來提需求,他們就負責把功能做完,然後產品那邊來把這個東西改改樣子。

其他互聯網公司傾向于快速回應、試錯、讓使用者來罵,我們做企業級產品,比較注重品質,流程式控制制比較嚴格。 所以這個結構可以讓我們更好地保證品質,讓整個流轉速度盡可能地快。 我們這兩組人倒是很有趣,產品組的同事很活潑,每當他們在那聊得熱火朝天,程式師那邊總是一片寂靜。 #p#副標題#e#

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會給你很多的機會,我自己原來是工程師,後來成了工程師經理。

回國之後,我幫中國的公司梳理過產品思路。 百姓網的王建碩(微博)是這麼多朋友聊下來,感覺是最容易接受矽谷模式的一位CEO了,他一直跟矽谷的步伐邁得比較近,每隔一段時間都會跑過去交流。

但是,有很多做法,中國與外國公司是很不同的。

如果你去和中國的CEO聊,再找產品經理聊,會發現他們對產品的理解並不一樣,這讓我覺得很奇怪。 產品經理跟工程師的協調也不行,很多的時候不知道對方在幹什麼。

創始人對公司整體的戰略規劃也會有些欠缺,如果不列出未來三個月的計畫,公司可能一直在救火狀態。 我鼓勵大家建立資訊的Vision(遠景),排好先後次序,按照時間推進。

中國工程師在整體理念上畢竟不如矽谷工程師,有時候太重視KPI,只為了完成某個指標。 在我看來,Facebook很少有冰冷的數位指標。

還有一個麻煩的問題。 中國公司更希望考慮商業化發展,那麼究竟你的創新是來自商業的需求,還是出自工程師、產品經理的角度?在中國創過一段業的人,幾乎都更想考慮如何賺錢這個問題。 這就讓大家不敢做冒險的生意。 蘋果之所以能夠起死回生,最開始是因為iPod,但是讓它飛黃騰達的是iPhone,這些東西在原來的蘋果是無法想像的,因為原來的蘋果已經屬於一個維持的狀態。 我覺得公司應當有20%的精力花在一些創新的、有爭議的產品上,它也許可以把你的公司帶入到另外一個很不一樣的狀態。

在幫百姓網整理思路之後,我希望我的一些矽谷思路可以給他們啟發。 王健碩有一句話讓我很開心,他說Facebook的做法我絕對不會照搬。 很高興聽他這麼說。 中國團隊到底能不能效仿Facebook這樣的產品制度,或者說能學到多少,我不清楚,這也許和中外互聯網環境有關。

口述:騰訊某高級產品經理

騰訊組織架構是矩陣型的。 矩陣的意思是,產品、開發、設計、運營都分屬在一個大的部門,橫向的是專案,可能是一個產品帶著5個開發,再帶著設計等人員,就是跨部門之間組成一個專案團隊。

新產品一般還是產品部門驅動,企業發展部、一些戰略調研的部門也會出一些研究和介紹,使用者研究崗位會做一些使用者報告。 一個團隊可能會由這三個人主導:產品經理,沒准還會有一個專案經理,以及一位技術部門的領導。 專案經理這個職位也會負責多個團隊間協調資源。

騰訊的成功,是不是得益于這套產品制度?我覺得不能完全這麼看,創業公司當使用者變到10萬的時候,你可能有適合你的制度和框架,到100萬的時候,你又有一個制度和框架。 騰訊的方法也許只適合騰訊自己。

但是騰訊之所以產品做得好,有一種產品文化在這兒:我經常會在上班的時候,被我們的高級執行副總裁,就是負責戰略層面的一個人物叫過去,問為什麼產品這個細節是個按鈕而不是一個連結?在騰訊,你的產品體驗會被任何人挑戰。

當然這是因為Pony(馬化騰)本人就是重要的產品體驗師。 公司風格應該是和公司老大相關的,比如馬雲很喜歡考慮市場,阿裡巴巴員工就喜愛討論戰略。

再舉個例子,大部分公司的程式師都很討厭需求變更。 我們有一個課程就是叫「動態運營」,會灌輸給工程師,做到60%的時候應該看一看使用者回饋,告訴他需要再繼續改進優化,程式師就明白這個邏輯了。

很多人提到騰訊的內部競爭,其實大家有些誤讀了,我覺得在內部,同樣產品之間的競爭並不多。 所有產品經理都是在一個部門,之間經常互動交流。 有時候你我做同樣的事情,如果我做得不太好我就換其他的。 我反而覺得淘寶的文化和我們不一樣,我和他們的人也經常聊,他們真的是幾個團隊做一樣的事兒。 這也是文化的不同,騰訊是希望大家都很儒雅;淘寶是說我跟你打一仗,直接競爭。

我們還有一個專門的部門做很多共用工具,把一些資源變成公用平臺,例如你看一些產品最後過去都是通向一個庫裡面的。

但是騰訊做產品的人確實是不少,我也覺得後續階段騰訊在人員擴張的步伐會放緩。 騰訊的產品經理非常多,我還真不知道數位,如果員工有2萬人,可能百分之十幾都是產品經理。 有這麼多人,內部會有一些順理成章去做一些擴張的業務,原來內部會覺得我偏要跟你做一個一樣的,現在大家會反思,是不是有些事情我確實不要做,而是讓產業鏈上下游的其他人做才是對的。 #p#副標題#e#

問卷

1.請用一句話形容創業公司構建自己「產品制度」(即公司通過怎樣的架構、流程來進行產品驅動與執行)的重要性。

生命線。 ——張銳

讓創業的激情不再磨滅在無止境的內耗中。 ——鄧天卓

This is the heart of what we do.——王俊煜

像一味中藥:先放什麼、後放什麼其實挺不同的,而且不同的人也不能用一樣的藥。 ——黃修源

不僅能使產品想法實現,還能在時間上獲得先機。 ——顧志誠

產產品制度是公司的「生產關係」,重要性不言而喻。 ——陳琪

2.是否對國內互聯網三大巨頭,騰訊、阿裡巴巴、百度的產品制度感興趣?為什麼?

調查結論:七成人認為不感興趣,頂多對騰訊的制度表示好奇。

目前不感興趣。 大公司的制度臃腫和累贅,不適合小團隊。 ——李江峰

不太感興趣。 巨頭之所以為巨頭,核心的不一定是產品制度,而是戰略和管理,我對後者更感興趣。 ——王旭升

對騰訊的感興趣:大體制下的小團隊和持續創新。 ——鄧天卓

感興趣,希望瞭解如何高效管理非常多條的並行產品線,並完成各產品之間的互通及重合度。 ——顧志誠

3.是否希望挖來國內互聯網三大巨頭的產品經理?為什麼?

多數人表示無所謂,但是對於騰訊的產品經理比較歡迎。

目前不希望。 產品自身不很複雜的時候,對產品的決策往往跟公司的決策聯繫在一起,不是普通產品經理能勝任的。 ——李江峰

可以來,不渴望。 大公司是流水線作業式的產品流程,職責、許可權有限。 ——張銳

會優先考慮,希望借此更系統和客觀地瞭解中國線民的全貌,或靠人脈與大公司建立合作。 ——王旭升

4.是否對Facebook、谷歌、亞馬遜等國際巨頭的產品制度感興趣?為什麼?

調查結論:多數人表示感興趣。

都感興趣。 如何保障創新的持續性,自己革自己的命。 ——鄧天卓

感興趣,希望瞭解國內外互聯網巨頭在產品管理方面的異同點。 ——顧志誠

5.你在招聘產品經理(or產品核心負責人)時有何條件?

真正喜歡所做的事,而不是只求一份工作;有具備跟自己的設想相呼應的技能或學習能力。 ——李江峰

能夠深入地發現和理解使用者的問題,並明白技術的可能性,給出簡單而優雅的解決方案。 ——王俊煜

思維和自己比較一致,既能夠把控大方向,又關注小細節。 ——黃修源

愛產品,愛嘗試各種產品,對產品有敏感的「觸覺」。 ——林承仁

6.請用一句話描述你與你的產品經理(or產品核心負責人)的關係。

我聽他的。 ——張銳

眼和手。 ——天卓

我與我自己。 ——王旭升

產品經理就是決策權受限的CEO。 ——陳琪

7.在你看來,產品經理出來創業的優勢或劣勢在哪裡?

優勢是能快速讓產品成為核心驅動力,考慮問題的方式更理性、更有節奏感和方向感。 劣勢是固執于以往產品經驗,眼界局限的話會閉門造車。 ——李江峰

優勢是大公司中的產品經理是最接近CEO 的角色,其他人搞不定的可以來補上。 劣勢是難以形成專業領域的積累,僅靠直覺還不行。 ——王俊煜

優勢是分寸感強。 劣勢是創業早期這傢伙幾乎不輸出生產力,尤其是「中國式」產品經理(不會寫代碼、也不會畫圖)。 ——王旭升

優勢是更容易在初創期快速推出產品原型到市場上檢驗,並快速修正。 劣勢是,一旦度過初創期,就需要惡補產品之外的綜合能力。 ——陳琪

8.關於創業公司如何做產品,或者如何構建自己的產品制度,可否推薦一些閱讀材料?如書籍、博客等(請絞盡腦汁無私分享)。

Allen Cooper相關的交互設計的書。

《Don't make me think》:講產品設計中的基本使用者體驗。

《Facebook效應》:對facebook初期創業時的重大產品決策有詳盡的描述。

《定位》:經典的行銷學著作,產品從一開始就需要在市場中尋找自己的定位。

《Lean startup》:關於產品點子如何變成成熟產品的考慮點,非常棒。

幾位推薦人各自的博客——定期分享好內容。

9.是否會刻意採取一些管理措施,留住公司的產品經理(or其他產品負責人)?為什麼?

更大的自主權,但要在符合公司發展戰略的前提下。 ——李江峰

用期權!——張銳

足夠的榮譽感和成就感,鼓勵多和外界溝通,並代表公司做宣傳。 ——鄧天卓

會,但是不會特意。 反正我們是全員持股的。

——林承仁

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.