我所見過的那些「低效」產品經理

產品老司機手把手教寫文檔,10天線上課程,零基礎掌握產品經理必備7大文檔撰寫法。了解一下>

就在前期準備的過程,不斷和同事、合作伙伴磨合的過程中,我發現了很多行業里、職場里的詬病,這些詬病最大的危害不僅能浪費你最寶貴的時間,還分分鐘能帶你跑偏,讓你最后無所適從。本文給大家講講關于大家為什么會低效而存在的問題。

這段時間真的忙,忙新產品的上線,所以上周的文章也沒有更新,以后我會更合理安排時間,拒絕斷更。

如果我沒有記錯,這已經是我第五個從0到1的產品了,所謂從0到1就是從業務規劃層面開始,直到產品上線產生營收,都由我自己直接負責,當中大概還有十五六個必要步驟。

這五個產品,前三個算是徹底涼涼了,第四個還在茍延殘喘當中,但每一個都有進步,都更接地氣、更有利于實現商業價值和用戶價值的平衡。所以這次這個我努力一下,爭取一把,希望不讓大家失望。

就在前期準備的過程,不斷和同事、合作伙伴磨合的過程中,我發現了很多行業里、職場里的詬病,這些詬病最大的危害不僅能浪費你最寶貴的時間,還分分鐘能帶你跑偏,讓你最后無所適從。

所謂低效,就是事倍功半,這是所有人都不希望看到的結果。在我以下歸納的這些問題當中,幾乎具有職業的普適性,放在哪個職位上來看,都大概率存在。

為了更通俗易懂,我就從產品經理說起:

一、對專業領域仍然一無所知

自打社會分工以來,行業各領域被刻意細分,本著專業的人解決專業的問題,提高決策的準確性、效率和行業影響力。

但越來越多的人,在專業領域上是一無所知的,仍然用著行業外的解決辦法去解決行業內的專精問題。更有時候,連行業外的通用解決辦法都沒有摸熟摸透,只能在上項目的時候不斷摸索。

我見過不少的產品經理,提出來的很多需求,是很茫然的,既不提升商業價值,也不提升用戶價值,效果還不能量化,先不說這個需求是不是一個偽需求,就本身而言,就存在兩個不能解決的問題:

(1)就算做了,有什么作用呢?

(2)就算做了,怎么定義它是做好了呢?

很多需求評審完了,技術也進入開發了,整個項目周期過去了,在復盤的時候才發現這兩個問題不可解決,何其憂傷。

判斷項目的投入產出,需求開發優先級,效果驗證這本來就是產品經理的職責所在,除了你必須要推進的需求部分,這些前置的判斷是你要替整個團隊去考慮的,不然要你來干嘛。

這種準確性缺失,效率低下,在項目開發推進中,都是極其致命的,歸根結底就是一個問題:絕大部分人沒有用專業的解決辦法來處理問題,又或者大部分人對專業領域的東西仍然一無所知。

建議:在必要工作之余的時間內,多補補課,平時多留意一下做得好的人為什么能做好。

二、感到困惑,但歸納不出是什么問題

工作上會困惑,遇到問題,這是很正常的,但是大部分感到困惑的同時,問題始終得不到解決,很大部分的原因是:他根本不知道遇到的是個啥問題?

很多時候,先不要去思考解決方案,能把自己遇到的問題歸納清楚,清晰地寫出來,這就已經解決一半了。

別不信,還真的是,人的大腦習慣概念化,抽象化地表達,你腦子里面有了這個問題的大概脈絡,很多時候真的只是個大概,需要進一步具體地表達出來。

很多人都是解決問題的高手,真的,只是很多時候他們不知道問題是什么罷了。

建議:多問自己幾句,我現在遇到的到底是個什么問題?

三、會排優先級,但從不按優先級處理問題

之所以有優先級的存在,就是說明有些東西是可以放棄的。不是說列出來的清單都需要全部做完,評審過的需求都要全部開發,只是說在有限的時間里,我們要把最最最重要的給做了。

這個解釋一點都不陌生,大家都懂,但是一回到工位上,就立馬變樣了,左一封郵件,右一個釘釘,完全忘記自己三分鐘前排好的優先級。

二八定律適合用在很多領域,如果你接觸的數據面夠廣,基本上你會發現所有的事情客觀上都被二八定律所劃分。

我統計過,有時候為了讓產品的某一部分得到真正提升,我實際上花了三天去出產品方案,但是只有差不多大半天左右做出來的東西是起著決定性作用的。也就是說我剩下的那兩天多做出來的東西,做與不做影響都不會特別大,只要把前面的做好即可,后面都只是錦上添花。

所以相應地,留給前面這些重要環節的思考時間,一定要是最充足,而且最需要給予重視的。工作不一定要全部都做完,只要把最重要的做完做好就可以了。

如果你還是覺得所有的都重要,就是你的優先級處理有問題。

建議:排完優先級,每天嚴格執行,除非部分插入進來的事情能在五分鐘內解決或者不做會死,否則都丟到后面排隊。

四、經常開會,而且經常沒有結論

一直到現在,我都很討厭開會,尤其是那些漫無目的,永遠只停留在想法和創意上的頭腦風暴。

腦暴這個詞不知道是從什么時候突然就流行起來,似乎什么解決不了的事情,只要三五個人,浪費一個上午的時間,腦暴一下就能得出結果,這種會議大部分時候都是自欺欺人。

總的來說會議有三種:

  • 面向上級的叫匯報,目的是為了請求資源去推進某些事并同步進度;
  • 面向下級的叫例會,目的是為了布置任務并同步進度;
  • 最后面向同級的叫討論會,目的是為了尋求最優的解決辦法。

既然是尋求最優的解決辦法,那么肯定要先有一些候選的解決辦法,這樣子在開會的時候才能通過了解各自的想法,權衡出最優解,把每個人的結論綜合出一個會議結論,這才是最高效直接的做法。

而現實當中,那些所謂的腦暴,是利用會議的時間去構思候選的解決辦法,可謂浪費至極。大家在完全沒有準備,沒有一點兒深入思考過的時候,所提出的一切假設都是沒有意義的。

尤其是產品前期的規劃會議,很容易變成自嗨的場所。

建議:不要經常開會,除非大家已經有了初步的結論,獨處的時間更高效珍貴。

五、跨部門溝通,沒讓大家明白業務目的

沒有一個人,能有時間把所有的事情都自己做完,也沒有一個人能擅長所有的領域,隨著產品在規劃過程中不斷地推進,跨部門的合作,越來越變得不可避免。但在我自己日常的觀察當中,發現并不是很多人懂得如何去跨部門溝通,尤其作為一個產品經理,你統籌不了產品部以外的部門資源,是很難保證你的需求順利推進的。

而那些溝通不當,或者達不到溝通目的的人通常都會犯下一個錯:沒在一開始的時候讓大家明白業務的目的是個啥。

這個很重要,因為跨部門的同事對我們來說一般都比較陌生,尤其在大公司里面,他們無法從過往和你合作的經歷去判斷出你的能力,這個時候他們還要分出額外的精力去幫助你完成看起來只屬于你的業務目的,這不坑爹嗎?

別人怎么可能有耐心和激情跟著你一直干下去?我見過很多統籌人一上來就blabla說要這要那因為要做成這個東西,而這個東西做好之后能有什么用,所有人都不得而知,最后大家聽完似乎都懂了,但是回到工位上卻貌合神離。

需要跨部門合作的業務,一定是具有集體意識的,也就是說這個業務目標一定是頂層的,如果你僅僅從自己能看到的地方出發,先不說別人幫不幫你,你努力的方向一定是有問題的。

建議:跨部門溝通之前,把項目背景交代清楚,還要把大家做這件事的目的確定下來,并確保大家認可。

總結

以上5點,都來自于日常的工作推進,我所能發現并大概率會重復出現的問題,無疑,這些問題日益積累,會讓你的努力付諸東流。

引用第3個問題的結論,一件事最后能做得怎么樣,很多時候就取決于那20%重要的工作有沒有做好。

很顯然,這就是那20%。

#專欄作家#

雅格布,微信公眾號:雅格布(ID:jacoblab),人人都是產品經理專欄作家。策略型產品經理,擅長需求挖掘以及產品增長,重點關注金融、游戲和社區領域,并對此類產品從0到1有啟發性的實戰思考。

本文原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自Unsplash,基于CC0協議

給作者打賞,鼓勵TA抓緊創作!
評論
歡迎留言討論~!
  1. 感到困惑,但歸納不出是什么問題,真的經常會有這種情況,一定要先多花點時間梳理問題,再想解決方案。學到了!

    回復
  2. 受益匪淺,收藏了

    回復
  3. 求教一下大家:需求的量化怎么理解呢?

    回復
  4. 講的很到位,敘述背景.明確目的.共同認可

    回復
  5. 說的對

    回復
    1. 自行車自行車

      回復
  6. 現在就是越到了這樣的困惑,自由好多事情,拍了優先級,但是有被微信郵件開會打斷。最后什么事情也沒干好。項目緊急自己想著要一下子把所有事情解決。但是發現事情越來越多,多的想要逃避。感覺壓力很大

    回復
    1. 是的

      回復
    2. 干就完了

      回復
  7. “提出來的很多需求,既不提升商業價值,也不提升用戶價值,效果還不能量化”,哎,費力不討好的事兒,最近干的真不少,寫的很到位,產生了很多共鳴 :cry:

    回復
  8. 第二點“感到困惑,但歸納不出是什么問題”,這應該是作者以及我都有深刻感觸的問題:腦子里有概念,但要復述出來的時候會礙于記憶或者文筆。以至于說的很多東西懂的人才懂。 于我,需要做的就是多復述

    回復
  9. 嚴謹對待問題與養成良好分析思維確實是一個好PM的基本條件,在看這篇文章時我也在反省當前的工作或以前的項目是否有犯過文中的錯誤,不能怠惰散漫

    回復
  10. 感覺寫的就是我~~~ ;-)

    回復
马总会三肖中特