"In preparing for battle I have always found that plans areuseless, but planning isindispensable."
——Dwight D. Eisenhower
作戰計劃書沒什麼用，但做計劃的過程不可或缺......
大部分的產品經理都需要定期做產品規劃，這些產品規劃包括了年度規劃、半年規劃、季度規劃甚至月度規劃。每個規劃需要畫產品路線圖（Roadmap），做幻燈片，先逐級彙總，向上彙報，然後再向下分解落地。如果速度慢一點，可能還沒來得及徹底落地，就要開始新一輪的規劃了。
就像艾森豪威爾所說的“作戰計劃書沒什麼用”一樣，產品規劃書通常也會跟現實情況有出入，用戶的反饋、市場環境的變化、競爭對手的策略、組織架構的調整等等都會導致產品規劃被修改或推翻。
剛做產品經理的時候，我很反感頻繁地去做規劃，感覺全世界的人都知道那是個謊言，但是還得一本正經地把謊說完。後來我逐漸意識到了規劃的重要性，也在實踐中總結出怎樣做出有價值的規劃。下篇我將用枚舉方式
| 自上而下，自下而上
不同的公司有着大體不同的產品規劃方式，下面舉兩個栗子~
1、自上而下:
含義：從最高管理層制定戰略開始，分解到各事業羣，再向下細化到產品線，最後拆解到每個職能的頭上。
（利）：更利於公司資源的戰略安排和協調，也方便戰略安排在組織內部的溝通和傳遞，因爲產品經理和開發都比較容易弄清楚自己做的事情跟公司方向有什麼聯繫；
（弊）：自上而下的拆解導致一線員工的判斷和認知很難融入公司戰略，很難做到所謂的“讓聽見炮聲的人做決定”，這可能會導致公司錯失機會。
2、自下而上：
含義：由每個具體的職能組發起，彙總到產品線，不斷向上傳遞，最終形成公司戰略。
（利）：後者則能夠給團隊成員更多的發揮空間，能夠激發主觀能動性。
（弊）：自下而上又比較散亂，缺乏一致性，可能不同的部門想做不同的事情，互相之間又需要彼此的支持，結果協調起來很困難，有種各自爲戰的感覺
3、產品規劃目的：
針對產品的願景和公司的戰略進行自上而下的溝通，讓每個人清楚組織接下來一段時間的方向和重心，並在公司戰略和自己的工作之間建立清晰的聯繫
激發大家的積極性和能動性，也可以給前線“可以聽到炮聲”的員工足夠的話語和決策空間
從這兩個目的出發，我們或許可以嘗試做一些結合。我認爲可以先自上而下，由公司管理層明確下一階段戰略方向，然後向具體的事業部拆解，但這個時候，不要下到太底層，只要有基本的框架就夠了，再自下而上進行具體的策略填充。
舉個例子：某個面向 C 類市場的產品，公司管理層在某一階段認爲用戶增量紅利基本沒有了，而且競爭對手該死的也都死了，沒死的基本也都成氣候了，一時半會兒打不死；所以公司決定會在接下來的一段時間內，集中資源改進和完善用戶體驗，公司重心不再放在增加用戶量上。
在這樣的方向和戰略下，服務部門可能會確定關注服務質量而非服務數量的規劃框架。至此，自上而下結束，自下而上開始。比如，服務部門下屬的呼叫中心會基於自己的職能範圍確定自己部門的策略，讓客服人員羣策羣力，討論通過哪些方式可以提高整體的服務質量，並且明確哪些數據指標可以反映服務質量的提高。
產品和技術部門也是一樣，先根據所在的事業羣做自上而下的拆解，然後再根據職能特點進行自下而上的細化。假設我是做支付的產品經理，基於用戶體驗的大方向，我可能會提出像“支持更多的支付手段”，或者“提高用戶交易安全性”等具體的規劃；而對於工程師來說，他們或許會考慮提高產品的響應速度和可用性等。
在類似的過程中，我們能清楚地知道公司接下來的業務重心和希望達成的目標，同時又有自由的決策和發揮的空間，是一個自上而下和自下而上兩者綜合的過程。
| 產品規劃不等於功能發佈計劃
很多的產品規劃文檔是由若干項目的簡述和預計發佈計劃構成的，我自己也做過很多這樣的規劃。這樣的發佈計劃很重要，但它卻不能算是好的產品規劃，它相當於跳過了爲什麼和怎麼做，直接描述做什麼和什麼時候做。
當大家聚焦於具體的項目內容和發佈時間時，很容易就會忽視產品規劃最重要的目的。大家不太容易從一堆項目中去猜測背後的公司戰略及部門階段性目標，而且在這樣的溝通框架下，真正擁有第一手訊息和經驗的同事會有一種“被告知”的感覺，這樣就會對產品和公司沒有參與感，失去主動性。
好的產品規劃應該從更宏觀的視角和判斷入手，儘量避免過分關注具體的項目和特性列表。
舉個栗子①
比如之前在做某條社區產品線時，我們分析認爲當時的短板在於內容生產不足，於是決定接下來先投入力量，提高整個社區的內容生產能力，下一步再提高內容分發與消費的效率，然後再關注社區用戶的互動氛圍。
在此基礎上，下一件事情是去明確檢驗每件事情是否做到的標準，比如通過監測新發的帖子數量來判斷社區的內容生產能力是否有所提高。至於具體的“做什麼項目來提高內容生產”，則是更進一步的具體實施階段才需要關注的事情。
因爲迭代比較快，而且每一步策略以及表現數據會影響下一步的方案設計，所以通常項目的發佈計劃不會規劃很遠。經常會出現“在項目進行過程中意外發現了機會，立即調整計劃跟進，或項目啓動後發現效果不好，中途止損取消”的情況。
更不用說組織架構調整、關鍵人員休假之類根本無法預期的意外情況！
有人會說：“既然大家都知道不靠譜，我隨便說一個到時候再調整是不是就可以了？”我的建議是：萬萬不可，寧可不給承諾，也不要承諾了卻交付不了。
前者別人最多說你慫，後者可是會喪失信任的，信任是產品經理的身家性命，一定要想辦法守好。
當然，在某些公司（尤其是大公司）裏，確定產品規劃時，如果沒有項目及時間點會被挑戰得比較厲害，爲什麼別人都有時間點你沒有？除非你已經是話事人，或者有絕對的影響力，否則這時就要考驗你在夾縫中生存的能力了。
我的建議是儘量打個提前量，提前進行戰略的溝通和團隊羣策羣力的討論，在此基礎上去做一些籠統的項目規劃，具體的特性能多模糊就多模糊，交付時間範圍能多大就多大。
舉個栗子②
比如我們的產品規劃是增加用戶支付手段:
錯誤規劃：“支持微信、支付寶和銀聯支付，11 月 20 日前上線”
正確規劃：“支持 3 種以上主流支付方式，在 11 月下旬至 12 月上旬完成”
更好規劃：“支持主流支付方式，Q4 完成”更好~
這樣做不但會讓團隊聚焦於業務目標而不是項目列表，也可以爲團隊爭取足夠的空間。
| 總結
1、我首先分享了自上而下和自下而上指定產品規劃的兩種方式，建議根據自己組織和業務的特點，選擇做產品規劃的方式；
2、帶着問題，奔着方向，產品規劃的目的及意義；
3、區分了產品規劃和發佈計劃的異同，這裏建議你不要用做發佈計劃的方式做產品規劃；