「產品管理」目前出現的四大變化:論「產品經理」的終極奧義

「產品經理」,從一開始,科技公司對這個角色不認可,不需要,到現在科技公司都有一個這樣的崗位設置。他到底職能是什麼? 「產品管理」從過去到現在再到未來,經歷著怎樣微妙且具有重大意義的變化?一個真正優秀的產品經理應該是什麼樣子。這篇文章非常透徹地講明白了一切。無論是目前正在為招聘「產品經理」的公司,又或者是立志要以「產品經理」作為切入點進入科技圈的年輕人來說,這都是一篇不可多得的好文章。
評論
評論

本文來自於:Medium《The Past and Future of Product Management》,TECH2IPO 翻譯

本文是基於我過去的從業經驗,觀察、以及犯下的許多錯誤中總結而來的。

如果要高度凝練總結一下本文的觀點,如下所示:

  • 我相信產品管理的未來建立在我們對人類複雜性的洞悉上,體現在開發產品的進程中以及藉以了解客戶的數據裡。
  • 我相信產品管理是一項具有決定意義的支持性輔助性角色,而不是某種「遠見性」角色。
  • 我相信如果在「硬技能」(專業性知識)與「軟技能」(人際交往、組織協調等不容易被評估的能力)之間做出界限清楚的劃分,這將給公司的生產力帶來極大的阻礙作用。而最優秀的產品經理往往具有一種「連接性」的作用,能夠將一個組織中的各個角色,各種立場銜接貫通。
  • 傳統產品經理的角色定位,技能檔案中範疇擬定的太窄,有些時候還會出現錯誤的方向。而對於一個真正偉大的產品經理來說,他的角色應該超越於「會設計的工程師」和「會編程的設計師」之上。

如果你對上面的結論感到疑惑、不解、甚至是強烈反對,請繼續讀下去。

首先要先給大家分享一下在過去的 5 年時間裡產品管理所出現的四大轉變,這四大轉變共同指向的盡頭便是產品管理的未來。

產品經理的必要性

在開始描述這四個轉變之前,我想要先指出另外的一個轉變。當我剛開始以產品經理的身份工作的時候,這個問題經常出現在耳邊:「為什麼我應該聘請一位產品經理呢?」在一些狀況中,我經常聽到 CTO 和專注與技術的創始人吹噓自己的豐功偉績:在不需要產品經理的前提下就將軟體開發出來。產品經理有些時候被視為一種「必要之惡」,一種對公司組織架構和損益表的妥協。

往往這樣想法的背後

都是認為產品經理無非是「二級工程師」,他們無法擔當純技術的角色。你需要一個工程師來真正把軟體開發出來不是嗎?產品經理說好聽點「錦上添花」,說不好聽點就是對「寫程式」和「配置代碼」這些「實質性工作」的阻礙。

就算在如今的很多公司,這樣的想法仍然存在,但是我已經很少碰到了。相反,人們經常問的問題是:「我該怎麼去找來一位產品經理?」

為什麼會出現這樣的變化,我想部分原因是因為現在很多高調宣傳的高科技產品往往無法達到開發人員的預期。將軟體開發出來,我指的是任何一種類型的軟體,把這個想法作為終極目標,比 5 年前要難太多。如今的風投們都越來越關心那些專注於提升收入,真正了解市場的公司, 所以難怪會出現從「開發出來軟體」到「開發正確的軟體出來」的轉變。

但問題就恰好出在這裡。為了達到這個目標,一個人或者一個團隊所需要的技能組合空前的複雜。招聘一個工程師本身就是一件很困難的事,但是招聘一個能夠掌管人力組織以及系統就更難了。前者無非局限在技術層面精研深究,而後者考量的是更加綜合的能力。當越來越多的公司都承認產品管理的重要性,自然而然圍繞著這個話題產生了無數的焦慮以及困惑, 比如「到底怎樣才能成為一名好的產品經理」以及「如何尋找到他們」。

第一個轉變:從 Agile 向 agile 的轉變

FktVJtYVjF9f__Zhk4vXf_S2YJzm

我相信關於這些問題的答案是隨著時間的變化而不斷演變的。如今我願意跟大家分享我所觀察到,思考到的一些轉變,尤其是在成為「優秀」產品管理者的這個話題上。第一個轉變是在開發方式上的,它從首字母大寫的「靈活」(Agile)轉變為首字母小寫的「靈活」(agile)。

這是什麼意思呢?從最初的形式上來看,「Agile」這個詞因為其首字母大寫而具有了一定的宣言成分,它是某種價值觀的確立,為了鼓勵「靈活開發」,它下面應該有一套價值觀做其支撐。從最純粹的形式上來看,「Agile」意味著尊重每一個個體的複雜度,承認,接受無法避免的變數。

從這樣的理念延伸出來一整套方法論,比如越來越細化的開發流程和工具,每一個都有著自身文件以

及一系列的規則。感覺上,這一切似乎都讓招聘產品經理不再變成一件難事。你只需要從這個宏大系統中選擇其中一個流程,針對這個流程選擇想對應的專家,工作就完成了。

但這樣的方法論有著非常嚴重的局限性。很明顯,這意味著你所僱傭的這個人必須對某一系列的知識內容有相當程度的掌握,同時還要有一些特定的經驗,招聘的訴求點並沒有瞄準到那些精於適應,快速思考的人才身上。而這些人正是如今小寫的「agile」所需要的人才。

對於剛開始學習「靈活開發」的人來說,最有效的途徑就是去遵循某些簡單的,不考慮任何情境的規則了。「只要發生了這樣的情況,那就這麼做。」自然靈活開發給了人一套方法論之後,很多人很容易就入了門,然後就沒有然後了,就卡在原地不動了。

當別人問起你在幹嘛的時候,你會說「我在學習靈活開發啊」,然後就鑽到了一套沒有什麼實際用途的規則當中不可自拔,反正你也不會因為學習這個而被解僱掉嘛。直到要把產品真正開發出來的時限將至,然後所有人都慌了。

從 Agile 到 agile,這是產品管理領域所發生的一次重大轉變,而且這種轉變給每一個人都帶來了不小的挑戰。公司正在意識到產品管理並不僅僅是選擇正確的流程,它是因地制宜,在自己公司的內部打造出來一套工作辦法!

FhKtcUfz0KAeT9uMiKj3VSAi299U

什麼是「工作辦法」呢?其實產品管理有點兒像做瑜伽或者靈修。你不可能通過讀一本指導性規則的書來掌握它。目前通常會出現這樣的狀況,這也是大多數公司不知不覺中犯下的錯誤:公司採取了「Agile」的開發辦法,又或者是招聘了一位新產品經理,當現狀沒有大的提升改善的時候,便宣稱這些方法統統失敗。有很多公司能夠在產品管理流程上面轉換 5 到 6 次,最後才意識到了根本問題是出在了「人」和「互動」上,而非工具和流程。將工具和流程改變是相對容易的,但是要把「人」和「交互方式」進行扭轉則需要一定的時間,其中肯定伴隨著抵觸對抗。

將產品管理視為一種「工作方法」,我想來自 Kabat-Zinn 的這段話說的尤為精闢。

人們出於想要經歷某種特殊情境,想要成為一個更好的人,想要降低自身的壓力和痛楚,想要打破舊習慣以及舊的行為模式,想要變得自由以及睿智,往往會採取一種辦法:「坐下來沉思冥想」。所有這些非常具有說服力的理由都讓人們採取沉思冥想。但往往人們所期待的某種「特殊情境」,或者是意味著事情發生好轉的「某些信號」沒有出現的時候,你就頓時陷入到了被動的境地,你開始覺得自己選擇的路是否出了差錯,開始自我懷疑是否行動上錯過了某些關鍵環節?

第二個轉變:「以數據驅動」的產品管理向「以客戶驅動」的產品管理轉變

FgyZSlUnfPEvLuCW0T7HOnA3moXN-2

正因為在產品管理上存在著種種的焦慮,並且還容納進來了一種名叫「軟技能」的東西,人們就自然而然地去尋找數據來幫忙。在我做產品經理的時候

,我知道想要讓自己的話立刻充滿無法辯駁的說服力,那麼從「數據」上做量的判斷吧。我的螢幕上充滿了各種的面板,花了大量的時間去管理和評估各種分析工具的有效性。

但是產品經理的職責並不是去理解「分析工具」,而是要去理解「客戶」。 往往以數據為驅動的思維模式會讓人痴迷於數字,脫離了客戶情境本身。

我們生活在這樣一個「大數據時代」,很容易陷入到對數字執迷不悟的陷阱中,我們看著那些數字和報表,自以為能非常了解客戶,甚至比客戶自身還要了解他們。這樣的想法不僅偏離了數據本身的目的,而且也將人性看得太簡單了。只需要靠數據坐在房間裡就能洞悉人心,完全沒有必要走出門跟客戶聊一聊,這樣的心態自大無知,狹隘且令人悲哀。當然,跟客戶直接交談肯定會帶來某種程度上的不解,尷尬,甚至會洩氣,但是如果你真的想要去了解客戶, 那麼你就不得不放下手中的數據,接受「人的行為是無法預測以及量化的」。

這並不是說數據全無意義, 而是數據分析應該建立在有明確的訴求和目的基礎之上的。如果沒有這些內容作為前提,那麼「數據驅動」的產品開發只是忙來忙去一場空。

第三個轉變:從「是什麼」到「為什麼」

FiK2bNb5NLTCSi-5oDV_etU_51sP

現在想想,當我作為產品經理的時候

,我為能徹底「擁有」一份產品開發路線圖而感到幸福,我可是那個做決策的人,組織的「大腦」,某個充滿遠見和洞察力的人,一個能夠走進來改變公司,使之變好的關鍵性人物啊!簡而言之,我是那個告訴每一個人該開發什麼的那個人。

這樣的想法只要稍微往前挪一步,那麼你的身份角色就類似於這個產品開發小組的「迷你 CEO」。當我開始以產品經理的角色工作時,我真的很喜歡這樣的想法,它讓我感到自己無比重要,充滿權力。噢天哪,有時候我看鏡子鏡子裡面竟然會浮現出上面這個男人的樣子……

尤其這樣的時刻最讓我喜歡,我的團隊中的某個成員跑過來問我:「我是否應該在這個領域繼續開發下去?」這讓我覺得我簡直成為了產品的靈魂所在,路線圖的擬定者以及守護者,產品未來的衛士,只有我能了解公司最深層次的目標和訴求……

不過,那是我生平犯過的最大的錯誤。曾經人們普遍認為:工程師就是負責執行的,其他的事兒不用管,比如商業

層面的決策。工程師可以一整天耳朵裡塞著耳機,一動不動的坐在位置上寫程式,如果你拉把椅子坐到他們跟前,想要跟他們聊聊商業目標,對用戶的理解,你現在做的這些事背後的意義是什麼,換句話說你為什麼要去做這些工作,一旦你有了這樣的嘗試,你肯定會招來厭煩的目光,他們覺得你是在浪費他們的時間,並且也讓他們那麼純粹的專業技能顯得不再純粹了。

讓工程師工程師就專注於手頭上編寫程式的工作,這不僅僅是錯誤的,而且也是對工程師職位的蔑視。我從來不相信一個人能夠在不知道原因的前提下能把事情給做好,這樣的想法當然不值得鼓勵。坦白來說,幾乎每一次產品經理或者高層在「為什麼」這個問題上遮遮掩掩,其真相就是他們本來就不知道答案!

現在回想起來,如果我在剛開始當產品經理的時候

有個人能給我提個醒該多好啊!「不去做超級英雄」,那種自視清高,覺得富有「遠見」的產品經理絕對是有毒的。

產品經理的職責從本質上來說就在承接各個板塊、部門、角色之間橋樑作用,他要讓每個人明白自己工作背後的原因是什麼,而不是工作內容是什麼,這是一個支持性的角色,而不是一個「遠見性」的角色。當被問及「我們接下來該做什麼」的時候,我也許會暫時感覺到舒服暗爽,但是這往往意味著我在產品經理上面的失職。

如果我的團隊不清楚他們正在開發的產品背後是基於怎樣一種考慮,他們根本不可能拿出適合這個項目的最佳技術決策來的。

最終,我不再嘗試去當一名產品「領導人」,相反我正在想方設法的讓公司的目標變得更加清楚,透明,這些目標要盡可能讓所有人知道,這當然會讓我顯得無足輕重,但是它卻極大地提升了整個團隊的工作效率。現在我跟某些公司合作,對項目中各個工作的輕重緩急進行排序的時候,我經常問我自己的一個問題是:「這家公司的目標是否足夠清楚,在我不在這家公司的時候,產品團隊是否有能力像我在的時候一樣,高效地排列出所有事情的前後次序輕重緩急?」

第四個轉變:從「硬技能和軟技能」向「連接式技能」的轉變

FoD8GSdmy4vrV2Y3Cw5txXKiwhGF

最後,我想談一下從「硬技能和軟技能」向「連接式技能」的轉變。

在招聘一名產品經理的時候

,人們往往在問這樣一個問題:如何在「硬技能」和「軟技能」之間尋找到平衡點。我認為這種一分為二的方法讓公司無法找到真正有價值的產品經理,也讓產品經理在工作中無法感到充足的自信。

Megan Kierstead 是在產品管理和用戶調查研究領域非常優秀的專家以及作家,他就說這裡面採取的語言,「軟」和「硬」之分從潛意識裡就讓人們覺得這是某種程度上的「零和遊戲」,你不是這一頭的就是那一頭的。

那麼招聘一名產品經理時描述的條件應該是什麼樣的呢?往往這裡面會有對技術上的強調,比如「足夠的技術水準」來樹立產品經理的門檻。這會帶來兩種結果,好的結果是公司能夠找到一名對技術充滿好奇心的產品經理,他能夠有效地將任務分配下去,並且也能提出好的問題。(其實這樣的技術門檻即使在目前看來也是非常低的);如果是最糟糕的結果,公司招來的應聘者只是看起來非常像工程師的一批人,這些人不可能成為優秀的產品經理。

產品經理要和工程師的角色一致,這樣的想法在工程師團隊中尤其受歡迎,甚至公司人事招聘上也會這麼覺得,誰願意把一個毫無技術背景的人招進來,讓他給一群懂技術的人發號施令呢?他們必須有著相同的從業背景,相同的技術興趣,特長,這樣才能有共同語言, 最怕的情況就是工程師團隊一起排擠這名應聘成功的「菜鳥」產品經理了。

但不幸的是,就算是這個人符合了工程師團隊的種種期待,這些產品經理還是會讓團隊失望,其原因跟這些人被招進來的理由恰好完全一樣!我剛開始以產品經理工作的時候,我總是依照自己的視角,對那些能夠證明我技術背景,價值的領域投以更多的注意力,尤其是工程師團隊都表示很感興趣的領域,我當然要著重強調。但是一旦團隊開始面對客戶,研究開發出怎樣的產品才能提升客戶體驗的時候,我頓時發現似乎沒有什麼領域是我的「私有領地」了,我的威信無所憑藉,只剩下一點點敏感可憐的自尊。

我所認識的優秀的產品經理, 他們都非常了解如何讓工程師團隊納入到「工作任務優先排序」的環節中。這個過程既有趣,也帶來了實質性的成果。他們知道如何授權給工程師團隊,使得他們都能夠從自己的專業視角出發,拿出對公司整體商業目標最有利的技術決策。換句話說,「成敗與否」的關鍵並不是看他「是否有足夠的技術背景」,而是一種能夠在不同的技能、價值觀之間來回游走,銜接的本領。

Fs57vBU3rj8G46DqIzvzzHC5u74i

為什麼對「技術背景」的要求如此普遍呢?貌似「技術背景」貌似就居於「以工程師為中心的文化」和「文化契合度」這兩個要素交合的部分中。從理論上來說,高度專業的勞動團體必須跟值得他們尊敬和欣賞的人一起共事才可以。但這樣一來,貌似工程師只會「尊敬」擁有相同技術背景的人們。但事實上不是這樣子的,這份尊敬會給予管理層,當管理層能讓工程師團隊工作順心愉快的時候,而非給予工程師本身這個角色。

「文化契合」是公司為什麼這麼難找到合適的產品經理的原因。因為這個角色範疇太過模糊,它牽扯到很多跟人們打交道的內容。

FqWuqksDCctaMgnpuuceQEzEEEh8

現在有很多人把「文化契合」替換了另外一個詞,尤其在那些自詡自己為創新型公司中更為常見。這個詞就是「增補文化」。這意味著公司願意去擁抱不同的技能和不同的視角,藉此增加公司的知識庫和提升能力等級。我想所謂「增補文化」的到來,反而會贏得公司原有工程師隊伍的認可,當然這得建立在工程師本身對新的視角,新的方法一直保持著好奇心,而不是畏懼新想法的衝擊。

對了,就是「好奇心」,好奇心是理解一名優秀的產品經理的關鍵,也正是「好奇心」,是產品經理注入到公司中的重要因素。優秀的產品經理應該是將看似分割的經驗、技能、價值觀等方面有效的銜接整合!

有很多公司都煩惱如何從公司內部找出一個合適的「產品經理」,我在給它們提供諮詢服務的時候往往要他們拿出一張紙,上面畫出來公司內部資訊流動的圖。這並不是組織機構圖,僅僅是人們是如何交流的圖。

往往畫完這張圖,很可能就會出現幾個傢伙,他們處於訊息交流的中心節點,扮演者銜接溝通的角色。但是往往這些人根本不符合過去傳統意義上對產品經理的定義,他們不是那種對設計感興趣的工程師,更不是會寫一些代碼的設計師。往往他們是銷售人員,又或者負責營運一個社群,又或者是負責行銷。往往他們根本就是沒有任何技術背景的傢伙,這些人才是小寫的「a」,「靈活開發」的真正代言人,他們在最為重要,且難以證明的溝通技能上面已經充滿展現其價值。他們才是未來真正優秀的產品經理人。

歡迎加入「Inside」Line 官方帳號,關注最新創業、科技、網路、工作訊息

好友人數

精選熱門好工作

Partnership Manager

樂購蝦皮股份有限公司
臺北市.台灣

獎勵 NT$20,000

Full-stack (Frontend most) Senior Software Engineer

ShopBack 回饋網股份有限公司
臺北市.台灣

獎勵 NT$20,000

資深前端工程師 - Solution (Senior Frontend Engineer)

iKala 愛卡拉
臺北市.台灣

獎勵 NT$20,000

評論