Reddit產品副總裁：如何打造一個持久高效的產品開發系統？
微信搜索“36氪”,獲取更多高質量內容.點擊進入36氪
Alex Le和Kavin Stewart目前是Reiddt的聯席產品副總裁。他們倆其實在8年前就認識了，當時分別是兩家有競爭關係的社交遊戲公司的創始人，不過他們並沒有劍拔弩張、針鋒相對，而是為了能共同生存而相互取經。Alex擅長設計，Kavin則擅長增加產品營收和用户增長。後來他們分別加入了其它公司負責產品方面的工作，但始終保持着聯繫。最終，他們都加入了Reddit，並共同擔任公司的聯席產品副總裁。
第一次聽説聯席產品副總裁，你可能會覺得這樣的職位設置並不是一個好主意，因為這樣的職位設置在合作的過程中可能會遇到很多問題，但對Alex和Kavin來説這並不是問題。為什麼這麼説呢？因為他們在公司的各個發展階段都有打造產品的豐富經驗，他們親自見證過很多成功、也遭遇過很多失敗；他們知道產品線何時該擴張、何時需要做出改變、打破重來，他們也見識過太多足以毀掉一款產品的致命錯誤。
近日，他倆接受了First Round Review的獨家專訪，主要分享了創業公司如何順利地從產品市場匹配階段過渡到增長階段，很多非常有前景的創業公司都在這上面栽了跟頭。他們分享了很多建議策略，不管你現在的公司處於哪一個發展階段，你都能借鑑他們的方法來學會如何打造一個高效、可複製且持久的產品開發系統。
跨越鴻溝
有一種東西叫創業公司青春期，這個青春期階段就是產品開始變得越來越受歡迎的階段。正如青春期一樣，這種轉變常常會讓人猝不及防。當然，他們之前可能預料過這個階段會到來，但這並不意味着他們已經為此做好了準備。
對於產品而言，主要有以下兩個方面的改變：
- 你已經不再是你自己產品的用户了：矽谷的創業者有這樣一個共同點，他們剛開始創業的時候想要解決的是自己遇到的實際問題。在創業最早期，你開發的產品的目標用户是與你自己類似的人或是你非常熟悉的人羣。一旦到了產品市場匹配階段之後，便會有很多新用户成為你的目標用户，這時你自己的需求已經無法代表你所有的用户的需求和想法了。
- 你將有機會去展開更多的測試：在你有了足夠多的用户或客户後，你將能夠根據用户行為來調整和優化產品。
隨着用户的新需求越來越多，你開始需要招聘越來越多的人，公司運營也會變得越來越複雜。為了獲得後續成功，你需要對你的產品和工程師團隊進行模塊化設計，這樣一來，你就能對要解決的問題進行分類，然後將不同的問題分配給相應模塊的團隊獨立快速解決。隨着公司日益壯大，所有團隊都能實現自主領導、並肩衝刺。如果你能夠早點將這種模塊化團隊機制嵌入到企業文化中，公司後期的快速擴張就會變得更加容易。
你必須要非常清楚地知道公司目前處於哪一個發展階段，這樣才能在相應的階段採用合適的流程。理想情況下，打造一個在公司發展過程中可以進行優化的流程，而不是每達到一個新階段都要將流程徹底打破、重新構造。
雖然Reddit是一家非常成熟的公司了，但和創業公司一樣，它也會遇到同樣的過渡轉折問題。舉個例子：Reddit最近正在開發移動App，關於App的功能和設計方面的想法全來自於團隊成員，畢竟他們是Reddit最為忠實的用户。
我們也知道，隨着獲取的用户越來越多，肯定會遇到很多剛剛接觸Reddit或是與我們的想法觀點不一樣的用户。有一個道理我們始終銘記：那些讓我們成功到達此地的東西是無法幫我們實現下一個成功的。
為了弄清楚App究竟需要上哪些功能，我們確實需要好好做功課，這和早期創業公司所經歷的那種絞盡腦汁的痛苦一樣。“我們不能僅僅將用户反饋的需求和問題直接轉給產品和技術人員，讓他們去解決。相反，我們需要我們的團隊不僅開發那些扔給他們的需求功能，同時也要主動探究那些我們沒有獲得的問題反饋，並想清楚哪些功能可以解決這些問題。”
他們在這個過程中採用的流程管理方法叫做“假設驅動型產品管理方法”。根據這套管理方法，產品經理已經不能停留在“我認為用户想要這個功能”上了。相反，產品經理需要這樣問自己：“你預測這項功能將會產生什麼影響？”
在A輪融資之前，你往往沒有足夠的數據讓你這麼做。在種子輪融資階段，你的公司本身就是你的一個假設。你將公司展示給全世界，只是為了想看看你關於公司的假設是否成立。隨着公司的發展，你會做出更多假設，那就是公司該往哪個方向走。確定了發展方向後，你會繼續假設該為產品添加哪些功能。這種不斷做出科學假設的能力將會讓你的產品被越來越多的用户所接受和喜愛。
在Alex和Kavin看來，隨着公司的發展，在產品開發方面將發生三個重大變化：如何產生想法？如何執行這些想法，將想法變成現實？如何對想法進行迭代？他們在下面分享了創業公司在這三個方面實現飛躍的最佳方式。
找到全新的頭腦風暴方式
你需要構建一個進行假設的體系，即使公司日後發展壯大了，這個體系依然可以作為未來產生功能假設想法的基礎。
將你希望達成的目標列成一個清單，例如你想要達成的指標、你想要看到的用户活躍度和用户增長數據。然後再根據數據和調研去猜測怎麼做才能實現這些目標。
如果你的公司還處於非常早期的階段，沒有足夠多的數據讓你去做定量分析，那麼你可以從在用户調研和測試中獲得的定性反饋開始做起。不過你所構建的假設體系不能僅僅依賴你自己已有的觀點與經驗，你需要往這個體系中注入一些新東西，做競品分析就是方式之一。你的競爭對手實現了你想實現的類似目標嗎？他們是如何實現這個目標的？你怎樣借鑑和迭代對方的做法，從而比對方做得更好？
除了競品分析外，另外一個在假設體系中注入新想法的方式就是與那些你希望成為你目標用户的人羣溝通，了解這些人目前使用的與你的產品類似的產品都有哪些、他們為什麼使用這些產品、以及他們可能不會使用你的產品的原因。不管怎麼説，你需要利用好手頭的已有資源，從與用户交流中獲得定性反饋要比什麼都沒有強得多。
產品管理主要有三個方面的內容：針對目標清單開展頭腦風暴、為目標清單確定優先級、執行目標清單。其中，細節決定成敗。
如果你頭腦風暴出來的清單是有問題的，那麼接下來的整個方向就會出問題。你想創新，這當然沒問題，不過首先要確保創新的方向是正確的。
在產品方面的創新應該是一個非常機械的過程。在有些人看來，頭腦風暴就好似坐在山頂上的時候突然被一道閃電擊中時感覺，其實並非如此。在我看來，在頭腦風暴的過程中，將“產生想法”和“評估想法”這兩個階段區分開來至關重要。我自己展開頭腦風暴的時候是這樣做的：首先將自己頭腦中浮現出的任何一個想法都先記錄下來，不管這些想法聽起來有多愚蠢，然後再對這些想法進行逐一分析與評估。
利用你在用户測試和調研過程中獲得的反饋以及從其它渠道獲得的信息，對最初的想法清單進行過濾和精簡，篩選出真正靠譜的好想法。利用下面這兩個要素對清單裏的想法進行優先級排序：
- 這個想法對達成目標有多重要？
- 這個想法的成功機率有多大？
只要回答了這兩個問題，你就能知道清單上的哪些想法的優先級比較高，然後再去執行這些想法，這能讓你更容易達成目標。在小團隊裏，這項工作可以集中統一開展。隨着公司規模的壯大和產品功能組合越來越分散，這時可以由各個團隊來各自獨立運行這個系統，將想法推進到下一個階段。
圖中人物為Alex Le
讓模塊化執行達到最佳狀態
頭腦風暴結束後，通常都會產生多個新的想法。在小創業公司裏，每個人都知道團隊裏的其他同事在負責什麼工作，這是小創業公司的一個優勢。在驗證了產品市場相匹配之後，創業公司的這個優勢就會逐漸喪失，這時你就需要花心思為不同的團隊分配工作任務，讓這些團隊在沒有人領導（尤其是沒有創始人的領導）的情況下也能獨立完成各項工作。
我親眼見證過很多創業公司都走到了這個階段，通常都是公司CEO或新招聘的產品主管負責為不同的員工團隊分配任務，這並不是一個好方式，最好的方式是讓員工都能負責各自最擅長的工作領域，並且有足夠的自由去進行創新與測試。
下面是一些常見的工作領域：
- 核心產品：我們如何讓產品變得更好？
- 註冊體驗：如何讓更多的人註冊使用我們的產品：
- 內部工具：如何優化公司內部使用的各項工具？
- 內容：我們應該向用户展示哪些內容？如何展示？
- 社區：如何建立起自己的用户社區？
- 渠道：在核心產品之外，我們通過哪些渠道與用户互動？如何互動？
- 盈利方式：如何獲得盈利，確保公司能生存下去？
我發現很多團隊都按照技術領域來劃分團隊，如前端網頁開發團隊。我認為這並不是一個劃分團隊的好方法，我建議按照宏觀產品而非單純的技術來劃分團隊。例如，關注產品所有平台的內容建設，關注如何在各個平台上提高用户轉化率。
從按技術劃分團隊轉變到圍繞目標來劃分團隊是非常困難的，因為之前形成的種種習慣是難以改變的。要完成這種轉變，就需要從公司高層開始做起。CEO需要主動放棄一定的控制權，不能對什麼工作都要親自參與和決策，要學會放權。根據Kavin和Alex的親身經歷，一旦創始人或CEO做到了適當的放權，那麼完成這種團隊劃分方式的轉變就會容易得多。
如何確定什麼時候需要進行這種轉變呢？
- CEO或聯合創始人已經無法掌握公司的所有工作，對產品每天的進展也不了解。
- 你試圖擴張自己的產品，這就需要你花更多的時間和精力去了解用户。
- 公司現有員工負責產品太多不同領域的工作，經常需要轉換工作場景，導致工作效率嚴重下降。
一旦你意識到了這種需要之後，你可以利用下面的方式來實施轉變：
- 為每一個主題領域的工作都任命一位商業負責人，負責驅動KPI和與高層的溝通。這樣的負責人通常是產品經理。
- 儘可能減少跨團隊依賴性。
- 制定運營目標，並將每個人的OKR都與這個目標綁定，讓每一個人的工作都更有目的性，也能更好地評估大家的表現。
- 持續重新評估現有體系的瓶頸在哪裏，並快速解決這個問題。
一旦你圍繞主題組建團隊時，你就會更清晰地了解誰負責產品的哪部分工作的。此外，你在定義主題的時候，你還需要任命一位負責人，這樣的負責人通常是產品經理。在一些工程師驅動的公司裏，這位負責人也可能是一位技術主管。負責人不需要管理團隊的其他人，但需要負責做出最終的決策，同時要對工作成果負責。
在Reddit，Kavin和Alex分別負責產品不同領域的工作，一位負責內容和社區，一位負責增長和盈利。此外，他們各自還組建了不同的主題團隊，每個團隊都有自己專門負責的工作領域。
每個主題團隊的負責人是需要做出最終決策的人，同時確保團隊裏的每個人的聲音和意見都能得到重視。如果你是團隊負責人，你需要讓團隊成員感受到他們的想法不僅被聽到了，同時得到了足夠的重視和理解。要想做到這樣，最簡單的方法就是重複他們説過的話：“你剛剛是説.......”，如果他們同意你的説法，那麼你可以説：“很好，現在我可以在決策的時候考慮你的意見。” 通過這種方法，即使最後你沒有采用他的意見，你也可以給出一個讓對方滿意的解釋，從而避免讓團隊成員產生疑慮，這有利於團隊和公司的長久發展。
隨着產品團隊日益壯大，你必須去教授和訓練這種技能。你需要幫助團隊中的每一個產品經理都培養出能充分考慮大家意見的能力。畢竟一個公司要想實現長久成功，團隊的和睦至關重要。
要想讓培養產品經理海納百川、充分考慮所有人意見的能力，就需要讓他們認識到，對於公司而言，任何一個單一決策對公司而言都不會產生致命的結果，同理，任何一個單一決策也都無法讓公司取得重大成功。這就降低了決策失誤的成本，減輕產品經理的決策壓力，讓他們能夠充分考慮所有人的意見。
產品運維的巨大影響
如果你不和產品團隊做好充分溝通，可能就會有很多個人只顧及各自負責的小功能和目標指標，而不會通盤思考整個產品。所以你需要一個“樞紐交警”，所有決策都需要經過他。他需要是一個能夠跟蹤同時開展的各個不同項目的人，了解不同項目間的相互影響。
你需要任命一個關注和重視產品宏觀體驗的人。這個人應該重視這兩項工作：（1）蒐集和溝通在實驗中獲取的數據；（2）引導每一個人都圍繞公司宏觀目標去開發產品功能和進行產品測試。如果你的公司有專門負責產品的副總裁，那麼他可以扮演這個角色。如果沒有，那麼可以指定一個產品人員來負責這項工作，或暫時讓CEO或聯合創始人負責也行。
如果某項產品功能的測試結果好的，這也並非意味着這項功能適合推給所有用户。你需要採取額外的步驟對結果進行分析，真正了解是什麼因素促使產生了這種積極的結果。在我之前就職的一家公司，我們常常會一天內開展5項測試，測試結果會相互衝突和影響，你很難真正搞清楚是什麼導致了什麼結果。
你的負責產品運維的“交警”需要充當這些測試結果的中央樞紐：集中獲取和分享測試結果，讓每一個人都知道這些測試信息。在Reddit，我們有正式和非正式的方法來分享這些信息。我們有產品經理午餐交流會，所有產品經理都在一起交流他們開展的有意思的測試以及測試結果。此外，我們還會召開戰略會議，某一領域的負責人將會彙報自己過去一個月中的工作和詳細的測試結果。
隨着公司規模的壯大，你會發現很多人都會陷入越來越長的產品迭代週期中。這時必須要有人關注和解決這個問題。比如，蒐集數據，看每一項新功能發佈所需要的時間，了解推出類似功能在不同時間段所花時間的差異，每一個衝刺期或季度推出的功能數量。你必須了解完成這些工作所花時間的長短，這樣一來，即使公司員工和項目越來越多，你都能保證產品迭代週期不會越來越長。
如果你了解Facebook的話，你就會發現它的產品迭代週期是非常短的，它並不是通過為一個項目配置更多人員做到這一點的。你需要有很多小的項目能同時保證產出，這就需要你在產品運維方面做好充分溝通。
為了能讓產品運維走向正規，你可以做以下這些工作：
- 確定少數幾個所有人都必須遵守的規則：對於我們來説，確保每一個人都在相同的進度上至關重要，所以我們對為數不多的例行會議非常嚴格。每兩週，我們都會開始一個新的衝刺。其他事情都可以靈活一點，但在每兩週一次的會議上，Reddit的所有產品團隊都會在會上開始一個新的衝刺——可能同時啟動7、8個項目。此外，每個團隊自己也會制定自己的衝刺計劃，他們只需展示給大家他們打算開展的工作就行。
- 提供一定的自主權：每個團隊在例會上做出的正式承諾有助於縮短產品迭代週期。但在一個迭代週期內如何具體開展工作，這由各個團隊自己確定，前提是他們能在每兩週一次的會議上交出滿意的衝刺答卷。
- 明確產品運維的角色定位。
- 現在就開始做。現在就開始啟動產品運維方面的工作，而不要等到有了總體規劃和確定的流程自後再去做。
如果你現在還是一家早期創業公司，團隊裏沒有人適合產品運維這個角色，這時不妨選擇一位高績效、注重細節的產品經理擔任這一角色。這個人必須是產品人員，這樣他才能了解不同項目的合理開發速度是什麼樣的。
在產品開發中提供或採納的建議都要符合公司的發展階段，然而這卻是很多人最容易忽視的。有人告訴你要數據驅動，你也努力想做到數據驅動，但在公司發展初期，你是無法做到數據驅動的。在一週只有300個訪客的情況下，你是無法開展A/B測試的。
另外一個常犯的錯誤在於，認為過去那些成功的做法能保證公司未來持續獲得成功。適用30個人的框架和流程是不適合200人的公司的。你必須機械化頭腦風暴流程、劃分責任、引進產品運維。只有這樣你才能緊密地團隊大家，激發大家將工作做到最好。
微信搜索“36氪”,獲取更多高質量內容.點擊進入36氪
資料來源：36Kr