請把“產品經理”這后面的“經理”兩個字去掉!
產品經理大多數人身處的卻是“互聯網行業”的“產品執行”,行業成熟度上就差了不是一個level,產品管理和產品執行更是相差了整整一個“經理級”辣么遠…
前兩天,在知乎上看到個很有意思的問題,大概是:
問題:產品經理對細節需要給到什么程度,才不會被開發罵?
描述:
- 公司為創業團隊,沒有特別細分的人員安排,之前都是開發自己完成交互設計和視覺設計的,因為體驗太爛成立了產品部,現有兩人。
- 題主對產品管理的工作的認知為規劃和立項,工作基本內容圍繞:項目任務書(目標市場、產品定位、可行性分析、目標成本和銷售目標等)、產品需求包(需求描述、用戶場景、優先級)。
- 從后文的描述中感受到題主認為的需求分析就是告訴開發要做某個功能,其他所有關乎這個功能的邊界、判斷、異常條件都由開發自己搞定。開發提出疑問的時候,題主因為要調研下個版本的需求而對這種類型的疑問感到不勝其煩。
槽點太多了,對吧?
產品經理們,就是太會把自己當作經理了。年紀輕輕的,學啥不好、干啥不好,偏偏要跟人學經理派頭。
我記得大三自己考慮未來做什么的那段時間,權衡了各方面客觀和主觀因素,最終選擇了“產品”這個角色作為進入互聯網世界的暫時優先選擇。
選擇完后,想從宏觀上細致了解現有的產品經理的角色到底是干嘛的,然后故意啃了一本死厚死厚的講傳統行業產品經理的書,書名是《產品經理的第一本書》,喏,就是下面圖片這貨:
當時看完,那真的是有種氣吞山河的氣勢,原來產品經理這么牛掰,每天在都斡旋于各種部門之間、運籌帷幄產品“大”事件,想想畢業后要做這個,還有點小激動呢,自我心略膨脹啊,改變世界就在眼前。
到了工作之后才真正體會到,人家那本書說的是“傳統行業”的“產品管理”,但是我們大多數人身處的卻是“互聯網行業”的“產品執行”,行業成熟度上就差了不是一個level,產品管理和產品執行更是相差了整整一個“經理級”辣么遠…
一個“經理級”辣么遠,到底是有多遠?
我個人認為,能真正被稱為產品經理的人,至少具備以下點:
1、?熟練產品本身的工作:
- 從0-1為何開始?如何開始?(行業認知?競品分析?…)
- 每個版本做什么以及依據?(是數據分析了?還是用戶調研了?還是市場反饋了?還是補技術債?還是第三方合作了?…)
- …
2、?熟練產品迭代過程中涉及結合的運營(新媒體、投放…)、商務(第三方合作…)的結合點和大致工作內容;
3、?熟練管理(團隊人員管理?迭代版本管理?資源協調?…)
以上的熟練是真的熟練進而生巧,同時對自己的決策有把握。做一次二次那不叫熟練。
簡單來說,就是知道如何帶領團隊做一款好產品,然后賣出去。個人認為,這個要求是極高的,沒有長時間的積累是不可能的。
而現在市面上,因為“人人都是產品經理”這個口號(雖然本意是好的),但是確實也是把經理二字的意義拉低了。
然而小小年紀的我們,又不懂,“經理”二字無形中會影響我們對產品工作的認知,比如文章開始的知乎那個問題,多了很多不知道哪兒來的不切實際,少了很多應該有的腳踏實地。
沒有日常對行業、對用戶的一點點的積累和認知,怎么得出的目標市場、產品定位?
沒有對產品細節、運營、商務的理解,怎么得出的目標成本、銷售目標?
沒有強有力的邏輯分析、交互理解,怎么來的需求描述、用戶場景?
沒有和其他部門例如運營、廣告、商務的對接結合產品的綜合考慮,怎么來的需求優先級?
腦袋里想的都是:我要做大事、我要立產品方向、我要寫MRD…你能對你寫的東西負責嗎?
產品方向定錯了,你擔得起責任嗎?
不要以為所謂的立項就僅僅是立項,如果通過了,還需要大把人和你一起做這個項目呢,說大了還得對和你一起付出的設計開發測試們負責呢,有時候你一句話人家就得改一天代碼呢。
厲害的只是產品經理這個title,并不代表你自己厲害。臺上一分鐘,臺下十年功,所有給出的好的產品方案,都離不開平時一點一滴的腳踏實地。
那么,接地氣的產品又每天在做什么呢?
1、用自己的產品和競爭產品
- 作為行業產品的用戶,會慢慢有用戶的心態,同時心態還會漸變,整體對產品的理解會擴大一個維度,更加容易從用戶角度上看待問題;
- 作為競品的用戶,可以從競爭對手的變化中,發現同行厲害的點或者驗證自己想做沒做但同行做了的效果;
- 作為自己的用戶,會更清楚的感受到產品有哪些問題、需要優化的又是什么;
俺們選股寶團隊里每天用時最久的是技術老大昊神(又稱比特幣礦主),常年排在用戶每日用時榜前三,經常提出一些體驗上的優化。對于這種技術老大,也是沒sei了。
2、看用戶嘮嗑、和用戶嘮嗑
- 每天都會看看自己產品的用戶群里在討論什么,從用戶的討論中可以感受一部分的用戶痛點、用戶思維決策方式,從而可能有利于產品、運營;
- 在后臺反饋或者用戶群中看到有想法的用戶留言或者發言,抓出來,和他們討論,有時候能夠爆發出一些有趣的東西;
3、看和分析產品運營數據
相比少數人的“我以為”、“我覺得”,我更相信廣泛意義上的統計數據的力量。
數據會告訴我們:
- 用戶更喜歡這里的內容,但是停留在那里的時間更久;
- 用戶更習慣于從這里接受推薦,但是又有自己的使用路徑;
- 這種推廣方式用戶不買賬,那種活動方式用戶更愛一些;
- …
當然,數據可能會因為各種原因摻了假或者因為雞生蛋蛋生雞的循環而騙我們,但是,還是一樣的道理,好好用就都有用。
4、管理需求池
暫未解決的bug、需要優化的部分、可以新增的功能…
產品本身的、其他部門需要的…
需要不斷的維護和管理,方便了解產品現有狀況和有利于列出下個版本的迭代需求list。
5、迭代中和開發、設計、運營的溝通
這個工作列出來好像看起來非常廢話,但其實不然。
迭代初期:和開發溝通溝通需求、和設計師細節溝通和一次次確認設計稿…
迭代中期:和開發偶爾調整需求細節、和設計師溝通引導頁、歡迎頁、廣告頁、應用商店宣傳圖等、和內容運營討論和確認活動…
迭代后期:和運營、內容最終確認活動相關入口和素材、和投放確認投放素材、和開發測試確認最后的版本情況…
以上的內容還不是全的,有些還是相互穿插的。除了這些之外,人不能保證自己一定沒有疏漏的時候:
需求分析漏了一個判斷啦、臨時加的一個需求有問題啦、設計稿不符合android的特性啦(蘋果爸爸大法好)、溝通問題導致開發人員沒有做這個需求啦、設計素材缺了啦、臨時有重要bug啦、打包版本打錯了啦、證書過期了啦、產品從屬關系有問題啦…
真正迭代開發的時候,什么事情都有可能出現,當然,可能大公司制度完善,開發時間長一些,可以一定程度減少這類事情的發生。但是,完美計劃的完美執行,這幾個字一定是個夢。
產品需要臨時或者一直去協調這些東西,并不是一件容易的事情,尤其狀況一起出現的時候。
6、和第三方合作
工作并不會像你預計的那樣一步一步走,有時候經常是你想好了明天要做什么、下周要做什么、這個月要做什么,然后第二天立馬就pia pia pia打臉。
這個第三方想跟我們合作,要去具體聊一下合作方案如何以及之后的技術對接;
那個第三方要跟我們用另一種方式合作,得評估下性價比;
那個想跟我們合作整一個定制版,還得考慮和自己產品的差異性;
花樣不要太透喲喲喲…
打亂你一兩天的工作優先級那倒還好,有時候合作力度大了,還可能會影響你整個月、整個季度的工作安排。
7、確定下個版本的需求及需求分析
這個工作很日常啦,主要就是確定下個版本做什么、畫出迭代的原型圖同時附上每個需求的相對細致的業務條件、邊界條件、判斷條件。不過,這個工作還是和以上提到的的其他工作穿插在一起的。
日常工作暫時先list到這里,肯定是有漏掉的,不過不影響主旨嘛。
“產品經理”,是我們的目標,沒有錯,但在實現目標的過程中,一步步走好當下的日常,才是現階段我們要做的。
“志存高遠,腳踏實地”,以此共勉之…
最后來個偏題的ps吧-
對于知乎那個問題,不說題主的想法有問題,同時我覺得題主根本就不適合創業公司。
創業公司哪來的流程明確、人員分工明確?一人一小細坑,那尼瑪,項目進展得多慢啊~
創業公司人少,但事兒還是一樣多,分分鐘有個鍋就得接著,不接就推進不了了哎喂。
想cover掉多少,由責任心決定;能cover 掉多少,由能力和付出的時間決定;
像我寶團隊,設計大大也討論產品的交互設計;開發也經常提出對產品上的意見,有些是交互上的不合適,還就自己默默就做掉了優化…
責任心不夠,千萬別入創業公司。
#專欄作家#
killifer,微信公眾號:killifer,金融資訊&工具類產品經理。腦洞大、笑點低、間歇性“有毛病”的理工科實力逗比少女。
本文原創發布于人人都是產品經理,未經許可,不得轉載。
謝謝分享,請問你寫一篇文章花多長時間寫完的?
。。??磳懙膬热萆顪\問題吧。不過都寫的比較慢,平均也要一下午吧。。。
工科女你好,我是工科男,你好搞siao
哪里搞siao
碰到一個有趣的工科女~ ??
蛤蛤~~快粉我,快粉我~~ ?? ?? ??
給小朋友贊一個
?? ?? ??
多少人都是被經理二字吸引了…去掉才是工作實質
我一直覺得好的產品經理有很多必備的能力和技能,但是有兩個最不可能少:
1、辨析需求的準確度
不能說產品經理挖掘的用戶需求就是正確的,但是在產品迭代中所要圍繞的點,它準確度慢慢提高,也意味著產品越來越少了眾多的試錯,也會更有機會成為好產品
2、產品設計的完美度
雖然不能達到完美,卻要追求完美,不需要研發替你考慮到什么,在產品規劃和設計時,作為產品就應該想到這些。完整性和預見性缺一不可。
啊哈~贊同,第一點體現的是對用戶、對業務的理解,第二點體現的是邏輯分析的能力~
說的好有道理,同為產品狗深有同感,樓主描述很多情況都在工作碰到了