復盤三步做好產(chǎn)品規(guī)劃

復盤三步做好產(chǎn)品規(guī)劃產(chǎn)品規(guī)劃是一件說難不難、說簡便不簡單的事情，筆者復盤了一次CRM系統(tǒng)的產(chǎn)品規(guī)劃，分享了其中對于關鍵節(jié)點的把握，以及做好一次產(chǎn)品規(guī)劃都要注意些什么事情。目前在一家互聯(lián)網(wǎng)財稅公司負責核心業(yè)務產(chǎn)品，手頭主要三大產(chǎn)品線：財務線、稅務線以及CRM線。最近帶著各產(chǎn)品線負責人完成了三大產(chǎn)品線的產(chǎn)品規(guī)劃，有些產(chǎn)品線是一直在持續(xù)迭代，有些產(chǎn)品線則是停滯了一段時間，換了產(chǎn)品線部門負責人負責人重新上手，整體上能來說已經(jīng)來說整理的七七八八了。過程中深感對于一名產(chǎn)品經(jīng)理來說，產(chǎn)品規(guī)劃能力的重要。而很多基本能力較為扎實的產(chǎn)品總監(jiān)在家電產(chǎn)品做產(chǎn)品規(guī)劃的時候也會陷入盲目堆需求、直接設計細節(jié)、優(yōu)先級排期混亂等問題上來。在此將上去自己的一些實操經(jīng)驗拿出來與大家分享。做產(chǎn)品規(guī)劃，說簡單也很簡單，把握關鍵節(jié)點，整理梳理出需求的輕重緩急即可。說難也很難，系統(tǒng)的現(xiàn)狀、市場的訴求、研發(fā)的資源、需求類型劃分、排期優(yōu)先級無一不是要納入考慮的要素。如何在千絲萬縷的線索中抽出一條清晰的脈絡，我的理解，最為關鍵的一點在于的業(yè)務深入理解和業(yè)務到系統(tǒng)做好抽象。做好這一步，產(chǎn)品規(guī)劃和需求排期最終不過是水到渠成的事情。本文我們以外呼型CRM系統(tǒng)為例（CRM較為普遍同時如前所述投資業(yè)務較為簡單），進行一次產(chǎn)品規(guī)劃的復盤。這一步先不要看任何系統(tǒng)，清空一切系統(tǒng)內的影像。首先，我們先思考，CRM業(yè)務發(fā)展的核心是什么？CRM的核心很簡單，過程銷售用來挖掘跟進銷售線索并最終實現(xiàn)到成交客戶轉化的就是。

這就是CRM的核心，圍繞這個流程，用戶（主要為本土市場銷售人員）有哪些行為和場景？從底下的一段場景描述中，我們發(fā)現(xiàn)涉及的用戶行為包括溝通工具的使用（電話、短信、微信、QQ等）、用戶跟進動作的記錄（打電話、上門拜訪等）、交易雙方達成必要手續(xù)（合同簽署、收付款等）。至此，我們可以總結下，CRM的本質是：通過溝通工具的使用、跟進動作的記錄、交易達成必要線索手續(xù)來推動銷售線索到成交額客戶轉化完成。不用這一步還是不要可看任何系統(tǒng)，清空一切系統(tǒng)的影像。跟進動作的記錄不用這一步還是不要可看任何系統(tǒng)，清空一切系統(tǒng)的影像。跟進動作的記錄通過上面對投資業(yè)務的梳理，我們可以開始思考一個缺陷，要完成上述的業(yè)務，我們能夠怎樣的一個系統(tǒng)。第一，這個操作流程系統(tǒng)需要幫我們完成操作步驟的流轉。而流程的流轉，無非要完成兩件事，在流程節(jié)點信息以及節(jié)點到節(jié)點之間的流轉。流程節(jié)點信息是什么？節(jié)點就是客戶所處的不同所在位置階段，即銷售線索、潛在客戶以及成交客戶三敏感性大客戶階段，流程數(shù)據(jù)流信息具化開來就是每個客戶階段客戶列表頁以及詳情頁客戶/客戶卡片。流程節(jié)點到節(jié)點之間的賴草要做什么？需要制定流轉的前提條件（如需要摻入哪些信息、上傳哪些文檔，生成哪些記錄等）以及流轉后的限制（必須哪個節(jié)點到哪個節(jié)點、流轉是否可逆等）。第二，流程不會潛意識流轉，而是通過一些核心功能模塊，來驅動操作方法的流轉。對照上圖，我們很極難拆分出溝通工具模塊（電話功能、短信功能、QQ等）、跟進動作的記錄（跟進動態(tài)、電話錄音、短信記錄、外勤簽到等）、交易達成手續(xù)（合同模塊、收費管理模塊、產(chǎn)品/服務管理等）。第三，作為一個系統(tǒng)，還需要一些通用功能來支撐用戶的基本操作和管理。我們可以把常用的系統(tǒng)功能拉都會看看是否我們系統(tǒng)過來用到，如用戶管理、權限管理、消息管理、基礎設置、幫助中心、數(shù)據(jù)統(tǒng)計……我們發(fā)現(xiàn)了一個不太一樣的通用模塊——數(shù)據(jù)統(tǒng)計。數(shù)據(jù)統(tǒng)計對很多系統(tǒng)來說，是一個通用的管理功能。但是對于CRM來說，數(shù)據(jù)數(shù)據(jù)分析統(tǒng)計不僅是對業(yè)務數(shù)據(jù)結果的分析，還會應用到對用戶工作的規(guī)劃統(tǒng)計和推動，即計劃模塊。所以，我們要把計劃管理放到推進推動流程流轉的核心功能中。

我們對上述功能抽象的結果做一個，如下：至此，我們完成了對業(yè)務到系統(tǒng)介面的抽象，看得出來可以看到的是我們對功能的拆解，換句話說是基于我們對業(yè)務思考抽象的思考。同時，也有一些功能是我們在做功能拆解的過程中衍生出來的功能，比如信息公海以及銷售線索的謎題領取與回收。在此有個小插曲，我們是如何衍伸基本功能出銷售線索的導入這一功能的呢？我們把銷售線索、潛在客戶、成交客戶編個號1、2、3。大家都知道程序員的一個梗說的是同樣是數(shù)數(shù)，正常人都是1、2、3，而程序員則會0、1、2、3?；氐轿覀兊脑O計，我們也會想，客戶是怎么就到了銷售案件線索這個階段（編號1）的？我們很容易就想起想到銷售線索從0到1的過程實際就是銷售線索衍伸實際的過程，從而衍生出銷售線索導入這個功能。其實，實際CRM系統(tǒng)設計中確實即便存在非常多的細節(jié)。例如數(shù)據(jù)回收協(xié)調機制、訂單流轉、財務對接、移動設備功能……揭開序幕來能講三天三夜。但之前我們也說了，本文僅演算法探討產(chǎn)品都市計劃的方法，而非CRM設計。在此再次聲明需要非常強調的一點：功能的拆解不代表的系統(tǒng)菜單的劃分，領袖更不代表的頁面的設計層級，所以我們還需要根據(jù)功能之間相互依賴的，來進行頁面模塊的拆分重組。關于功能的拆解到功能模塊的收斂、合并、拆分、嵌入，我們在此不做贅述。這一步，我們需要開始可看系統(tǒng)了，畢竟這早已幾乎已經(jīng)是最后一步了。在這一步，我們首先需要功能性得出功能清單。如果現(xiàn)在什么系統(tǒng)即便沒有，可能上述的功能拆解就是功能清單了。而如果我們是在已有系統(tǒng)上時做迭代，那我們需要拿著上述的功能清單，比對已有的信息系統(tǒng)功能，分析哪些功能我們被忽視的，哪些功能是需要優(yōu)化的。最終計算結果一個功能清單，或者就是所述我們通常所說的需求池。而下面，我們就要對供給池進行就要規(guī)劃了。對需求的規(guī)劃，我們依賴于三個主要指標：需求類型、需求重要程度、需求緊急程度。三大指標相互之間相互獨立，常規(guī)指標依序內部存在優(yōu)先級排序。緊急度通常作為版本規(guī)劃依據(jù)；需求重要性作為同一緊急度下（或者同一版本內）需求優(yōu)先級依據(jù)；同一緊急精準度度同一重要性下需求類型作為需求增益依據(jù)。具體來說：所有緊急度高需求構成最近即時一個版本需求，消費需求緊急度中需求作為下一發(fā)行版需求，緊急度低需求作為預計未來未來原版需求；同一版本需求中，按照需求必要性從高到低排列排序；同樣重要性需求量中，通常優(yōu)先處理線上Bug,其他需求類型次之。當然，每個系統(tǒng)融資需求類型、需求重要性、需求緊急度劃分需要根據(jù)各個英國公司公司的業(yè)務與產(chǎn)品自行定義，并不存在標準規(guī)范同一標準或者固定的公式。通過以上步驟，基本我們也就完成了初步的產(chǎn)品規(guī)劃。當然，產(chǎn)品規(guī)劃的最終定稿還要和開發(fā)、測試團隊進行溝通，結合團隊研發(fā)資源進行綜合考慮，最終和業(yè)務部門確認定稿，該過程我們在此不做贅述。在產(chǎn)品工作中，我一直認為，產(chǎn)品設計絕不能是一個依據(jù)個人感覺判斷一個人的主觀或者完成的工作。產(chǎn)品設計、產(chǎn)品規(guī)劃、產(chǎn)品溝通、項目跟蹤以及產(chǎn)品雜務工作的科研工作方方面面，都需要有認識論來支持經(jīng)驗主義工作的進行，有時候若是甚至像數(shù)學公式一樣，需要經(jīng)過嚴謹?shù)恼撟C與推導。每個人能人的方法論可能不盡相同甚至大相徑庭，同一個人的方法論也并不是一成不變。但只有通過方法論的提振，才能推動產(chǎn)品設計工作高效高質的完成，進而業(yè)務的落地與戰(zhàn)略目標的達成。聲明本文所提到的CRM系統(tǒng)以及相關業(yè)務，