你還在犯草根產品經理在犯的錯嗎？
作者：陳濱淋
隨著互聯網的發展，產品經理的需求越發旺盛。而互聯網產品經理沒有對應大學專業。 有幸進入大型互聯網公司工作和學習的產品經理畢竟少數。多數產品經理都在經歷著從草根到專業的轉變過程。細數這幾年，自己眼見新人曾經犯過的錯誤，值得深思與總結。
一、關於職能定位
許多產品經理剛入門的時候都是從簡單的原型製造開始，更準確地說應該是臨摹其他產品的相關頁面。在這個過程中從介面上逐漸去辨別某一個產品功能的好與壞，美與醜。
慢慢地就認為這些就是產品經理這份工作的everything了。他們的目光永遠聚焦在產品的外衣，而對於產品內在的價值和意義思考不深，甚至完全忽略。這樣的產品經理通常只能算一個不專業的交互設計師。
出現這種現象的原因主要是許多公司缺乏對產品經理的認知、判斷、培養的能力。
在不同公司，對產品團隊的工作要求、重視程度差異較大。更直白點說，許多公司缺乏產品經理基因，壓根就不知道招聘什麼樣的產品經理，不知道他們應該做什麼事情。
回到主題，產品經理對自己的職能定位一定要深刻。高度要能俯視整體產品線，廣度要能涉獵更多知識面，深度要能直入業務最本質。忽然想起林夕的歌詞“在高處凝望世界流動”，Yes，這就是產品經理應有的視角！
二、關於需求管理
1、沒有建立完整、客觀的需求獲取通道。需求往往來自運營部門、市場部門或老闆的要求，產品經理淪為需求文檔撰寫者，把別人的想法寫成文檔，交付給技術團隊。這樣的產品經理則淪為傳統軟體發展的需求分析師。 要建立完整、客觀的需求獲取通道產品經理必須“眼觀六路，耳聽八方”：定期收集外部使用者對產品的評價和回饋；定期對競爭對手的產品動向進行分析和跟蹤；定期從後臺提取使用者行為資料，分析使用者行為，通過資料提供產品反覆運算的理論依據；
2、沒有建立合理的需求考評機制。需求漫天飛，永遠不知道哪些需求要做，哪些不做，哪些先做，哪些後做。產品經理要為產品建立需求池，打造需求管理體系。從需求獲取、需求排序、需求分析、需求評審到需求設計、需求開發和需求變更都要有依據和操作規範。以此來確保整個產品研發方向的合理性，摸索出一個適合市場要求和團隊研發實力的反覆運算節奏。 比如反覆運算週期以及每次反覆運算研發團隊能承受的工作量。
三、關於流程管理
流程管理是最容易刨出坑的地方。關於流程方面的問題通常有兩種表現形式。一種是日常化工作沒有形成明確的流程，造成團隊工作混亂。比如關於需求變更流程，如果沒有明確的流程，產品經理在發起需求變更的時候很容易出現資訊傳遞不對等。
團隊應該事先規定清楚，影響程度不同的變更必須上報到哪一個層級。以此來控制需求變更的合理性。需求變更應該通知的範圍，除了技術、測試還應該通知運營團隊甚至老闆。以什麼樣的形式表達需求變更？郵件形式還是需求文檔？這些問題沒有相關流程會造成很多團隊間扯皮、推諉的現象。
另一種情況則是團隊通過討論通過艱難地制定出某一個流程，可是在執行階段出現問題。團隊缺乏執行力，缺乏對流程的培訓機制，缺乏對流程的改進和反覆運算。一個流程正如一個產品，要深入人心需要不斷試錯，升級。因此對於研發團隊中最核心最常見的流程，必須靠強大的執行力來支撐，最終在團隊裡形成一種良性的工作習慣。
四、關於市場調查
在需要聽取到團隊之外的聲音之時，產品經理通常會想到通過市場調查的方式收集資訊。如果產品經理本身對市場調查方面的工作不夠精通，通常會犯這幾類錯：
1、調查目的不明確。每一次市場調研需要當做一個獨立專案去完成，在項目立項之前，就已經有一個明確的方向和目的。比如針對產品的某個指標發起的一次調研。那麼首先需要把這個指標細分成多個相對可量化的指標。在後續調查問卷的設計中，或者用戶訪談問題的設計中都有明確的方向和邏輯。比如，要調查使用者對某個產品使用者體驗的滿意度。可以細分成介面美觀程度、主要流程易用性、主要流程載入速度、還有一些軟性能的滿意度等等。
2、樣本採集不科學。採樣的準確性直接關係最終結果的準確度。在調研中有些問題則必須通過與用戶面談，有些問題則打死不能當面與用戶溝通，必須通過線上問答的形式。比如滿意度，當面去詢問對產品的滿意度，使用者礙於面子給予的回饋通常會比實際想法不符。因此採用的時候要綜合考慮採用的管道、樣本的數量才能得到相對客觀的基礎資料。
3、問卷設計不合理。俗話說上樑不正下樑歪，如果調研的目的和調研邏輯沒梳理清楚，到了問卷設計步驟一定會淩亂。而問卷設計部合理最常見的有如下情況：問題與中心無關、問題描述太籠統、選項不完備、選項不互斥、問題帶有強烈的誘導下等等。
五、關於跨團隊溝通
產品經理在整個大團隊中無疑應該充當”萬金油“的角色。需要平衡不同團隊的特性，在技術面前要積極推動需求的實施，在運營團隊面前則要堅持合理的節奏和原則。溝通能力差的產品經理通常會淪為運營對付技術的工具，或者是技術對抗運營的犧牲品。產品經理不要在團隊裡”搞政治“，卻必須能游刃於團隊間，靠的是過硬的專業技能和人格魅力。
1、在技術面前強調需求的價值，讓程式猿深刻認識到自己開發的功能為何而生。同時建議在需求設計階段就邀請他們參與，多聽取技術的意見，與程式猿建立濃厚的感（ji）情（qing）。
2、在運營面前強調需求合理性，運營通常給出的需求是沒有站在整個產品規劃上來思考的，多數屬於”哪痛帖哪“”指哪打哪“這樣的場景。更不會去考慮需求可行性，天馬行空的需求漫天飛也是正常的。這些無處不在考驗著你的溝通能力！
或許我們都經歷過從草根到專業的過程。本文列舉的問題也未必適用於所有人或團隊。仍然希望對廣大新入門的產品汪有所説明。
比如，要調查使用者對某個產品使用者體驗的滿意度。可以細分成介面美觀程度、主要流程易用性、主要流程載入速度、還有一些軟性能的滿意度等等。
2、樣本採集不科學。採樣的準確性直接關係最終結果的準確度。在調研中有些問題則必須通過與用戶面談，有些問題則打死不能當面與用戶溝通，必須通過線上問答的形式。比如滿意度，當面去詢問對產品的滿意度，使用者礙於面子給予的回饋通常會比實際想法不符。因此採用的時候要綜合考慮採用的管道、樣本的數量才能得到相對客觀的基礎資料。
3、問卷設計不合理。俗話說上樑不正下樑歪，如果調研的目的和調研邏輯沒梳理清楚，到了問卷設計步驟一定會淩亂。而問卷設計部合理最常見的有如下情況：問題與中心無關、問題描述太籠統、選項不完備、選項不互斥、問題帶有強烈的誘導下等等。
五、關於跨團隊溝通
產品經理在整個大團隊中無疑應該充當”萬金油“的角色。需要平衡不同團隊的特性，在技術面前要積極推動需求的實施，在運營團隊面前則要堅持合理的節奏和原則。溝通能力差的產品經理通常會淪為運營對付技術的工具，或者是技術對抗運營的犧牲品。產品經理不要在團隊裡”搞政治“，卻必須能游刃於團隊間，靠的是過硬的專業技能和人格魅力。
1、在技術面前強調需求的價值，讓程式猿深刻認識到自己開發的功能為何而生。同時建議在需求設計階段就邀請他們參與，多聽取技術的意見，與程式猿建立濃厚的感（ji）情（qing）。
2、在運營面前強調需求合理性，運營通常給出的需求是沒有站在整個產品規劃上來思考的，多數屬於”哪痛帖哪“”指哪打哪“這樣的場景。更不會去考慮需求可行性，天馬行空的需求漫天飛也是正常的。這些無處不在考驗著你的溝通能力！
或許我們都經歷過從草根到專業的過程。本文列舉的問題也未必適用於所有人或團隊。仍然希望對廣大新入門的產品汪有所説明。
