回首在創業公司擔任產品經理這幾年，火山在流程圖、原型圖、PRD等技術流的硬技能磨練得還算紮實，因為這些硬技能是隻要自己肯花心思去學習和研究，假以時日是可以達到一定的高度的。而對於如何管理需求、如何推動專案、如何進行產品決策等意識流的軟技能，就是很難通過理論的學習得到的。但恰恰也是這些意識流上的環節，是最容易讓產品經理走彎路的地方，這些彎路總結起來就是幾條：
第一、完美主義
這是初級產品經理最容易走的彎路。典型的表現就是想太多，臆想使用者需求，各種邊邊角角的應用場景考慮得細緻入微，投入巨大的人力，最後花了大力氣做出來一大堆使用者很少用，甚至根本用不到的功能。
第二、一蹴而就
簡單瞭解需求之後，沒有需求分析，不跟開發做可行性分析，在設計過程中也不跟業務方作需求評審，流程圖、原型圖、prd整個專案一蹴而就，最後PRD出來之後才進行需求評審，才發現一開始方向就錯了，整個產品方案需要推翻重做。
第三、脫離使用者
這一點，toB類產品經理是重災區。從銷售、客服、老闆、開發等等各方獲取需求，卻鮮有直接問使用者獲取需求，這直接導致產品經理對於偽需求的辨別能力直接下降，最終導致做出來的產品如同隔靴搔癢，無法觸及使用者心中最大痛點。
第四、決策缺跟弦
資源緊張，先做哪個後做哪個，產品的取捨與決策永遠都是跟著自己的感覺走，缺跟弦，或則索性被業務部門牽著鼻子走，缺少對於專案價值的考慮，最終導致花了很多的時間，做了很多的專案，產品卻沒有本質的提示。
第五、毫無章法
無論是管理需求、產品設計，還是資源協調、專案推動，基本都是跟著感覺走，想先做什麼就做什麼，想到哪兒就做到哪兒。缺乏有效而必要的管理規範，做專案也缺乏套路，毫無章法，進而導致需求管理一團亂，專案推進效率低。
以上這些彎路是我在創業公司這幾年感觸比較深的，正所謂吃一塹長一智，在我發現自己走過一條彎路之後，我就會總結一些改進或修正的方法，以避免在以後的工作中再犯同樣的錯誤，走同樣的彎路。儘管實踐證明，大多數心得都是行之有效的方法，大都能解決實際的問題，但它們主要還是針對每一條可能犯的錯誤制定的單點突破的攻略。團隊人員規模在擴大，專案越來越多。換一個專案、換一個產品經理、換一個對接人，這些錯誤就會繼續重演。因此，我就一直在琢磨，有沒有一種方法，可以：
- 最大限度地避免產品經理犯一些低階錯誤？
- 最大限度地讓不同風格、不同背景的產品團隊成員保持相同的步調？
- 讓產品經理制定的優先順序計劃與業務部門的需求儘可能地一致？
- 儘可能地避免產品經理的專案方案犯方向性的在錯誤？
- 最大限度地降低產品、開發與測試之間的溝通不暢？
- ……
作為一名名不見經傳的創業公司的產品新人，顯然，我很難接觸到BAT這樣的一些大公司的產品前輩，更沒有機會到大公司進行學習。但我知道，有很多的前輩，都已經把他們在大公司裡面的積累通過文字和書籍的形式分享出來了。因此，我瞭解這些大公司的途徑就是，看這些大公司的產品前輩寫的書。從剛入行做產品時，我就看過很多產品方面的大牛前輩的書，比如《人人都是產品經理》、《谷歌亞馬遜如何做產品》、《yes，產品經理！》等等，他們無一例外都提到了產品管理流程對於一家網際網路公司的重要性。因此，我在上任伊始就有意識地去建立一些必要的產品管理的流程。比如：
在我擔任我們公司產品經理之前，由於公司剛成立沒多久，總共也就七八個開發，沒有產品經理，更別提什麼產品管理規範。要說有什麼原則，那就是——怎麼快怎麼來。所以，我們能看到的幾乎所有需求都是從需求方（老闆、銷售、市場、客服、開發）以最短路勁直接提給開發。比如銷售接到一個客戶需求，回來跟某個開發簡單一說，開發gg以他們的高智商在腦回路里一轉——沒問題，可以做！於是立馬就著手開始幹了。再問他們要多久呢？腦回路再一轉，掐指一算——3天吧。最後，開發gg沒有食言，還果真用3天就把功能做完了，由於當時也沒有測試，於是開發gg自己測一下沒啥問題，當天下午就直接就釋出上線了……
這樣的形式由於中間環節少，看起來似乎工作效率、溝通效率都挺高。但時間一長，團隊規模一大，負面影響也就逐漸顯現出來了，這些負面影響集中表現在：
- 低價值需求——需求沒有經過有效地篩選過濾，開發的產品沒有缺乏有效的價值，一些低價值的需求被投入巨大的精力去實現；
- 低優先順序需求——需求的優先順序缺乏有效的評估，做了很多緊急但不重要的專案，對產品的提升並無太大的意義；
- 資訊不暢——由於大多單點溝通，所以業務部門並不知道技術部門在整體都在做些什麼專案，開發每天都很忙，但似乎沒有人知道他們在忙什麼；
- 節奏混亂——開發做完一個專案沒問題就發了，有時候一週法兩次，有時候一週發三次，也有時候遇到大的專案，可能兩週也不發一次，工作缺乏節奏感。
- 產品質量差——由於產品缺乏需求設計，又缺乏有效測試，產品上線之後又暴露出一堆的bug，根本用不起來。
第一把火：需求歸口
所有人提出的需求，必須且只能提到我這裡做統一的需求歸口，由我進行統一的需求篩選及優先順序管理。業務方不能越過產品經理直接向開發提需求，開發人員也有權拒絕產品經理之外的人員提的所有需求。就這樣，公司千絲萬縷的需求變得逐漸清晰，開發和業務部門都可以更加清楚地找到準確的對接人。而且，由於產品經理可以將業務部門的業務需求轉化為開發更容易理解的開發需求，也可以把所有開發正在開發的專案以清單的形式傳遞給業務部門，因此，這一把火，也讓整個公司跨部門之間的溝通變得更加通暢。
第二把火：產品測試
向公司提出直接了直接的測試人員招聘需求，為團隊補充測試人員的角色。測試人員到位之後，在專案沒有經過測試之前，開發不得直接把專案釋出上線。這一把火，讓我們的線上的產品質量得到了很大的提升。
第三把火：產品釋出
跟開發、業務部門一起，商定了每週四晚上23:00之後作為常規的釋出時間，除緊急修復類的專案之外，常規情況下，一週一個釋出週期，產品和專案的開發都按照這個節奏進行推動。這一把火，讓整個研發部門的計劃性得到了很大的提升。
這就是上任伊始我為公司制定的極簡版產品管理流程，儘管比較簡單，但的確解決了當時的很多實際的問題，以至於我們CTO在月度全員例會上，對我上任一個月的表現進行了點名表揚。但隨著公司的發展和團隊的擴張，這個最簡版的產品管理流程逐漸不能適應實際的工作需要，於是，我又根據實際的情況對流程進行了版本迭代和升級，比如：
由於沒有明確的PRD文件，而溝通又存在資訊的損耗和失真，開發最後實際做出來的功能跟產品經理的原始需求差別太大，進而導致跟開發扯皮的情況越來越多，於是，我增加了PRD文件的流程——產品經理提交開發之前必須要形成明確的PRD文件的流程。
業務部門的業務量陡增，對技術部門抱怨連天，總覺得很多很重要也很緊急的專案提給技術部門最後都沒做，於是，我增加了優先順序例會的流程——產品與業務每週一的需求優先順序排序的例會，一起商定接下來要做的專案優先順序。
由於需求變更經常導致開發、產品和測試之間的溝通問題，比如產品跟開發商定了需求變更的內容，卻沒有及時告知測試，導致經常測試按照舊版的PRD跟開發提bug在所難免，不僅產生工作量的浪費，甚至有時還造成一些不必要的矛盾。於是，我又增加了需求變更的流程——任何的需求變更，均需要同時跟開發和測試確認過後才可以進行需求變更，同時，變更的內容必須及時記錄進入PRD文件。
就這樣摸著石頭過河，一步一步地對產品管理的流程規範進行升級，最終，在我離開公司之前，就在當時那樣一個有著七八十人技術團隊的創業公司當中，形成了這樣一套產品管理的流程規範：
實踐證明，我當時為了解決實際問題所制定的這套流程規範，對於我們當時那樣一個規模的創業公司而言，基本還是行之有效的。但這並不意味著它也一定適合每一家創業公司，今天把這套流程分享給大家，也只是給大家做個參考。
那麼，創業公司到底需要怎樣的產品管理流程？
在火山看來，沒有任何一套產品管理流程是適合所有創業公司的，因為每家創業公司的情況都不一樣，永遠沒有最好的產品管理的流程，適合實際需要的產品管理流程就是最好的流程。要問怎樣才能制定出一套適合自己公司的符合實際情況的產品管理流程，如果一定要火山給出一個建議，那我的建議是：去了解成熟公司的做法，但照搬照抄成熟的公司的做法。因為每家比較成熟的網際網路公司都會有一套自身的需求或產品管理流程規範，它們可能因企業文化的不同、行業屬性的不同或產品形態的不同而形態各異，照貓畫虎可能會適得其反，即便是火山總結的這套相對比較適合創業公司的產品流程也是如此。
但殊途同歸，產品管理流程的存在，說白了都是為了通過規範的流程去降低因人、因專案、因背景等各方面因素帶來的不確定性，讓需求和產品的管理更加可控。與此同時，一套好的產品管理流程規範還可以從總整體上有效地提升一個團隊的工作效率和產品質量，而這也恰恰是管理流程存在與一個網際網路公司的最為重要的意義所在。
因此，無論公司大小，無論處於哪個階段，一套行之有效的產品管理流程對於一家網際網路公司都是非常關鍵和必要的。如果你所在的公司還沒有這套流程，或許是時候去制定一套了。
後記
回顧我所走過的這些彎路，它們有一個共同的特點，就是隻要產品經理願意去思考和總結，無論是什麼原因導致的，也無論是什麼樣的彎路，最終都是可以靠產品經理的努力解決掉或避免掉的，因為說到底它們基本都是一個產品經理本職工作內的內容。但還有一些彎路，可能是產品經理拼勁全力也未必能夠扭轉得回來的，它們就是由於公司高層決策失誤而導致的一些彎路，而這些彎路由於是大方向上的決策失誤，因此往往影響也更加深遠。
相關閱讀
評論(0)