永遠沒有最好的產品管理的流程，適合實際需要的產品管理流程才是最好的流程。

回首在創業公司擔任產品經理這幾年，火山在流程圖、原型圖、PRD等技術流的硬技能磨練得還算扎實，因為這些硬技能是只要自己肯花心思去學習和研究，假以時日是可以達到一定的高度的。而對于如何管理需求、如何推動項目、如何進行產品決策等意識流的軟技能，就是很難通過理論的學習得到的。但恰恰也是這些意識流上的環節，是最容易讓產品經理走彎路的地方，這些彎路總結起來就是幾條：

第一、完美主義

這是初級產品經理最容易走的彎路。典型的表現就是想太多，臆想用戶需求，各種邊邊角角的應用場景考慮得細致入微，投入巨大的人力，最后花了大力氣做出來一大堆用戶很少用，甚至根本用不到的功能。

第二、一蹴而就

簡單了解需求之后，沒有需求分析，不跟開發做可行性分析，在設計過程中也不跟業務方作需求評審，流程圖、原型圖、prd整個項目一蹴而就，最后PRD出來之后才進行需求評審，才發現一開始方向就錯了，整個產品方案需要推翻重做。

第三、脫離用戶

這一點，toB類產品經理是重災區。從銷售、客服、老板、開發等等各方獲取需求，卻鮮有直接問用戶獲取需求，這直接導致產品經理對于偽需求的辨別能力直接下降，最終導致做出來的產品如同隔靴搔癢，無法觸及用戶心中最大痛點。

第四、決策缺跟弦

資源緊張，先做哪個后做哪個，產品的取舍與決策永遠都是跟著自己的感覺走，缺跟弦，或則索性被業務部門牽著鼻子走，缺少對于項目價值的考慮，最終導致花了很多的時間，做了很多的項目，產品卻沒有本質的提示。

第五、毫無章法

無論是管理需求、產品設計，還是資源協調、項目推動，基本都是跟著感覺走，想先做什么就做什么，想到哪兒就做到哪兒。缺乏有效而必要的管理規范，做項目也缺乏套路，毫無章法，進而導致需求管理一團亂，項目推進效率低。

以上這些彎路是我在創業公司這幾年感觸比較深的，正所謂吃一塹長一智，在我發現自己走過一條彎路之后，我就會總結一些改進或修正的方法，以避免在以后的工作中再犯同樣的錯誤，走同樣的彎路。盡管實踐證明，大多數心得都是行之有效的方法，大都能解決實際的問題，但它們主要還是針對每一條可能犯的錯誤制定的單點突破的攻略。團隊人員規模在擴大，項目越來越多。換一個項目、換一個產品經理、換一個對接人，這些錯誤就會繼續重演。因此，我就一直在琢磨，有沒有一種方法，可以：

• 最大限度地避免產品經理犯一些低級錯誤？
• 最大限度地讓不同風格、不同背景的產品團隊成員保持相同的步調？
• 讓產品經理制定的優先級計劃與業務部門的需求盡可能地一致？
• 盡可能地避免產品經理的項目方案犯方向性的在錯誤？
• 最大限度地降低產品、開發與測試之間的溝通不暢？
• ……

要回答這些問題，我首先想到的就是——去學，去看看那些比較成熟的大公司它們都是怎么做的。

作為一名名不見經傳的創業公司的產品新人，顯然，我很難接觸到BAT這樣的一些大公司的產品前輩，更沒有機會到大公司進行學習。但我知道，有很多的前輩，都已經把他們在大公司里面的積累通過文字和書籍的形式分享出來了。因此，我了解這些大公司的途徑就是，看這些大公司的產品前輩寫的書。從剛入行做產品時，我就看過很多產品方面的大牛前輩的書，比如《人人都是產品經理》、《谷歌亞馬遜如何做產品》、《yes，產品經理！》等等，他們無一例外都提到了產品管理流程對于一家互聯網公司的重要性。因此，我在上任伊始就有意識地去建立一些必要的產品管理的流程。比如：

在我擔任我們公司產品經理之前，由于公司剛成立沒多久，總共也就七八個開發，沒有產品經理，更別提什么產品管理規范。要說有什么原則，那就是——怎么快怎么來。所以，我們能看到的幾乎所有需求都是從需求方（老板、銷售、市場、客服、開發）以最短路勁直接提給開發。比如銷售接到一個客戶需求，回來跟某個開發簡單一說，開發gg以他們的高智商在腦回路里一轉——沒問題，可以做！于是立馬就著手開始干了。再問他們要多久呢？腦回路再一轉，掐指一算——3天吧。最后，開發gg沒有食言，還果真用3天就把功能做完了，由于當時也沒有測試，于是開發gg自己測一下沒啥問題，當天下午就直接就發布上線了……

這樣的形式由于中間環節少，看起來似乎工作效率、溝通效率都挺高。但時間一長，團隊規模一大，負面影響也就逐漸顯現出來了，這些負面影響集中表現在：

• 低價值需求——需求沒有經過有效地篩選過濾，開發的產品沒有缺乏有效的價值，一些低價值的需求被投入巨大的精力去實現；
• 低優先級需求——需求的優先級缺乏有效的評估，做了很多緊急但不重要的項目，對產品的提升并無太大的意義；
• 信息不暢——由于大多單點溝通，所以業務部門并不知道技術部門在整體都在做些什么項目，開發每天都很忙，但似乎沒有人知道他們在忙什么；
• 節奏混亂——開發做完一個項目沒問題就發了，有時候一周法兩次，有時候一周發三次，也有時候遇到大的項目，可能兩周也不發一次，工作缺乏節奏感。
• 產品質量差——由于產品缺乏需求設計，又缺乏有效測試，產品上線之后又暴露出一堆的bug，根本用不起來。

于是，為了解決這些問題，最為一名新官，在我擔任產品經理之后，除了完成自己最基本的產品設計的工作之外，在產品管理的流程上，我也燒了三把火：

第一把火：需求歸口

所有人提出的需求，必須且只能提到我這里做統一的需求歸口，由我進行統一的需求篩選及優先級管理。業務方不能越過產品經理直接向開發提需求，開發人員也有權拒絕產品經理之外的人員提的所有需求。就這樣，公司千絲萬縷的需求變得逐漸清晰，開發和業務部門都可以更加清楚地找到準確的對接人。而且，由于產品經理可以將業務部門的業務需求轉化為開發更容易理解的開發需求，也可以把所有開發正在開發的項目以清單的形式傳遞給業務部門，因此，這一把火，也讓整個公司跨部門之間的溝通變得更加通暢。

第二把火：產品測試

向公司提出直接了直接的測試人員招聘需求，為團隊補充測試人員的角色。測試人員到位之后，在項目沒有經過測試之前，開發不得直接把項目發布上線。這一把火，讓我們的線上的產品質量得到了很大的提升。

第三把火：產品發布

跟開發、業務部門一起，商定了每周四晚上23:00之后作為常規的發布時間，除緊急修復類的項目之外，常規情況下，一周一個發布周期，產品和項目的開發都按照這個節奏進行推動。這一把火，讓整個研發部門的計劃性得到了很大的提升。

這就是上任伊始我為公司制定的極簡版產品管理流程，盡管比較簡單，但的確解決了當時的很多實際的問題，以至于我們CTO在月度全員例會上，對我上任一個月的表現進行了點名表揚。但隨著公司的發展和團隊的擴張，這個最簡版的產品管理流程逐漸不能適應實際的工作需要，于是，我又根據實際的情況對流程進行了版本迭代和升級，比如：

由于沒有明確的PRD文檔，而溝通又存在信息的損耗和失真，開發最后實際做出來的功能跟產品經理的原始需求差別太大，進而導致跟開發扯皮的情況越來越多，于是，我增加了PRD文檔的流程——產品經理提交開發之前必須要形成明確的PRD文檔的流程。

業務部門的業務量陡增，對技術部門抱怨連天，總覺得很多很重要也很緊急的項目提給技術部門最后都沒做，于是，我增加了優先級例會的流程——產品與業務每周一的需求優先級排序的例會，一起商定接下來要做的項目優先級。

由于需求變更經常導致開發、產品和測試之間的溝通問題，比如產品跟開發商定了需求變更的內容，卻沒有及時告知測試，導致經常測試按照舊版的PRD跟開發提bug在所難免，不僅產生工作量的浪費，甚至有時還造成一些不必要的矛盾。于是，我又增加了需求變更的流程——任何的需求變更，均需要同時跟開發和測試確認過后才可以進行需求變更，同時，變更的內容必須及時記錄進入PRD文檔。

就這樣摸著石頭過河，一步一步地對產品管理的流程規范進行升級，最終，在我離開公司之前，就在當時那樣一個有著七八十人技術團隊的創業公司當中，形成了這樣一套產品管理的流程規范：

實踐證明，我當時為了解決實際問題所制定的這套流程規范，對于我們當時那樣一個規模的創業公司而言，基本還是行之有效的。但這并不意味著它也一定適合每一家創業公司，今天把這套流程分享給大家，也只是給大家做個參考。

那么，創業公司到底需要怎樣的產品管理流程？

在火山看來，沒有任何一套產品管理流程是適合所有創業公司的，因為每家創業公司的情況都不一樣，永遠沒有最好的產品管理的流程，適合實際需要的產品管理流程就是最好的流程。要問怎樣才能制定出一套適合自己公司的符合實際情況的產品管理流程，如果一定要火山給出一個建議，那我的建議是：去了解成熟公司的做法，但照搬照抄成熟的公司的做法。因為每家比較成熟的互聯網公司都會有一套自身的需求或產品管理流程規范，它們可能因企業文化的不同、行業屬性的不同或產品形態的不同而形態各異，照貓畫虎可能會適得其反，即便是火山總結的這套相對比較適合創業公司的產品流程也是如此。

但殊途同歸，產品管理流程的存在，說白了都是為了通過規范的流程去降低因人、因項目、因背景等各方面因素帶來的不確定性，讓需求和產品的管理更加可控。與此同時，一套好的產品管理流程規范還可以從總整體上有效地提升一個團隊的工作效率和產品質量，而這也恰恰是管理流程存在與一個互聯網公司的最為重要的意義所在。

因此，無論公司大小，無論處于哪個階段，一套行之有效的產品管理流程對于一家互聯網公司都是非常關鍵和必要的。如果你所在的公司還沒有這套流程，或許是時候去制定一套了。

后記

回顧我所走過的這些彎路，它們有一個共同的特點，就是只要產品經理愿意去思考和總結，無論是什么原因導致的，也無論是什么樣的彎路，最終都是可以靠產品經理的努力解決掉或避免掉的，因為說到底它們基本都是一個產品經理本職工作內的內容。但還有一些彎路，可能是產品經理拼勁全力也未必能夠扭轉得回來的，它們就是由于公司高層決策失誤而導致的一些彎路，而這些彎路由于是大方向上的決策失誤，因此往往影響也更加深遠。

作者：火山，個人微信公眾號：PM火山。

本文由 @火山 原創發布于人人都是產品經理。未經許可，禁止轉載。