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

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

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

接了產品經理之後，我做了什麼？

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

1. 了解利益關係人（stakeholder）

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

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

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

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

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

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

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

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

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

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

- 我轄下的同事

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

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

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

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

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

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

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

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

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

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

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

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

3. 密集溝通、勇於請教

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

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

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

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

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

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

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

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

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

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

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

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

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

下一步

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

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

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

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