剛踏入新公司的產品經理，要如何快速熟悉全新的環境、陌生的產品線以及人際關係？Onboarding 有哪些注意事項？剛好這陣子有滿多朋友更換公司，這篇預計透過 3 個維度 Product（產品）、Project（專案）、People（人員）記錄一下產品經理上工流程。
一、入職前的準備工作
⠀⠀
在面試階段通常就會看各種文章，像是：- 公司：公司背景、近期新聞、創辦人新聞
- 產品：產品發布會、官網產品介紹
- 競品：產業動態、競爭對手發展
這些可以在入職前就先建立產品的初步認識，可以在入職後快速了解產品的基本資訊，快速聽懂同事的溝通語言。
⠀⠀
在拿到新公司 Offer 時，我也會先訂下要達到的目標，比較常見的像是：
- 要累積 OO 專案或產品
- 要創造 OO 數據或指標
- 要嘗試帶領 OO 團隊
- 要晉升 OO 職位
- 要爭取 OO 外派機會
這些目標可以讓自己進到公司後，先有初步的目標方向，例如「為了累積 OO 產品規劃經歷，現階段先開始熟悉 OO 產品功能」。
⠀⠀
二、 Product（產品）、Project（專案）、People（人員）
除了上述之外，可以從 3 個面向來了解接下來的工作樣貌，分別是：
- Product：產品架構、用戶洞察、市場定位以及關鍵指標等面向。
- Project：團隊正在執行的專案，包括專案目標、執行進度、資源分配
- People：利害關係人，包括跨部門協作夥伴、外部客戶
⠀⠀
（一）Product — 了解產品全貌
⠀⠀
作為產品經理，要能規劃產品之前要先了解產品現況，根據我之前待過的產品團隊會有幾種方式：
- 閱讀過往產品文件：包含產品上線文件、教學文件、FAQ 等
- 參與內部各種會議：包含每日站會、週會、各種例會等
- 向團隊成員請教：包含 PM Mentor、RD、Sales 等
但上述不一定每間公司的狀態都能參考，有些公司比較沒有整理文件的習慣，因此 PM 剛進去公司能看的文件非常零散，我的作法是主動整理一份產品規格書，做法如下：
- 將整個系統切成不同主頁面、子頁面
- 看有沒有現成的文件可以先閱讀，陸續記錄在自己的新文件上
- 每一頁自己都操作過一遍，紀錄每一個動作的細節和阻擋情境（像是欄位上限、送出方式、刪除情境等）
- 將不確定的規則都記錄在規格書上
- 先向同事確認若要瞭解這幾塊，可以查看什麼文件
- 若都沒有文件，未來要規畫這塊的功能時再請教工程師
⠀⠀
雖然自己整理文件很土法煉鋼，但這個方式可以讓自己快速了解到整個系統，特別是使用者流程和功能現況：
- 以電商平台為例：最快的方式就是自己上架數個商品，並從前台測試下單
- 以求職平台為例：則是自己建幾份不同職位的履歷，並測試投履歷
比起聽別人說，直接把自己當成是使用者走過一次產品流程，能更快了解使用上的一些問題，像是「為什麼當時會這樣設計？這個欄位怎麼有點不好填寫？這個地方看不懂要做什麼？好像不知道要怎麼操作下一步？」等問題，這些問題對於未來產品規劃都會有幫助，也可以了解目前系統的一些基本 UX Guideline。
另外隨著 AI 工具出現，也可以直接透過與 AI 對話掌握特定產品的概要，例如向 AI 詢問「請比較 A(自家品牌) 和 B/C/D(其他產品) 的差異」、「請說明 OO 系統的使用流程」等，雖然不完全精準，但也足夠讓新進產品經理了解功能樣貌或競爭者有誰。
⠀⠀
（二）Project — 掌握專案執行現況
⠀⠀
除了產品本身，產品經理若能了解公司目前正在執行的專案狀況也是一個快速融入團隊的方法。
透過專案管理工具、會議記錄或直接與專案經理請教，可以提前掌握在特定產品之下有沒有關聯的專案正在執行，這些資訊建議包括：
- 專案概要：專案名稱、預期完成時間、目前進度狀況
- 參與人員：專案經理、參與團隊、各利害關係人、專案要報告的客戶
- 專案成效：指標、數據、目標
- 自己角色：自己未來在此專案中會不會扮演什麼角色
以 B 端產品為例，有些專案類型是「客戶導入專案」，這時導入就會跟指定功能有關，像是 A/B/C 功能要上線才能讓某客戶簽約，這時專案經理和產品經理就會很密切合作。
以 C 端產品為例，可能則是「和某個外部產品有異業結盟」，這時特定功能可能就會需要調整。
⠀⠀
除了專案本身之外，我也會盡可能去了解「專案經理的工作流程」，像是：
- 專案進案的方式：會不會影響到產品 Roadmap
- 專案優先級原則：其他團隊都在關注什麼指標
- 專案資源的分配：公司在意的專案是什麼類型
- 專案管理的方式：卡片工具或 Excel 表單
這幾項可以從專案經理的視角更了解公司的決策方向，包括評估原則、商業考量、資源分配、人力分配等因素，也能事前了解到「專案經理的立場」，這對於未來和這個角色合作時，比較能站在他們角度在同理事情。
⠀⠀
（三）People — 建立利害關係人網絡
⠀⠀
除了 Product、Project 之外，People 也是身為產品經理需要掌握的關鍵，內外部利害關係人的人際網絡是順暢工作的基礎。
最快的方式是畫一張「人際關係圖」，從自己角色出發，會碰到哪些角色？像是：
- 上層：Mentor、直屬主管、副總
- 平行層：專案經歷、業務、客戶經理
- 開發團隊：工程師、設計師、QA 人員、系統分析師、數據分析師
- 外部人員：客戶、第三方系統商、外包人員
事前掌握這些人際網路，可以在工作中比較知道什麼狀況要找誰，特別是關鍵人物 (Key man)，最直接的狀況是萬一開發進度延誤，要找誰求救或徵詢更多人員開發，或是該找哪個專案負責人討論時程等。
⠀⠀
人際網路完成後，再來就是要找到「每個人的使用說明書」，像是如何和直屬主管互動，是否需要每雙週 1on1？是否要每週繳交週報？回報開發進度的頻率是如何？他對功能的期待是？（向上管理不容易，這也是我還在學的一個課題）。
而與開發團隊的默契也是需要花時間培養，每個工程師都有各自的習慣，像是「Coding 中不希望突然跑過去討論」、「有事先留言不要突然跑來」、「定義好每個規格再來討論」、「請列出你具體要開發的 API 內容」等眉角，身為產品經理需要掌握每個人的溝通節奏和特定語言才能讓工作更順暢。
以我過往案例，我會盡可能去了解技術細節，像是 API 名稱、排程名稱、schema 名稱等，讓我在提需求時可以更精準告訴工程師說我需要改什麼地方，同時因為可以和工程師討論到技術面，之後若要和專案經理和業務介紹產品時，也能更清楚說明我們能支援什麼 / 不支援什麼。
外部利害關係人雖然不在公司內部，但他們的影響力往往也很重要，以 B 端產品為例，客戶是最重要的外部利害關係人，他們願意付費、持續續約通常才算是 B 端產品的成功，因此保持客戶良好關係、定期收集他們的反饋，。對於 B 端產品經理也是滿重要的日常工作。
⠀⠀
三、快速上手的實戰技巧
⠀⠀
在某些公司的 Onboarding 過程，有些會有 Mentor 帶著你一步步通關，像是第 1–5 天要閱讀什麼文件，甚至會帶著你和未來合作的部門打招呼，常見的流程像是：
- 第 1 天：加入各 Slack 頻道、認識團隊成員、觀看內部教學影片
- 第 2 天：閱讀產品文件、操作 A/B/C 功能
- 第 3 天：閱讀產品文件、操作 D/E 功能、自己走過一個用戶流程
- … 等
但如果沒有人帶著你做上面這些事，也可以主動和 Mentor 約個固定 1on1 諮詢，像是我之前有約過 Mentor 每週的一三五固定進行 30mins 的 1on1，一次問完我遇到的問題，持續 2 個月左右。
若真的不確定要做哪些事，可以參考以下方式讓自己上手：
- 公司：閱讀公司官網、理念、內部教育訓練影片
- 產品：閱讀產品文件、教學手冊、FAQ、電子報
- 團隊：主動向團隊成員自介、或中午一起加入吃飯
- 人員：觀察辦公室周遭的各種角色，劃出人際網路圖
⠀⠀
另外一個新人常遇到的陷阱是「不要太急於改變現有的流程」，即使一開始可能對於某些事情會覺得有更好的方法，但要先理解為什麼現有的方式會存在，它解決了什麼問題，有什麼歷史脈絡。
避免過早批評各種事物，而是以觀察和理解的心態來參與，同時也盡量避免一開始就試圖下各種決策，而是透過逐步貢獻和參與感建立信任。
⠀⠀
四、總結
⠀⠀
剛好近期參與不少 PM 活動，和不同 PM 聊到報到流程時，發現每間公司狀態都很不同，有些要自己去打怪闖關，有些遇到很善心的 Mentor 手把手領進門。
但原則通常就是這三個元素：Product（產品）、Project（專案）、People（人員）。
- Product：理解產品架構、用戶、和系統
- Project：掌握專案執行、管理流程、資源分配
- People：覺察利害關係人、關係維護
這三個面向是相互關聯的，能為之後的工作更順利，好工作的衡量標準對我來說不只是完成工作任務，更包括團隊協作、利害關係人協作、專案協作等多方考量。
這篇是我自己這幾年的 PM 職涯心得，持續讓自己養成系統思考，也持續在不同角色可以創造產品經理的價值。
⠀⠀
如對這系列文章有興趣可以再觀看：
