成為 Junior PM 的半年 Part 1

距離設計系研究所的畢業口試已經過了一年，到進入職場，回顧這段期間有不少的成長與體悟。

在經歷過一段認識自己的過程中，很感謝有前輩與朋友的多方討論，讓我很堅定地第一份工作就選擇 Product Manager 的方向。

在角色定位上從設計師移動到 PM，開始需要在使用者、商業、技術的圈圈中尋找平衡點，也同時負責多種專案與溝通。

回顧當初列了一些想當 PM 的原因，對比真實進入到 PM 的工作後，對 PM 的角色有了更具體的意象，用專案的前中後流程來分享身為 Junior PM 的思考角度！

專案前：

• 專案鼓吹者：站在專案的前端了解需求，試圖展開專案的可能性。與主管與團隊說明專案執行的必要度，評估帶來的產品數據成長與價值。
• 思考促進者：先提出目標與預期想法，再跟團隊成員一起思考，匯集到不同的觀點與建議，補足自己遺漏的觀點。也反映到平常自己就很愛問人建議… 最後再結合自己的判斷理出結論。
• 資源調配者：決定 Sprint Goal，哪些功能必須完成，哪些功能完成了更好。評估團隊消化點數的能力，將資源應用在重要的功能上，創造最大化的價值。
• 長遠規劃者：過程中仍會遇到跟工程師、設計師想法不同的狀況，或是來自上面的隕石（？）大家各自的利基點都想要讓產品更好。然後在投入市場驗證時間點、開發資源、使用者體驗種種考量之下，最大化優先追求 MVP 與控制實作範疇是 PM 的守備範圍，過程中思考的好提案未來都可以放進規劃的～～

專案執行中：

• 方向決策者：一切產品規劃地看似完美，在執行中仍會發現不少小洞… 發現問題時，團隊會一起提出各種建議與討論後，最後再望向 PM 評估出的結論。有時候因為太菜，偶爾會懷疑自己的決定，後來想想現階段關於產品功能的決定，不管對錯大致上都有後續解法可補足，用保持持續迭代不追求一次到位的心情，來看待這段產品開發歷程，建立決策信心。
• 進度追蹤者：每日早上 Daily 會議了解開發進度與問題討論，理解專案卡關或時程可能延長的原因。在每次的 Sprint Review 時，在開發階段就讓利害關係人測試功能獲取回饋。
• 史料記錄者：除了撰寫 PRD 之外，還需要記錄專案過程中發現的事情，補漏過去開發沒想到的議題，這些議題可能會成為未來功能開發的小阻礙，比如說舊有 A 功能與新增 B 功能使用者操作行為出現相互抵觸的問題，B 功能要如何取捨操作行為？還是接下來一起優化 A 功能。

專案上線前後的節點

• 數據觀察者：根據過去定義的功能目標查看數據與預估成效的差異，定期追蹤數據的表現，作為未來優化功能的基底，推動下一次的功能優化。
• 功能公告者：對利害關係人、使用者介紹功能的好處，鼓勵體驗新上線的功能。
• 感謝與鼓勵團隊：雖然 PM 掌舵了產品的大方向，產品成功與否仰賴不同角色的專業才能完成。
• 進行反思：包含許多面向，可從產品面、個人心態面、團隊面、開發流程面去思考。團隊面、流程面通常會在 Retrospective 會議進行、產品面、個人面就可以跟主管或前輩 1 on 1 的時候提出想法。當專案結束時，要記得保留一些時間反思或是收集成員回饋，PM 本身在邊做邊學中，也需要內建迭代的能力。

快速記錄部分半年來 PM 參與開發產品扮演的角色，也會發現自己持續地在進步當中，慢慢長出工作中自己的思維。一直以來很感謝這體驗到的一切，在沈寂一段時間後用文字記錄。

希望看過文章的人們，在 2024 可以持續地朝向自己所想的方向前進 ( ´▽｀)