從專案經理專職成產品經理時,必備的四個工作認知

從專案經理專職成產品經理時,必備的四個工作認知

之前幾篇文章可能有寫到,我在 2020 年初在原公司內轉,從線上課程內容製作的專案經理(Project Manager)轉職成為產品經理(Product Manager)。如今內轉已滿一年,加上同時碰到一些組織與營運上的變動,覺得這時間點正好可以來記錄自己接任產品經理後,做了哪些事情、達到什麼效果。

我是怎麼內轉成為產品經理的?

其實我的內轉比較像是「臨危受命」,「產品經理」這個職位既非升職,也非主動爭取而來,而是公司基於某些內部原因而做的人力調動,原因無法詳述,但總之,我就只是被調來遞補產品團隊的產品經理(兼產品主管)缺額。

接了產品經理之後,我做了什麼?

總之,我就這樣突然變成產品經理了。因為幾乎沒有相關經驗,所以上任之前非常緊張,花了很多時間思考接任後要做哪些事,以下是我嘗試過的 4 個方式,也是我覺得產品經理必備的 4 個小技巧或工作認知:

1. 了解利益關係人(stakeholder)

在內轉之前,我對於產品經理的認識並不多,對這個職位的認知僅限於紙上談兵 — — 看過訪談影片或文章、看過別人寫的心得、上過線上課程等,但真正上任後,才發現這些東西看起來是一回事,但真正上了戰場(職場)後,又是另一回事,這會盡量在後面逐一舉例。

先插個題外話,延續上面講的,就是因為我看過不少相關文章和教材,但看完卻沒什麼感覺,總覺得就是一些很常見的公式或心法;然而,自己實際上做起來又有別的體悟,所以才想把這些更為深切的感受寫成文章。

但一定仍有讀者會覺得:「這些文章不就是老生常談嗎?」(就像當時的我看到別人文章時,也是這樣想),但!我只能說,唯有親身經歷過之後,才能很深切了解到,這些看似廢話(?)的文字,還真的有道理所在。

就像這個小標寫的,有人可能會覺得「了解利益關係人」不是本來就應該做的嗎?但之所以要如此強調,就是因為它特別、特別、特別重要,真的很重要。

以我碰到的狀況舉例,這件事情之所以會那麼重要,就是因為先前的團隊溝通有很大的問題,需求端與實作端之間並沒有充分了解彼此的需求跟困境,所以造成很多溝通上的誤差跟誤解。正因為這樣,我才把「了解利益關係人」這件事設為到職後的首要任務。

畢竟我是「空降」的產品經理,之前既沒有相關經驗,也很少和產品或工程團隊共事,大家對我的能力或做事方法都不了解。所以在一開始,我希望大家看到的是一個「勤能補拙的菜鳥產品經理」,而不是一個「很自以為是的空降主管」。

那該怎麼做?首先,先定義出有哪些利益關係人,分法有很多種,我是依照溝通方式來分:

- 我的上層:直屬主管、CEO

- 與我平行的其他管理層:如:行銷、業務、課程、工程等各部門主管

- 我需跨部門合作的第一線人員:如:法務、財務、行銷、業務、課程、工程等各部門的第一線人員

- 我轄下的同事

我的作法是, 在跟利益關係人(不論是組內、老闆、跨部門的同事還是主管)交流前,先把想了解的事情列出來,開會時逐一詢問,並且記下每場會議的內容,尤其「一定」把大家各自的考量(他在乎什麼?)、規劃的目標(他想做什麼?)、碰到的問題(他碰到哪些困難?)、對於產品團隊的期待(他希望產品團隊給予什麼協助或資源?)等,一一紀錄下來,再陸續盤點和歸納,並列出對應的解法,最後再排序出團隊接下來的目標。

我把這整個流程當成一個「產品經理到職專案」在管理,甚至私自把這段「跟團隊成員互動的過程」當成自己的試用期,要求自己得在短時間內陸續跟團隊成員培養默契、建立溝通的管道、重拾信任,讓大家願意分享他們真實的想法。

現在說來簡單,但我自認這一切剛開始很不容易,畢竟以前完全沒有跟這些利益關係人密集共事過,加上先前需求端與實作端之間已有些溝通問題,一時之間要化解問題也沒這麼容易。但如果不去解決,問題就永遠不會消失,所以說到底,就是要持續去做。

「了解利益關係人」不是到職的一個「任務」而已,它是長期的「過程」,需要一而再再而三地跟團隊溝通和說明,不能只是一次性地做個樣子,目前也還在持續努力中!

2. 不躁進、不力求表現,先盤點工作、穩定軍心

跟上面有點呼應的是,我在剛開始到職的時候,並沒有馬上列出產品的 roadmap,而是先跟利益關係人「拜碼頭」,之後才開始在組內盤點資源、建立流程,以及把東西文件化。

上述這些「打底」的過程,都是在尋找並建立組內協作的共同語言,當大家找到一個「共通語言」後,才能夠比較沒有落差地溝通。團隊的流程和文化建立之後,我才開始盤點產品的任務 — — 也就是團隊實際上要開始規劃或者優化哪些功能。

當然能夠有這些「奢侈」的時間來做這些事情,得感謝當時主管和老闆給了我很多的權力跟信任。也因為有這樣子對應的權力,會讓我更審慎評估資源的運用。

這邊再插個題外話,在接任產品經理這個職位前,主管還帶我去拜會了另外一間公司的產品 lead,跟他請教關於我們公司內部碰到的一些問題,對方就說,他也遇過類似的狀況,而當時他們花了半年到一年的時間,才讓團隊整個穩下來。

所以當時主管也就比較悲觀地預期,目前這信任瓦解的團隊可能也得花半年重上軌道。也就是說,很有可能在半年之內,公司沒辦法推動任何大型產品功能的開發。

最後,我在兩個月之內就把這些事情都打理好了。雖然沒有人壓死線,但我知道公司內部已經處於人事紛亂太久了,產品團隊真的被擱置了很長一段時間,有很多進度還有團隊的默契都很難在短時間內救回來。正因為知道這些狀況,我在剛接手工作時的第一個月,心理壓力是前所未有地大。

話說回來,到底是怎麼做到的?其實就是真的是市面上很多文章寫的,也就跟這篇文章列出的方法差不多,但差異是在於「你願意投入多少時間跟心力去做這件事情」。因為說穿了,這些事情每個人都會做,可是能夠做得多徹底?願意花多少的時間?願意多努力?這才是真正影響事情能否被做好的重要因素。

3. 密集溝通、勇於請教

團隊打穩基礎、建立溝通默契後,再來終於可以開始推動產品的前進。但我的第一步也不是要突然間做一個很大的功能,而是先挑一些比較小的票來做,比如說 bug 票或者是畫面的小調整。

會這樣子做的原因是,團隊才剛開始運作,得先確認這些流程有沒有什麼問題,同時間也可了解同事的工作習慣,陸續培養跟他們工作的默契。

現在看來,我也認為這樣子做是好的。因為先做一些小東西,涉及到的人相對比較少,溝通流程單純,算是比較安全的做法。

比如說,解張 bug 票可能就是一個設計師,再搭配一個前端或後端,有時候甚至一位工程師就能搞定。但如果突然想要推個大功能,可能就得抓進兩個設計師、兩三個前端加後端,溝通節點非常多,流程也會很複雜。在團隊剛建立的時候,我不認為面對這麼大的挑戰是對自己與團隊有幫助的。

如果成果不錯,當然是很棒的事情!但通常這也代表要付出比想像中還要大的代價跟時間,而團隊在當下是否有這樣子的資源呢?更悲觀的是,萬一事情搞砸了,等於在一開始就失去了團隊的信任跟期待,那之後要推進其他事情,想必就會更困難了。

4. 資訊文件化、溝通透明化

講完了和利益關係人的溝通、 建立工作流程以及與跨部門共識的默契,第 4 個方法則是讓「與我的工作相關的事情」高度透明化以及文件化。

有人可能會覺得:「不是本來就應該要這樣子嗎?」但很遺憾的是……還真的不是這樣。

以我的個人經驗來說,有妥善文件化的組織真的 非 常 稀 有!尤其新創公司做事通常是又快又急,即使討論好一個目標或一個任務,過程中仍會有很多改動和討論,這就會導致任務完成後,要不是沒有文件紀錄,不然就是文件紀錄也是東缺西漏,沒什麼考古價值。

再以我的現職公司舉例,在我接手產品經理之前,產品功能的做與不做、迭代紀錄「幾乎」都沒有文件化,導致各部門溝通時花很多成本,因為大家的認知根本不在同一個水平上。

此外,當我真的想要優化某個功能或頁面時,也沒辦法知道它所有運作的邏輯和發展脈絡,團隊在動工改畫面或改程式之前,還得先花時間把目前的使用邏輯搞清楚。

也因此,即使我很討厭寫文件(畢竟要花超多時間啊,大家也不一定會乖乖看),但這些文件就像是產品的「史書」,未來的人如果有意願「考古」,就能從中找到很多資訊,比如當時為什麼做出這樣子的決策、參與的人有誰、做了哪些變動等,進而更有效率地拼湊出產品的全貌。

除了將資訊文件化,我也會確保大家都有權限看到這些文件,所以我在每週一早上,都會在公司的群組回報團隊上週與這週的進度,並附上相關的文件連結。如果要做大功能或大改版,也會舉辦內部腦力激盪,或者至少開個雲端協作文件,鼓勵大家拋出想法。一來就是想讓這些溝通過程透明化,不要給人黑箱作業、老闆說了算的感覺,二來也能增加同事們的參與感,組織成員之間才會有互動交流的機會。

下一步

現在不管是組內還是跨團隊的合作,我認為已經有一定的默契了,工作流程也差不多都建立下來了,接下來則期待自己能降低人事管理的比重,把重心放在產品本身,而且不要只是接需求、處理單點問題,而是多花時間思考產品策略,比如根據公司的商業策略,產品還可以有哪些發展,是要加功能還是擴張產品線,甚至是嘗試其他商業模式等,希望能從挑戰之中找到更多機會與突破點。

如果能做好這件事,就能讓產品團隊的產出真正對應到公司整體業績的表現。畢竟產品經理不是活在象牙塔裡,也不是照老闆丟下來的進度去交付功能就好,而是應該要站在更前面,跟第一線的業務、行銷、商業開發等,一起去思考怎麼樣的產品最適合市場,甚至更搶先地預測市場的走向,提前部署出使用者將來可能會需要的功能。

原文轉貼自:MH ( 原文標題:新手產品經理的一週年回顧&成長日記 )

本站所有文章未經事先書面授權,請勿任意利用、引用、轉載。