起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識我在安全行業創業——產品篇
編輯導語：本文作者和大家分享了做創業團隊中的產品經理的一些感悟和產品工作流程，包括市場調研、需求分析、產品規劃設計、需求評審、協調跟進、產品測試和上線后反饋改進，希望對大家有所幫助。
宇宙的盡頭是考編，那產品經理的盡頭是什么？
本篇文章是創業記錄的產品篇，本來想要寫的內容很多，最終還是決定聚焦在創業團隊產品經理的一些事兒。
我大學畢業的第一份工作是程序員，但相較于需要遵循既定規則的編碼工作，我更喜歡做有創造屬性的產品工作。從程序員轉行產品經理，是有加分項，但由于沒有系統性的學習產品相關知識，同時也面臨不具備產品技能、缺乏產品方法論、無項目經驗等困境，所以經歷了很長一段海投簡歷卻鮮有回復或面試一輪便不了了之的“至暗時刻”。
我沒有大廠的工作經歷，所以我這里分享的也是基于自己在中小企業、創業團隊中的經歷。
在正式進入產品工作之前，往往是從老板、業務團隊、競品、用戶處獲取新想法或者行業新的發展趨勢，從而形成新需求。
一個完整的產品工作流程包括：市場調研、需求分析、產品規劃設計、需求評審、協調跟進、產品測試、正式上線、產品培訓、收集反饋、持續改進。這里面也包含了產品經理的工作職責和基本能力，下面我結合自己的親身經歷，和大家分享一下這些流程中的一些事兒。
一、市場調研
市場調研一般包括用戶調研和競品調研。
1. 用戶調研
用戶調研是指通過包括但不限于問卷、現場訪談等方式獲取受訪者的痛點、建議、意見等，并針對用戶調研獲取的信息進行統計分析，從而具象為用戶具體需求或解決方案。
我們的用戶以政府、公安、企事業單位為主，他們對于問卷調查這類調研方式往往不太關注，也不會認真對待。經過兩次問卷調查發現調研結果不太理想后，我們也減少了問卷調查。當我們在產品方向上有新的想法或改動后，就通過即時通訊工具或者現場調研會的方式，與用戶中的特定人群進行正式或非正式的溝通。
不管是TO G還是TO B類型的產品，往往業務鏈路長、業務流程復雜、涉及角色多。每次調研之前我們都需要明確本次調研的目標，在調研過程中也要一直緊扣主題，嚴格控制討論的邊界，防止出現會議主題跑偏的情況。
不管是我們自身還是用戶的時間、精力都是非常有限的，如果我們每次的調研會沒有達到想要的效果，從而出現多次反復談論的情況，用戶也會表現出不耐煩、甚至質疑能力的情況。
2. 競品分析
競品調研主要包括競品定位調研、功能分析、商業模式分析。
要知道在TO B或者TO G領域，一般來說沒有哪一款產品能夠解決某個業務場景的所有問題。
比如我們行業內的一家競品公司的產品，更多地聚焦在業務前期的委托受理和特定業務進行中常規狀態下的業務過程處理，另一家則更多地聚焦在通用場景的標準化處理過程。兩家公司的產品定位有重合，也有不同之處。而我們希望在這條賽道上能殺出一條路來，產品就必須有其他的亮點，畢竟打敗微信的一定不是另外一個微信。
經過與用戶溝通，我們得知由于近幾年司法行業的整頓，用戶對業務處理過程中的操作行為留痕、文書歸檔、問題規避有非常強烈的需求，所以我們產品的定位就聚焦在司法行業業務處理過程規范化以及司法文書線上歸檔，致力于為用戶規避業務操作中的問題，完善問責制度。
相信很多產品經理都做過功能分析，特別是在產品功能設計的時候。畢竟友商之間“互相借鑒”都是司空見慣的事情。但我們借鑒的時候，要知其然也要知其所以然。
最開始我使用競品的產品時，發現有很多莫名其妙的操作，明明可以非常簡便的完成某個流程，但競品卻設計得異常復雜，但當我認真梳理業務流程、政策文件時，才發現是出于業務流程需要和政策要求。
作為產品經理，我們在使用任何一款產品的時候，其實都可以養成有意識地去理解產品設計背后邏輯的習慣，這也有利于我們在后續的工作中明確思路和參考“復用”。
在我最開始做競品分析的時候，最容易忽略的就是商業模式的分析，上周在“人人都是產品經理”上，看到一位作者詳細地講了講商業模式與盈利模式的區別，獲益匪淺。文章里面提到，“商業模式=推廣模式+用戶模式+產品模式+盈利模式”。
雖然我們做任何一款產品都是為了盈利，但應該先梳理用戶群體，明確提供產品的方式，做好推廣，最終才能實現盈利。這些要素加起來形成了一個完整的商業模式。
我們對競品的商業模式的調研也會反向給我們提供思路。我還是以我們的競品為例，一家競品仍采取以傳統的項目建設收費、按年收費、按照使用數量收費等收費方式。
而另一家則免費建設，按照用戶案件的涉案金額或催收還款金額比例提成收費。同時包括與其他各大司法機構合作形成數據互通。各大司法機構保證案件數量，他們通過系統建設和技術服務的方式，保證案件成功率，以此形成對賭框架。
兩家公司的商業模式各有利弊，第一家更為穩定但利潤率較低，第二家風險相對較高但利潤率也較高。分析競品商業模式也是為了自己產品在形成商業模式上提供思路，形成一套完善的商業模式，當然具體怎么選擇商業模式也要看團隊所處階段和團隊成員的秉性。
3. 政策調研
由于我們的產品和項目主要聚焦在“網絡安全+司法”領域，產品的需求和改動有很大一部分來自于法律法規、政策、國家標準、行業標準的變動，所以我平時除了用戶調研和競品調研，還會關注相關法律法規、政策的變動，甚至在必要的時候也會邀請行業內專家對政策進行解讀，以便我們更好地理解政策用意和明確我們的解決方案。
二、需求分析
我在《售前篇》里寫售前工程師的“聽說讀寫”，其實“讀”就是用戶需求分析，搞清楚用戶的顯性需求和隱性需求，讀懂用戶的真實想法。但產品經理的工作粒度更細，會涉及到每一個功能點的設計，也會影響研發同事的研發進度和排期，所以產品經理的需求分析也需要更細化。
我一般會從三個維度來分析需求：
1. 真需求or偽需求？
首先說一說真需求還是偽需求，我們接受需求的來源可能是客戶、公司老板、銷售團隊、技術團隊等，每個角色可能都是站在自己的角度提出需求。但“屁股決定腦袋”，我們不能盲目聽從他人的建議，我們也沒有辦法滿足所有用戶。
比如有一次我們技術團隊提出，考慮到數據的安全性，是否需要設置用戶在登錄情況下半個小時不操作，就自動退出登錄。一開始我還非常高興并且采納了技術團隊的建議，上線后卻遭到用戶強烈吐槽頻繁的重新登陸。
原因是用戶操作系統的環境是在一個有嚴格權限控制的物理環境，不會存在有其他相關人員能夠隨意進出和操作的情況，這就是我之前沒有結合實際情況判斷需求真偽。
真需求還是偽需求有幾個簡單的判斷標準：
- 需求提出方是不是我們的真實用戶；
- 是個性化需求還是通用需求；
- 需求是否和公司的利益存在沖突。
所以不光研發會砍產品經理的需求，產品經理自己也要學習砍需求。
2. 需求背后的緣由？
搞清楚需求背后的緣由是為了在產品規劃設計的時候，能夠達到用戶希望的效果。這個時候我們需要從用戶的真實使用場景、實際業務流程、操作的頻率入手，深入了解，以此才能在系統設計時找到更好的解決方案，當然在設計過程中也要持續與用戶保持溝通，以避免錯誤理解需求或設計問題。
3. 需求是否緊急？
需求是否會影響到用戶的日常使用？不及時上線是否會對用戶或公司帶來損失？是否還有更重要的功能需求？這些都是影響需求排期的關鍵因素，所以需求需要區分優先級、重要性，也要充分考慮公司戰略、投入產出比、團隊資源等因素。
比如我們創業團隊的開發資源永遠是有限的，對于非緊急或并不那么重要的需求往往先放入需求池，等到后面版本再實現。
三、產品規劃設計
我理解的產品規劃設計其實是兩個層面的事情，“規劃”和“設計”其實是兩個層次的工作。
產品規劃是相對于需求的具象。相對產品設計的抽象，產品規劃包括業務流程梳理、產品架構梳理、產品功能梳理，當明確用戶需求之后需要對整個業務流程通過圖表的方式進行可視化的展示（Visio、Excel等），把所有流程、角色、節點、條件都羅列出來。
在梳理的時候要通盤考慮避免遺漏，這里可以自己整理一個查漏補缺表，通過查漏補缺表單和流程對應檢查是否缺失。產品架構梳理到產品功能梳理也是由抽象到具象的過程，我們首先通過梳理流程將不同業務流規劃成不同的系統板塊，再根據不同的系統板塊梳理羅列對應的功能點。
比如我曾做過的一個產品，上級用戶向下級用戶下達的指令有不同的類型，而不同的指令類型的業務流程不同，我們就在梳理框架的時候將不同指令作為不同的系統模塊羅列。
某類指令的實效性相較于其他指令的實效性更強，這類指令就需要加上即將逾期、已逾期等功能屬性，再根據不同的指令類型的流程和需求進一步明確功能點，這樣就可以從粗粒度的框架細化到細粒度的功能點。這樣做的好處是既可以避免功能模塊的遺漏，也可以避免因業務流程繁雜而導致規劃混亂的情況。
產品設計簡單來說就是將羅列出來的功能點，通過可視化的方式展示（包括原型圖、PRD文檔）。
曾經剛入行的時候一直以畫好原型圖為終極目標，后來才發現畫原型是基本能力，而非核心能力，前期的調研、需求分析是輸入，原型圖、PRD是經過梳理思考和嚴密邏輯推理后的輸出，原型設計的意義在于節省與客戶、研發、UI、測試等溝通成本和降低大家的理解成本，可以讓各方人員更明了地理解產品的功能與流程。
對于是高保真還是線框圖，也是根據不同公司的要求因人而異。重要地不是把原型畫得多漂亮，而是能在原型設計圖中將需求點講清楚。我一般更習慣用線框+簡單的交互，復雜交互我選擇用文字的方式梳理。
四、需求評審
其實我們做產品就是一個重復輸入、輸出的過程。需求調研（輸入）——>產品規劃設計（輸出）——>需求評審（輸出&輸入）——>原型調整（輸出）。
需求評審是每一個產品經理都會經歷的過程，產品在迭代，需求在更新，需求評審也會一直持續。
其實需求評審會最需要解決的問題就包括：
（1）向團隊成員傳達解釋需求價值（why），為什么會有這樣一個需求，我們為什么要做？
我們開需求評審會的成員可能包括：公司老板、業務部門負責人、研發、測試、UI等，需求的實現其實都是技術部門而非業務部門，他們可能對業務的理解和需求的價值并沒有老板、業務負責人、產品經理深。在讓技術部門實現功能之前，要做到知其然，也要知其所以然。
很多時候研發的同事認為，第一次需求確定了就不要再改了，每次讓他們修改之前的需求，總是需要軟磨硬泡，還會質疑需求的合理性。但是市場在變化，客戶也在變，我們的產品更需要隨之調整。
傳達需求價值既是為了讓團隊成員對業務和需求的理解更清晰，也是為了讓他們知道這個需求并不是拍拍腦想出來的，更容易讓他們接受，也可以增強對你的信任感。
（2）向團隊成員輸出需求的具體規劃（what），這個需求的具體流程是什么，功能是什么？
會前我都會自己過一遍具體的規劃，再次梳理規劃的鏈路，保證能在會上更夠簡單、直接、明了地向團隊成員介紹。
會上首先通過思維導圖、流程圖的方式，讓團隊成員對系統的規劃設計有一個初步的印象。然后再通過原型圖的詳細說明，完整表達規劃思路。在這個過程中會穿插一些問題的討論，這個時候就需要充分聽取團隊成員的意見和建議。
雖然大家都說我們要把自己當成用戶，但由于我們作為團隊內部最熟悉業務流程的人，產品設計一定會有主觀元素在里面，有時候就難免會有一些設計不當考慮不周的地方，這個時候團隊成員可能更容易站在用戶視角看待問題。
（3）與團隊成員協商需求的實現過程（how），功能如何實現，由誰實現，實現的周期？
任務分配、周期明確也是評審會的一個非常重要的環節，計劃出來了得有人具體實施。這個就需要根據需求的輕重緩急、團隊資源、成員排期具體協商。
還有一些事情需要注意：
- 會前充分準備，提前將相關資料文件與團隊成員共享，以避免團隊成員需要現場熟悉會議資料；
- 不要太玻璃心，有時候我們可能會出現產品規劃的時候有邏輯漏洞的情況，而被研發同事批得體無完膚，這個時候應該勇敢承認自己的錯誤；
- 會中注意控場，避免討論問題邊界太過發散；
- 會議結束前就關鍵問題進行總結，確保大家對本次會議的議題達成共識；
- 會后及時做會議紀要，避免未參會人員僅能得知零散信息，導致產品推進進度慢。
五、協調跟進
我們沒有專職的項目經理，產品經理兼任項目經理。產品研發迭代過程中，由產品經理作為橋梁對上匯報、對下傳達，同時負責把控產品開發周期與進度，跨部門的協調溝通。
需求明確后，我一般會與研發負責人一起分解任務（細化到具體功能點），最終形成任務清單和里程碑；了解目前研發同事手里任務多寡，進而進行任務的分派；同時也會讓同事對分派任務進行再次確認（簽字畫押），以增強目標感和責任感。在整個研發過程中，我也會每天了解研發進度，以便及時發現并調整進度偏離的問題。
產品經理還有一個很重要的職責就是跨部門甚至跨公司的協調，研發同事往往更喜歡悶頭自己做自己的事情，對于這類協調溝通的事情不太擅長也不太情愿。產品進入研發階段，作為產品經理更多也是協助研發同事能夠順利推進產品研發。
對外協調我們可能需要主動“組局”，比如我們經常都會遇到與第三方公司接口聯調的情況，而跨公司協作就經常會出現溝通問題、時間問題。我們需要提前把兩家公司的相關人員聚集起來共同制定目標，約定調試時間，以免出現一方長時間等另一方的情況（畢竟大家的時間都很寶貴）。
對內我們也需要及時協調溝通，比如后端開發已經把所有功能接口完成了，但前端還在等UI設計圖，導致項目會出現停滯的情況。這些都是我們需要去解決的。
六、產品測試
嚴格來說產品測試的時間和產品開發的時間應該是一半一半。
沒有經過系統化的測試，大概率在正式環境中會出現很多問題。產品測試也不能僅僅QA部門，作為產品經理，你是設計產品的人也是最熟悉產品的人。
測試階段前將測試用例寫好真的非常重要，我們要把每一個需要測試的分支項詳細羅列，對于需要重點測試的板塊也要提醒，標注測試方法和預期結果，不管是我們自己測試還是QA測試，甚至全員測試的時候大家方便對照。
我一般會在交給QA部門前，自己進行至少2-3次的系統性測試，在測試過程中也會發現一些自己以前沒有考慮周到，研發也沒有發現的問題，這樣做也是為后面測試的同學節省時間（因為我們的資源真的很緊張，我們幾條產品線并行，但測試人員也嚴重不足。）
我們測試問題一般是放在禪道上，然后指派給對應的研發同事，研發同事修改完善后記錄，再進行回歸測試。雖然我不是專業的QA，我們的測試流程也沒有大廠那么嚴謹，但在不斷地摸索過程中也發現了一些容易出錯的點，總結了一些方法。
七、上線、反饋、改進
產品做得怎么樣，就需要上線后交給用戶來評判了。
不管是項目還是產品都是周期的，一定會有一個開始節點和關閉節點。諾蘭模型把系統的周期分為初始期、普及期、控制期、整合期、數據管理期和成熟期，周期之間都必須從一個階段發展到下一個階段，不能實現跳躍式發展，這些周期也對應了我們產品優化迭代的進度。
沒有十全十美的產品，沒有能夠滿足所有用戶的產品。包括微信才出來的時候，同樣也有很多不盡如人意的地方，他們同樣也是通過建立反饋機制，搜集數據，不斷地改進才有了現在的樣子。
我們做產品同理，我曾經聽到一句話“如果我們不能做到一鳴驚人，那就先以破爛示人”，深以為然。我們可以允許前期產品的缺陷，這些缺陷或許是我們了解用戶不夠、或許是我們思考不到位、或許是我們團隊資源不足，但我們要以良好地心態去面對去解決，破爛是一時，改進才是常態。
面對用戶的反饋，擁有良好心態也是非常重要的。無論是吐槽還是謾罵，我們都要本著做產品的初心去面對。有人吐槽說明他們是真的在用，沒人反饋才是最糟糕的。我們要學會主動去過濾無用信息，主動尋找并聽取有效建議。
以上是我基于一個完整的產品工作分享的一些思考感悟。
回到文章最開始的問題，產品經理的盡頭是什么？在我看來產品經理沒有盡頭，只有無止盡的學習和思考，不斷地輸入再輸出。
人人都可以是產品經理，但不是人人都可以做好產品經理。
本文由@蹦蹦怪 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Pixabay，基于CC0協議
你的例子中說到：客戶投訴長時間不操作需要重新登錄；
但是這個功能（超時自動登出）對于2B的客戶，應該是報障產品安全、用戶信息安全的最基本功能；不得不說客戶是愿意為了便利性犧牲一點安全性的。
最后你們這個功能改了嗎？
改了，還是要考慮特殊情況。
作者可以分享下讀到的那篇商業模式和盈利模式的文章嘛
http://www.aharts.cn/pmd/5232745.html
謝謝作者大大
產品經理要學會去理解產品設計背后邏輯的習慣，這有利于在后續的工作中明確思路和參考。雖然產品都是為了盈利，但也要產品做得好、給用戶好的使用感受才能盈利啊哈哈。
你這名字起得可有些名字了，哈哈哈。安全行業，我以為會給我們普及哪些是安全行業，怎樣在里面進行創業，看完才發現，原來每一個行業，只要不違法，都是安全行業，在自己熟悉的行業內進行創業。
安全的范疇太大了，有業務就需要有安全，安全和業務是互利共生。
客戶有網站有域名，那就需要WAF、抗DDoS產品；用戶有線下機房或者有云主機，那就需要相應的配備主機安全防護產品；有容器就給配容器安全產品；有大量的數據，就需要配數據治理、數據脫敏等數據安全產品；客戶公司規模比較大，就需要配備相應的IDDAS體系。
安全很大，往大了說安全包括身份、日志以及專業的安全服務；狹義的安全包括專業的安全服務，如主機防護、態勢感知等