來分享個人的經驗談、與我的觀察，如果可以回頭一次，我會希望某些點可以做得更好。
由於產品經理（以下用 PM 簡稱）的日常工作忙起來時間會顯得相當破碎，以具備高度責任感為原則來說，會希望降低顧此失彼的狀態，因此建議以不同面向、當下處理事務的急迫程度優先級進行排序，本次會先分享 PM 與利害關係人的相愛相殺關係鏈介紹，之後再根據其他的工作情境分享囉。
在產品開發的領域經常使用到的詞彙 – 利害關係人 (Stakeholder)，我比較喜歡以 PM 的角度出發作為簡單解釋則是：你的組織及工作環境裡，你需要面對的人。且這個面對並非只是交代進度，基本上只要是還在職的一天，都需要審慎去思考如何與利害關係人維繫良好關係，向上彙報、而平行或向下也可以掌握各方狀態。因為「人」的相處很重要，所以我們需要瞭解如何與各種人、你的老闆及同事們互動，目標是讓團隊協作無論在溝通時的氛圍與工作上的互助效能足以發揮最大值。
- 向上管理：
通常是主管，又分為一級或二級（以上）主管。我自己習慣的是需要透過觀察瞭解各主管的個性、掌握眉角，主要提醒的是在例行大家可以想像到的工作狀態回報以外，有一些小事情例如由 PM 發送會議通知時也需要留意主管是否有多個 e-mail？你是否先確認過當週或是下兩週他的會議安排了？是否有重要會議也可能會影響到你想與他討論一些重要決策呢？
對於一級主管是相對自己比較近的上司，關係通常會更緊密一些，建立與上司的互信關係我始終認為工作中是非常重要的事。特別又以 PM 的工作有許多事項最好都要讓主管瞭解進度，即使主管已經對你具有一定的信任感，也期望 PM 們不要辜負了主管的信任感。嘗試多主動回報進度，好的、壞的我認為都可以講，但是怎麼講、要講哪些重點，請都先在腦中思考過，或是把想法打出來進行整理。
面對一級主管我在回報事項時會比較鉅細靡遺，甚至會先交代事件背景、目前進度以及我預計會怎麼做？當然，有些事情並不是我自己想過就可以完美解決，會找主管除了回報之餘也可能是找他請益，但不要讓主管覺得 PM 沒有自己先想過，我認為這個會是扣分的行為，因此建議一定要先試著想過解法，再與主管請教及確認可行性。而面對二級主管的回報時，個人傾向是先讓他瞭解事情的結論，再用條列式進行重點陳述，再根據主管的提問答覆。
- 平行管理：
這點真的是產品經理的 70% 日常，我認為多數 PM 們都是在與同部門及跨部門的同事或是對外的客戶端進行合作。由於我目前負責的工作並不會走向前端，因此不會實際服務客戶，因此分享的內容以內部的平行管理為主。
另外，特別提到一點，由於產品經理需要對自己所做的決策負責，以及說出來的決策需要堅定、要讓團隊倍感信心。原因是工程師或是設計師是相較產品經理而言較為後端的角色，多數時候在 team 中可以自在地發揮，不過如果需要跨部門溝通時不見得會是優勢的狀態，通常也仰賴 PM 給予明確的指示。因此 PM 要將外部的聲音完整的消化過，並轉化成產品開發部各個成員都可以理解的語言，把期望轉達給大家，進而再來討論可以如何開始下一步。
以下按照同事職能屬性分別說明合作上可以注意哪些事項
–
(1) 前端 (Frontend Engineer)、後端 (Backend Engineer) 或全端工程師 (Full Stack Engineer)：
工程師們都有一顆很可愛的內心，我接觸過的工程師通常都有自己一塊領域的小幽默（大家可以多去和工程師聊天，可能會有意想不到的事）不過回歸工作面，與工程師們相處需要留意「邏輯」，雖然說與各利害關係人溝通時都需要帶著換位思考的心態，但我認為在和工程師溝通時，他們確實會相較其他角色，更在意邏輯的演算。這邊講得並非是程式碼 code 寫的邏輯怎麼樣，而是 PM 與工程師之間「溝通的邏輯」。舉例來說，Day 1 工程師接收 PM 提出一個新需求，但 Day 2 PM 卻又更改了需求內容。類似這種異動不是不可以，但對於 PM 的考驗在於要怎麼樣是有理的做出需求的異動？可能是因為高層主管的新命令，產品的方向突然要調整，我覺得都是很有可能發生的，但考驗卻是落在 PM 如何說服工程師接受需求更改，因為可能前一天工程師已經著手準備資料庫新架構等情況了。這時候雙方一定要先花時間溝通討論，把現有的需求都列出來，時程怎麼變？假設時程依舊不變，那既有的需求們勢必優先級可能要做微調等等的。
換位思考的原則在於 PM 自己也不喜歡短時間內使用者提出的產品新需求不斷疊加上來，而且還給予期待希望這些都可以在未來的某個時間點趕緊上線，所以工程師肯定也不喜歡新需求不斷被加進來，但工程師們一定可以接受事情被討論，那麼大家好好的來想辦法，我們可以怎麼做。不要傷了和氣，是更重要的。
–
(2) 資料科學家 (Data Scientist)、數據分析師 (Data Analyst)：
有越來越多的組織中會編制這兩種角色，如果你的組織內有這些同事，恭喜！原因是我認為這兩個角色在公司內的貢獻在於數據的量 (data base) 一定要夠大，可能會是很雜的，但必須要夠大才能進行抽絲剝繭。因個人過去的經歷，對於數據相關的議題是很感興趣的，所以在與資料科學家互動時，會找機會多多請益他們探索資料的想法，我會想要知道為什麼會這樣找？而對方可能也會反問我某些在數位行銷相關的知識、互相協助，讓最終我們希望可以爬梳的資料可以如實呈現。
資料科學家通常會是具備技術背景的，例如可能是從後端工程師、或是技術型產品經理轉職，所以性格上我認為與工程師會微微的像，溝通時也要留意話語的一致性，注意邏輯。而數據分析師可能會依照公司期望的分析工具，例如已經採購的工具、或是可以全權交由數據分析師發揮想要使用的工具，例如 Excel, Google Analytics, Microsoft Power BI, Elasticsearch 等。但與兩者同事相處時，通常會聚焦在「數據」怎麼被應用，我的話會試想數據如何被佐證正確性以及後續的應用策略，再和科學家與分析師討論。
–
(3) 視覺設計師 (Visual Designer)、UI Designer、UX Designer：
設計師免不了與「美感」有關，舉凡數位產品 Web/App 勢必要經過美化才能上線。合作時通常會是由產品經理先出一個類草稿的設計原型 (Wireframe) 再交付設計師進行視覺化呈現 (Mockup)，在第一階段溝通 Wireframe 時也會找工程師等與該專案產品開發的同事大家一起討論，希望直接在 Wireframe 階段就要將功能定義下來，以免進到設計師的 Mockup 階段功能又需要修改，會浪費工時。細節預計之後釋出一篇關於產品經理的工作流程(Workflow)再細講。
和設計師討論時我會注重確保設計師理解設計原型(Wireframe)的各個重點功能，通常 Wireframe 的頁面上針對各點功能都會有文字描述，在這邊我建議各位 PM 務必要描述清楚，同時也會請設計師參考其他的文檔，例如產品規格表 (Spec)、產品需求文檔 (PRD) 等；而設計師如果針對特定功能仍有小疑惑的話，可能也會直接手繪一個示意圖與 PM 確認是不是這個意思？我認為無論是哪種溝通方式，PM 掌握的原則即為 Wireframe 不求畫的完美漂亮，但每一張的頁面、每一個功能都需要具體呈現，加以文字敘述運作的原理。
而視覺美感的部分，在產品開發初期盡可能的我會先和主管高層們確認希望的產品定位及方向，如果沒有太大問題，會讓設計師有個底瞭解該產品的定位，像是 B2B / 色調需要較為穩重，可能傾向深藍色系 / 不用太多的人物小圖等。基本上不會限制設計師太多，還是希望可以給他們多一點的發揮空間，但需要給一個可以進行設計發想的方向。
–
(4) 業務推廣同事 (Business Development)：
和業務的合作通常就有趣了，我指的有趣是 BD 同事並非像上述 (1)~(3) 類型的事們似乎可以收束成大概的角色輪廓，一個團隊裡面的各 BD 們可能有著風格迥異的狀態產生，也形成 PM 面對業務主管、業務執行人員，要如何整合意見，考驗 PM 的溝通技巧。通常攸關產品大的走向，一定是找業務主管確認是否符合他們 team 的期待？針對個別的業務同事則是討論使用上遇到的問題、或他們可能會提出某些新功能的詢問及期待，PM 面臨相關的問題時需要評估要讓他們瞭解到哪種程度，在這邊的換位思考變成要陳述的為讓他們可以轉述直接講給「客戶/使用者」聽的語言。
舉 2 種情境為例：A 功能已經完成，但預計在下個月才會進入優化討論；B 功能準備要上線，但前端的業務同事們還不知道。
A 功能情境：取決於 PM 是否已經有規劃或釋出過版本計畫，如果還沒有的話則可以先擬定一個時程表，布達未來三個月預計的重點功能會在哪個時間點釋出，可以想像成里程碑的概念。但遇到重點功能的預計完成日還不明確的話，可能變成要呈現的是預計在哪個時間點準備做哪些事（進入討論、會再約哪些部門研討、其他…？）。提高雙方對於產品開發進度認知的一致性。
B 功能情境：我認為和 A 功能情境十分雷同，但差別在於要探討的是為什麼 B 功能沒有提前先預告即將釋出？有些情況可能是產品開發單位自行嘗試做出一些新功能，並非來自 BD 或其他單位提出的需求，可以理解成是 Bonus Function，我個人滿喜歡這種自發性的提出功能的創意，不過前提是團隊的開發進度許可，且個人也有餘力。但如果 B 功能是來自需求，那我建議 PM 對於內部資訊的佈達及流通性必須做個檢討，試想是不是可以開一個跨部門例行會議跟各 team 分享近週、月的產品進度。
–
(5) 數位媒體企劃 (Planner)：
在媒體代理商的環境裡必定有 Planner 的角色，由於我主要接觸的為數位產品相關，因此 Planner 也以數位媒體為例子，其會負責客戶的數位媒體策略之規劃。由於我有相關經驗，所以和 Planner 溝通時相較順暢無礙，不過如果是從未與數位 Planner 溝通過的 PM，我建議可以先熟悉一下現行如 Facebook, Google 等廣告形式，Planner 的工作目標往往是達成客戶於數位廣告上的成效 (KPI)，可能是透過廣告而完成的留名單數要達到某個數量、廣告被點擊的次數達成幾次等。因此與 Planner 環繞的討論話題通常是我們所開發出的產品如何直接或間接達成客戶的媒體成效？在檢視產品指標及數據時，Planner 首要在意的為所見的數值要怎麼與客戶的期待對接。PM 溝通的切入點務必要記得不要談太多技術面、太艱澀的用語，也就是與工程師或設計師討論的產品架構的相關術語，在和數位 Planner 討論時我建議是通通拿掉；轉而用 Planner 可以理解的語言，例如：
對 工程師：這個圖表需要用長條圖呈現，X 軸代表品牌、Y 軸代表個數，以 100 為單位呈現。
對 數位媒體企劃：這個圖表可以應用在要提供給客戶看目前各品牌的實際個數，以瞭解競品之間的展店程度。
小結上述的 2 種面向，即可以發現對於工程師需要交代製作圖表的細節；而對數位 Planner 則是描述一個使用情境，讓他可以判斷是否這樣的圖表功能符合客戶預期。
–
(6) 廣告優化師 (Digital Advertising Analyst)：
同數位 Planner 的狀況，過去我具備長時間投放數位媒體廣告的經驗，因此十分清楚對於廣告優化師而言在意的是數據的正確性，產品是否有助於任何與廣告投放相關的事情？基本上會聚焦在產品是否可以優化廣告、提供自動化定期報表，如果不是前面兩者，優化師看待產品的定位可能變成廣告「前測」或「後測」的工具，意指是否可以幫助先做廣告投放前的數據建議、或是廣告投放後可以參照比對執行成效究竟與什麼面向可能具有相關性？
PM 要瞭解的是廣告投放的流程運作，探討在每個環節產品可以加入成為角色的機會。確認優化師在執行面遇到的問題，畢竟產品的產出目的在於要解決使用者的問題，有可能在聽完期許與回饋後沒辦法於現在實踐，但 PM 可以先將相關的討論、想法註記下來，以利未來才能記得再重新拿出來討論。
- 向下管理：
資深 PM 如果有下屬組員的話，則會進行向下管理，而我目前在 PM 這個角色實際管理的我不認定為「組員」，比較像是管理資淺的同事們 (Junior Colleagues)的工作進度及確保工作品質。其他向下管理的經驗來自先前在數位行銷領域、以及現職工作以外的專案（我個人視為 Side Project）。主要在這部分我的建議是對於組員的掌控權不要過大，以 PM 來說如果有確實執行產品開發中的敏捷開發流程，應落實每日的站立會議 (Daily Scrum / Daily Standup Meeting)，確保瞭解團隊中每個角色的當日與近期工作目標與進度。可以在討論年度目標時先溝通好雙方對於工作目標是否一致，鼓勵組員發想嘗試想要做的新事情，如果遇到比較沒想法的組員，則需要多花一些時間從眼前的工作內容延伸，試著協助組員可以自己統整出感興趣的項目。
最後來聊一聊我認為的 PM 與利害關係人如果可以維持友善的關係，對 PM 而言可以獲得以下益處
隨著不同事件累積疊加後的經驗值不容小覷，不過每一次都要做的比前一次更好，所謂的更好可以是效率的提升、執行事件的完整程度甚至是雙方溝通時的語調氛圍皆可以處於冷靜討論。綜合以上 PM 如果都順利達成的話，在人際關係上與利害關係人便可以維持良好的狀態，下一次要進行溝通或需要談判時有助於更佳順利地推進。
預祝各位 PM 們與利害關係人都可以維持相處舒服、友善的合作關係。