在傳統企業與互聯網企業，產品經理所負責的職責范圍不都相同，能夠施展的領域也不一，雖各有差異，但各自有優缺點。作者結合自身經歷，分享他是如何完成這款產品0-1設計的，希望對你有些啟發。

趕上互聯網裁員的大浪潮，我從上家公司畢業了，入職新公司后，新公司目標是自研一套信息化管理系統，給自己的眾多分公司使用（各個分公司的業務大體相同，可以共用一套產品），總部可以對各分公司統一管理。我就是這個項目的產品經理，唯一的產品經理。沒錯，新公司屬于傳統行業，并非互聯網行業，投入到IT建設的經費有限，所以只有我一個產品經理，開發是外包。

下面步入正題，結合我的實際經歷，介紹下我是如何完成這款產品0-1設計的？

一、明確產品定位

對于企業自研產品，花錢的是企業老板，在開始動手前，要先明確老板的需求和想法，避免做出來的東西不是老板想要的。在開始之前，我先是組織召開了一次會議，明確新產品的定位，想要達到什么樣的目的，以及后續產品可能發展的方向。

參會的人員包括老板、研發負責人、市場部負責人和運營部負責人，我們暫且將他們統稱為產品評審團。會議最后大家也都達成了一致的結論，想要用新產品實現企業的數字化轉型，方便總部統一管理。需要實現進銷存的管理、基礎業務的流程管理、相關的報表統計等等，還明確了哪些業務需要總部統一管理，剩下的可以由各分公司自由管理。

其中老板還提到一點，產品在自己的企業運行穩定后，后續會賣給其他同類型企業，由于企業所處行業較小，該行業的信息化系統還是處于市場空白階段，所以新產品研發后具有一定的市場競爭力?；谶@個原因，新產品可以考慮使用SaaS模式。

從運營戰略上看，SaaS的服務模式有3種：

①純SaaS模式：互聯網公司提供軟件，幫助客戶用起來，推動續約。

②SaaS+模式：除提供軟件服務外，基礎行業的理解提供增值服務。

③+SaaS模式：先完成自己的數字化轉型，再通過SaaS模式溢出自己的運營能力，幫助其他企業實現數字化轉型。

很顯然，我們的新產品很符合最后一種。

二、業務調研

明確了新產品的方向，下一步就是開始干了。首先就是需要到企業中去，做業務調研。這時需要選擇一個標桿企業，并且這個標桿企業是老板認可的，可以將標桿企業的管理理念通過新產品延申到其他分公司，形成標準化管理。走到企業中去，我們需要了解以下內容：

1. 企業的組織架構和崗位

特別關注組織架構中的重點崗位和產品相關崗位，羅列出每個崗位的崗位職責，對于后面的調研打下基礎，避免在調研時忽視了某個角色，同時幫助我們理解企業的業務。

2. 企業業務的整體情況（宏觀）

首先要了解企業的商業模式和經營策略，這兩者決定了企業的工作重心，是企業的管理者最關注的點，而新產品面向市場時，客戶決策人正是企業的管理者。了解商業模式和經營策略，可以把我們的視角拉到和企業管理者一樣的高度，也可能從中找到重要的觀點作為產品原則來指導我們后續的產品設計，有利于讓我們的產品更符合所屬行業，以及后期可以銷售給更多的客戶；

其次了解企業的整體流程，畫出整體流程圖，需覆蓋企業的所有業務類型，主要描述關鍵流程和步驟，不需要細化到具體功能。整體流程圖可以幫助我們快速的了解企業的業務流程，同時為后面輸出詳細流程圖打下基礎，避免疏忽遺漏。

3. 企業業務的詳細說明（微觀）

詳細流程圖?；谡w流程圖，對每個步驟梳理詳細流程圖，要盡量細致，同時避免遺漏。關注每個環節節點的多種可能性，每個節點是否可以進行逆流程操作，將所有情況考慮全面，必要時記錄解釋說明。梳理好后，要和業務人員核對一下，保證信息同步，流程圖的格式均可，能保證清晰即可，保證調研結束再看流程圖仍可以看懂。

業務規則重難點說明。將流程圖無法體現的業務規則，描述記錄下來，業務流程中的重難點，單獨記錄出來，產品設計時多關注這些點。如果新產品可以解決目前企業的難點痛點，那新產品對于企業的價值是非常大的，一些同質化的功能并不能彰顯新產品的價值。

4. 報表和單據

無論是業務人員還是管理層，都會有報表需求。管理層往往每隔一段時間就會查看企業的經營情況數據，所以報表的需求在MVP版本是一定要做的，我們需要收集企業現有的報表。無論企業是否已經數字化，都會有在用的報表，如果沒有數字化，管理者也會自制表格讓一線業務人員填寫，已經數字化，就收集下現有系統中的在用的報表，確認是否還有其他線下的統計表格在使用。

單據也是業務環節中不可缺少的，如果企業有打印單據的需求，還要收集企業正在使用的單據，誰用，在什么時候使用，參照收集的單據樣式，都要加到產品設計中。比如去醫院看病時，醫生會給我們打印處方單，處方單上由系統自動打印出醫生開的藥品，拿著處方單去收費處繳費，收費單上顯示每個藥品的價格和總價……這些都是系統完成的。

收集報表和單據時，不光是要收集，還要理解里面每個字段的含義，產品設計時也要考慮業務流程可以提取出這些數據字段。

5. 現有系統

我們的企業一部分正在使用其他同類型產品，新產品上線后會替換掉當前使用的系統，這時要關注一下現有系統企業使用的情況。

接觸過客戶的產品經理一定知道，客戶總喜歡說的一句話，“之前的xxx系統可以那樣，你們這個系統怎么不行??？”，客戶對之前的系統是有使用習慣的，突然切換系統會不習慣，總會和之前的系統去對比，如果他想做的事情，新產品滿足不了，他會覺得體驗很差，新產品不如舊產品。

所以我們要訪談一下，每個角色每天都會使用現有系統的哪些功能，他認為哪些功能好，哪些功能不好，理由是什么，期望有什么新功能。認為好的功能新產品一定也要有，或者用其他形式滿足，認為不好的功能新產品要改正，期望的新功能視情況具體分析MVP版本要不要做。

三、確定MVP

業務調研回來后，梳理好詳細業務流程圖和業務規則，此時我們已經對需求明確了，下一步就是要確定MVP版本的功能范圍，MVP版本要滿足最小化和可行性，即只做最核心的功能和客戶能用起來。

首先要劃分需求優先級，根據需求優先級的高低決定MVP做哪些功能。這里使用到RICE法則：Reach觸達，有多少客戶提出了這個問題；Impact影響力，客戶對這個需求的迫切程度和重視程度；Confidence信心，產品經理對這個需求的判斷；Effect努力，付出的成本。

把需求全部劃分優先級后，組織會議討論MVP版本的功能范圍，邀請產品評審團參加。為了便于參會人員的理解，需要把需求整理，按模塊劃分，每個大需求有哪些需求點，不用特別詳細的邏輯說明，把關鍵點列出來就好。通過我們已經對需求優先級的判斷，再結合產品評審團的意見，最終明確MVP版本要做哪些功能。

四、輸出詳細方案

MVP版本功能確定后，開始設計原型，設計時參考業務調研時的詳細流程圖，爭取每個關節節點的逆流程和多種可能性考慮全面。評審通過后，提交給開發，進入正常軟件開發環節。值得注意的是，一旦開始開發后，盡量保證需求不再變更，如果是接收到了新的急迫需求，可以安排到1.1版本的迭代中，盡量不要打擾開發人員的節奏，如果是設計邏輯遺漏缺陷這種問題還是要處理的。

MVP版本上線后，我們是先在調研企業試運行一段時間，把期間反饋的小問題和bug解決掉，運行穩定后，在逐步推廣至其他分公司。

寫在最后

在傳統企業中是否利于產品經理的職業發展，我有幾點感受和大家分享一下。

首先說不好的地方：

資源極少，甚至沒有UI、測試，如果涉及C端頁面，就請個外包的UI設計，按頁面收費，PC端頁面的效果完全由前端開發把控。

開發是外包的，異地協作，我們的外包開發喜歡晚上熬夜工作，上午睡覺，所以只有下午時間可以溝通，有時晚上在群里發消息還要回復；不照著原型做，有時候原型復雜了，就用一個簡單的方式代替了，功能實現了但用戶體驗減分；測試出來的問題改不干凈，有的問題改幾次還是改不好。

沒有測試，沒有測試，沒有測試。很苦惱，自己測根本測不全，很多bug測不出來，上線后都是客戶發現bug，再改，用戶和我的體驗都很差。

充當客服。幫助企業產品上線、產品培訓、日?；貜彤a品使用問題，周末的問題也要回復。

不利于培養商業思維。傳統企業的自研產品，就是企業內部使用，并不會靠產品獲取利潤，所以沒有機會培養產品經理的商業思維。

再說好的地方：

對產品的話語權較大。不像在互聯網公司，每個產品經理只負責一個產品模塊，在傳統企業中可以站在更高的視角對整個產品進行規劃，可以培養產品管理能力。

可以接觸用戶。有足夠多的機會去接觸用戶，收集意見，直接對接用戶可以收獲一手需求，誰懂用戶，誰對產品就有話語權。