心靈的港灣

互聯網產品經理常犯的錯誤


你還在犯草根產品經理在犯的錯嗎?

作者:陳濱淋

隨著互聯網的發展,產品經理的需求越發旺盛。而互聯網產品經理沒有對應大學專業。有幸進入大型互聯網公司工作和學習的產品經理畢竟少數。多數產品經理都在經歷著從草根到專業的轉變過程。細數這幾年,自己眼見新人曾經犯過的錯誤,值得深思與總結。

一、關於職能定位

許多產品經理剛入門的時候都是從簡單的原型製造開始,更準確地說應該是臨摹其他產品的相關頁面。

在這個過程中從介面上逐漸去辨別某一個產品功能的好與壞,美與醜。

慢慢地就認為這些就是產品經理這份工作的everything了。他們的目光永遠聚焦在產品的外衣,而對於產品內在的價值和意義思考不深,甚至完全忽略。這樣的產品經理通常只能算一個不專業的交互設計師。

出現這種現象的原因主要是許多公司缺乏對產品經理的認知、判斷、培養的能力。

在不同公司,對產品團隊的工作要求、重視程度差異較大。更直白點說,許多公司缺乏產品經理基因,壓根就不知道招聘什麼樣的產品經理,不知道他們應該做什麼事情。

回到主題,產品經理對自己的職能定位一定要深刻。高度要能俯視整體產品線,廣度要能涉獵更多知識面,深度要能直入業務最本質。忽然想起林夕的歌詞“在高處凝望世界流動”,Yes,這就是產品經理應有的視角!

二、關於需求管理

1、沒有建立完整、客觀的需求獲取通道。需求往往來自運營部門、市場部門或老闆的要求,產品經理淪為需求文檔撰寫者,把別人的想法寫成文檔,交付給技術團隊。這樣的產品經理則淪為傳統軟體發展的需求分析師。要建立完整、客觀的需求獲取通道產品經理必須“眼觀六路,耳聽八方”:定期收集外部使用者對產品的評價和回饋;定期對競爭對手的產品動向進行分析和跟蹤;定期從後臺提取使用者行為資料,

分析使用者行為,通過資料提供產品反覆運算的理論依據;

2、沒有建立合理的需求考評機制。需求漫天飛,永遠不知道哪些需求要做,哪些不做,哪些先做,哪些後做。產品經理要為產品建立需求池,打造需求管理體系。從需求獲取、需求排序、需求分析、需求評審到需求設計、需求開發和需求變更都要有依據和操作規範。

以此來確保整個產品研發方向的合理性,摸索出一個適合市場要求和團隊研發實力的反覆運算節奏。比如反覆運算週期以及每次反覆運算研發團隊能承受的工作量。

三、關於流程管理

流程管理是最容易刨出坑的地方。關於流程方面的問題通常有兩種表現形式。一種是日常化工作沒有形成明確的流程,造成團隊工作混亂。比如關於需求變更流程,如果沒有明確的流程,產品經理在發起需求變更的時候很容易出現資訊傳遞不對等。

團隊應該事先規定清楚,影響程度不同的變更必須上報到哪一個層級。以此來控制需求變更的合理性。需求變更應該通知的範圍,除了技術、測試還應該通知運營團隊甚至老闆。以什麼樣的形式表達需求變更?郵件形式還是需求文檔?這些問題沒有相關流程會造成很多團隊間扯皮、推諉的現象。

另一種情況則是團隊通過討論通過艱難地制定出某一個流程,可是在執行階段出現問題。團隊缺乏執行力,缺乏對流程的培訓機制,缺乏對流程的改進和反覆運算。一個流程正如一個產品,要深入人心需要不斷試錯,升級。因此對於研發團隊中最核心最常見的流程,必須靠強大的執行力來支撐,最終在團隊裡形成一種良性的工作習慣。


四、關於市場調查

在需要聽取到團隊之外的聲音之時,產品經理通常會想到通過市場調查的方式收集資訊。如果產品經理本身對市場調查方面的工作不夠精通,通常會犯這幾類錯:

1、調查目的不明確。每一次市場調研需要當做一個獨立專案去完成,在項目立項之前,就已經有一個明確的方向和目的。比如針對產品的某個指標發起的一次調研。那麼首先需要把這個指標細分成多個相對可量化的指標。在後續調查問卷的設計中,或者用戶訪談問題的設計中都有明確的方向和邏輯。比如,要調查使用者對某個產品使用者體驗的滿意度。可以細分成介面美觀程度、主要流程易用性、主要流程載入速度、還有一些軟性能的滿意度等等。

2、樣本採集不科學。採樣的準確性直接關係最終結果的準確度。在調研中有些問題則必須通過與用戶面談,有些問題則打死不能當面與用戶溝通,必須通過線上問答的形式。比如滿意度,當面去詢問對產品的滿意度,使用者礙於面子給予的回饋通常會比實際想法不符。因此採用的時候要綜合考慮採用的管道、樣本的數量才能得到相對客觀的基礎資料。

3、問卷設計不合理。俗話說上樑不正下樑歪,如果調研的目的和調研邏輯沒梳理清楚,到了問卷設計步驟一定會淩亂。而問卷設計部合理最常見的有如下情況:問題與中心無關、問題描述太籠統、選項不完備、選項不互斥、問題帶有強烈的誘導下等等。

五、關於跨團隊溝通

產品經理在整個大團隊中無疑應該充當”萬金油“的角色。需要平衡不同團隊的特性,在技術面前要積極推動需求的實施,在運營團隊面前則要堅持合理的節奏和原則。溝通能力差的產品經理通常會淪為運營對付技術的工具,或者是技術對抗運營的犧牲品。產品經理不要在團隊裡”搞政治“,卻必須能游刃於團隊間,靠的是過硬的專業技能和人格魅力。

1、在技術面前強調需求的價值,讓程式猿深刻認識到自己開發的功能為何而生。同時建議在需求設計階段就邀請他們參與,多聽取技術的意見,與程式猿建立濃厚的感(ji)情(qing)。

2、在運營面前強調需求合理性,運營通常給出的需求是沒有站在整個產品規劃上來思考的,多數屬於”哪痛帖哪“”指哪打哪“這樣的場景。更不會去考慮需求可行性,天馬行空的需求漫天飛也是正常的。這些無處不在考驗著你的溝通能力!

或許我們都經歷過從草根到專業的過程。本文列舉的問題也未必適用於所有人或團隊。仍然希望對廣大新入門的產品汪有所説明。
產品經理在發起需求變更的時候很容易出現資訊傳遞不對等。

團隊應該事先規定清楚,影響程度不同的變更必須上報到哪一個層級。以此來控制需求變更的合理性。需求變更應該通知的範圍,除了技術、測試還應該通知運營團隊甚至老闆。以什麼樣的形式表達需求變更?郵件形式還是需求文檔?這些問題沒有相關流程會造成很多團隊間扯皮、推諉的現象。

另一種情況則是團隊通過討論通過艱難地制定出某一個流程,可是在執行階段出現問題。團隊缺乏執行力,缺乏對流程的培訓機制,缺乏對流程的改進和反覆運算。一個流程正如一個產品,要深入人心需要不斷試錯,升級。因此對於研發團隊中最核心最常見的流程,必須靠強大的執行力來支撐,最終在團隊裡形成一種良性的工作習慣。


四、關於市場調查

在需要聽取到團隊之外的聲音之時,產品經理通常會想到通過市場調查的方式收集資訊。如果產品經理本身對市場調查方面的工作不夠精通,通常會犯這幾類錯:

1、調查目的不明確。每一次市場調研需要當做一個獨立專案去完成,在項目立項之前,就已經有一個明確的方向和目的。比如針對產品的某個指標發起的一次調研。那麼首先需要把這個指標細分成多個相對可量化的指標。在後續調查問卷的設計中,或者用戶訪談問題的設計中都有明確的方向和邏輯。比如,要調查使用者對某個產品使用者體驗的滿意度。可以細分成介面美觀程度、主要流程易用性、主要流程載入速度、還有一些軟性能的滿意度等等。

2、樣本採集不科學。採樣的準確性直接關係最終結果的準確度。在調研中有些問題則必須通過與用戶面談,有些問題則打死不能當面與用戶溝通,必須通過線上問答的形式。比如滿意度,當面去詢問對產品的滿意度,使用者礙於面子給予的回饋通常會比實際想法不符。因此採用的時候要綜合考慮採用的管道、樣本的數量才能得到相對客觀的基礎資料。

3、問卷設計不合理。俗話說上樑不正下樑歪,如果調研的目的和調研邏輯沒梳理清楚,到了問卷設計步驟一定會淩亂。而問卷設計部合理最常見的有如下情況:問題與中心無關、問題描述太籠統、選項不完備、選項不互斥、問題帶有強烈的誘導下等等。

五、關於跨團隊溝通

產品經理在整個大團隊中無疑應該充當”萬金油“的角色。需要平衡不同團隊的特性,在技術面前要積極推動需求的實施,在運營團隊面前則要堅持合理的節奏和原則。溝通能力差的產品經理通常會淪為運營對付技術的工具,或者是技術對抗運營的犧牲品。產品經理不要在團隊裡”搞政治“,卻必須能游刃於團隊間,靠的是過硬的專業技能和人格魅力。

1、在技術面前強調需求的價值,讓程式猿深刻認識到自己開發的功能為何而生。同時建議在需求設計階段就邀請他們參與,多聽取技術的意見,與程式猿建立濃厚的感(ji)情(qing)。

2、在運營面前強調需求合理性,運營通常給出的需求是沒有站在整個產品規劃上來思考的,多數屬於”哪痛帖哪“”指哪打哪“這樣的場景。更不會去考慮需求可行性,天馬行空的需求漫天飛也是正常的。這些無處不在考驗著你的溝通能力!

或許我們都經歷過從草根到專業的過程。本文列舉的問題也未必適用於所有人或團隊。仍然希望對廣大新入門的產品汪有所説明。