2022 年 3 月我提了辭呈，將正式離開大學畢業後加入的第一間公司。這短短 1 年 8 個月的時間，我更加瞭解自己在專業能力上的優勢與興趣，也在不斷解決問題與探索的過程中，找出許多職場應對進退、職涯規劃上的應採行的策略。
這次的系列文章會分成上中下三篇，涵蓋 4 個主題：
- 建立自己的 Narrative — 定義產品經理的角色、在公司的定位
- 建立回饋機制 — 找到自己能力成長的參考（附上我常用的學習資源）
- 迭代執行策略 — 領導決策層、營運團隊與各部門 scrum team member
- 對於職場、職涯其他的學習與反思
上篇聚焦在 PM 的工作內容與技能，涵蓋前兩個主題，請見：總結第一份工作的學習 （上） — 從 0 到 1 勝任產品經理。
中篇（本篇）會寫到 PM 與跨部門的角色應如何有效合作。前兩篇適合想往產品經理的職能發展的人、與會和 PM 有密切合作的角色閱讀。
下篇涵蓋的內容較 general，請見：總結第一份工作的學習（下） — 一些不錯的 Mental Models。
正式進入內容前，先簡單介紹一下我的背景。
2020 年從台大國企系畢業後，我加入一家外商 B2B 保險科技新創，擔任產品經理，從 0 到 1 打造產品，主導過多項產品項目的開發。大學期間我的實習與專案經驗圍繞在商務開發、顧問與創投，沒有任何產品管理、程式學習或軟體開發的經驗。第一份工作是我首次加入新創的工作環境，從 0 到 1 學習如何勝任產品經理的角色。
三、迭代執行策略 — 領導決策層與各部門 scrum team member
To Note: 本篇分享的內容完全基於我的工作經驗，簡化了 PM 產品開發流程中的許多步驟和細節。此外，在各階段合作的 Stakeholder 成員，也會因公司組織的規劃而有所不同。在這篇談 PM 的領導力一文中，我想強調建立跨部門 alignment 的重要性。領導跨部門溝通與合作是產品經理的核心任務。許多討論產品經理的領導力的文章都會談到如何實踐 Influence Without Authority 。如同產品需要迭代一樣，產品經理與各部門的合作模式也需要透過定期的回饋更迭、實踐。為達成有效、及時的合作方法的迭代，我建議 PM 可以學習站在你合作的對象的角度思考，找出能改善工作效率的切入點。
以下分享幾個我是如何改善和不同部門的夥伴的合作品質：
(1) 營運團隊（策略、行銷、商務開發、客戶專案管理）、客戶
就我所在的 B2B 科技新創而言，營運團隊通常會直接面對客戶，接觸更多市場趨勢、競品策略。他們的 KPI 常會是 Lead Generation 數量、客戶成交量，並會直接處理客戶問題，甚至需要負責協助管控專案上線時間。就管理層而言，他們需要決定、提供公司的整體策略、產品的大方向。因應公司所在的產業，公司可能會和數個領域專家合作，給予團隊更多產業與用戶 insight。
營運團隊不會比產品團隊更了解產品的功能模組實作的方式。對他們而言，了解產品實作進程、產品的哪些功能能如何有效解決客戶問題就會是與他們溝通上的關鍵（如此他們才能與外部 stakeholders 們承諾可交付的產品範疇和原因）。當營運團隊或客戶提出需求時，產品經理應去理解需求背後的動機、use case、使用頻率等，而非直接將他們提出的解法實作在產品上。在產品經理產出 high-level business requirement 時，也須頻繁和這些 stakeholders 確認細節，讓他們理解我們的設計與考量。
當產品經理剛接到新需求時，應先理解需求對於公司策略的重要性、對於用戶的價值。當產品團隊不會直接接觸到用戶時，透過與營運團隊、產業專家或客戶的溝通與問答，我們需了解用戶的使用流程與情境，而非直接確認或定下 solution 。而在溝通的過程中，可以將提案內容視覺化（舉例來說，畫出 user flow 或簡單的 wireframe），或借助競品的設計來討論。
例如，在設計付款狀態時，可以參考 Stripe 的信用卡授權、請款流程和報價（Quote）流程；也可以依照未來產品可拓展的情境，多參考其他廠商的銀行帳戶、支票付款流程設計。
(2) 設計團隊
產品團隊與設計團隊的工作內容時常重疊，在合作上也常會因為職能切分、資訊同步落差等起衝突。Julie Zhuo（Facebook 前 VP of Design）在 How designers push back against PMs and how PMs can respond! 一文中提及了幾點常見的衝突點。
「你想要的改動我都能改，但你需要把你考量的原因講清楚。不然我沒有辦法在 review 會議幫我的設計背書。」是我曾從設計師得到的回饋。這也讓我檢討到：PM 與設計師的合作需非常緊密，在資訊同步上也是。
當 PM 為了各個專案忙得焦頭爛額，參加各種 sync-up 會議、蒐集完來自各部門的會議後，若有任何需求、設計上的改動，都應將自己做決定的緣由同步給所有團隊的成員（不僅是設計師！如果能將 scrum 成員都拉到一個會議中，快速討論、找到癥結點又更好！不僅溝通效率提升、促進團隊合作的默契，也能幫助所有成員更明白其他部門的角色的顧慮，在執行後續負責的任務上，能更早設想到可能的問題）（Caveat：PM 應知道什麼時候該 loop in 哪些 stakeholders，不要浪費別人的時間）
設計師為用戶體驗負責，而產品經理的角色是要把需求定義到足夠清楚，給予設計師發揮的空間（舉例：PM 應定義好現階段想達成什麼樣的目標？需要的功能是什麼？需要的欄位有哪些？主要的流程與架構是什麼？等等，以及各種「為什麼」）
產品經理和設計師在合作的專案上應達到 co-ownership 的健康合作關係。想了解更多，可以參考這篇 PM 101 — Working With Designers ，寫得非常好！裡面討論到以下幾點：PM 和設計相互期望值的建立、PM 對 Design team 必須有的尊重、PM 應如何和協助跨部門團隊和設計團隊合作。
(3) 工程團隊
產品經理在產品設計前中後的流程中，都需要工程團隊的協助，例如：評估需求可行性，到實際開發實作並協助測試等。和工程師的合作上我目前體會最深的就是：Specs/需求要定義得夠清楚，並且良好地傳達給工程團隊。
當產品還在前期的需求、設計階段時，會需要依照需求對於產品的改動程度，與工程團隊了解現有的實作方式和 convention。當設計的需求需要更多技術背景知識時也是。以後者的情況為例，我通常的做法是會找很多網路上的 reference ，快速了解相關的設計、功能，並向前後端諮詢。確認了我的理解正確後，必要時我會畫簡單的 wireframe 協助溝通。
當產品經理要將準備好的功能文件（Specs）帶進開發時，應透過講述（Grooming Meeting）、文字（Specs 本身）讓工程師快速了解他們即將實作的需求為何，並即時確認所有人的理解一致。在 Grooming Meeting 時，我認為產品經理常犯的一個錯誤是太快開始講功能的細節，而不是先帶到需求的前因後果。缺少對於需求的認識，除了會讓需求的講述非常發散，難以讓聽眾 follow 講者闡述的內容，也可能造成後續開發上認知的差異。時常在和工程師聊天的過程中，會了解到他們想參與更多早期產品設計的階段，幫助他們對於需求的認識。而我認為除此之外，也能透過在 Grooming Meeting 或其他同步的會議中，帶到更細節的產品功能設計原因（例：我和設計師在這裡想過兩種設計方式，最後選了這種，原因為何？）以便更好地傳達我們權衡後的想法。
Specs 的撰寫上，我傾向把自己設想為工程師，去思考如果我要來開發這個項目，我需要知道多少細節？作為產品經理，我需要為產品的品質負責。因此在寫 Specs 時，會把所有大小細節都訂清楚，像是 field requirement、error handling、snackbar 動畫效果等。當我的需求是要能正確算出價錢、佣金時，我要提供什麼樣的範例，才能幫助工程師有效了解我設計的邏輯？
(4) 測試團隊
產品經理和測試團隊的合作上，可能發生的衝突會包含：測試團隊對於使用情境和最低可接受的放行標準沒有 alignment、不切實際的上線時程等等。其中，我想就前者做經驗分享。
在產品經理產出功能文件（Specs）帶進開發後，測試團隊也會一併看 Specs 、開出 test case 。然而，當專案 scope 很大、參雜許多新舊功能，不同功能會因為不同客戶有截然不同的使用情境和使用流程上的差異。這時的測試就會複雜很多。
我認為產品經理可以透過文件、會議等形式，將使用的情境描述給測試團隊（如果 Grooming Meeting 提供的資料不夠！）在專案時程緊湊的前提下，這會有助於 QA 辨認什麼是產品最低可接受的放行標準、什麼樣的情境是目前有實作的功能還無法 cater to 的、何為高、中、低優先級的 bug tickets ？
當然，有任何文件上的更新，全 scrum team 的成員也都應得到資訊同步，一併追蹤共同產出的成品的改動！
感謝你花時間閱讀。喜歡這篇的話，可以接著閱讀下篇：總結第一份工作的學習（下） — 一些不錯的 Mental Models，或者回到上篇：總結第一份工作的學習 （上） — 從 0 到 1 勝任產品經理。希望這些分享能給予閱讀的你帶來一些幫助。
分享的內容源自我的工作經驗與所接觸的學習資源，歡迎任何的反饋：）
