當產品經理加入一個團隊時，常覺得好像有一百件事情得做，但卻不知道要從何切入比較好。這篇文章我想談的是，產品經理剛加入團隊時，該怎麼評估重心要擺在哪？這是一個很實際的問題，因為大多數人剛加入新團隊時多少都會覺得惶恐，且因為產品經理的責任範圍很廣，因此會不確定該從哪裡下手。這篇文章主要是寫給有這樣困擾的產品經理們。
1.產品經理的職責
先來談談產品經理的職責，每間公司對產品經理的定義略有不同，在此參考 Facebook 與 Google 徵才網頁上通才型產品經理的責任範圍。
產品類 Product
- Establish shared vision across the company by building consensus on priorities leading to product execution
- Integrate usability studies, research and market analysis into product requirements to enhance user satisfaction.
- Define and analyze metrics that inform the success of products.
- Understand Facebook’s strategic and competitive position and deliver products that are recognized best in the industry.
- Understand markets, competition, and user requirements in depth.
流程類 Process
- Lead the ideation, technical development, and launch of innovative products
- Maximize efficiency in a constantly evolving environment where the process is fluid and creative solutions are the norm
- Launch new products and features, test their performance, and iterate quickly.
人員協作類 People
- Drive product development with a team of world-class engineers and designers
- Work collaboratively with engineering, marketing, legal, UX, and other teams on cutting edge technologies.
- Develop innovative solutions to problems by collaborating as needed across regions, product areas, and functions.
從以上的分析，不難看出產品經理的職責主要是以下三類：
- 產品類 Product：了解商業目標與用戶需求，制定產品策略與衡量指標。
- 流程類 Process：帶領產品開發上線，透過假設、驗證，持續優化產品。
- 人員協作類 People：與工程師、設計師、行銷等不同職務、不同地區、不同功能的團隊協力推出產品。
2.起手式評估框架
經過以上的分析，我們知道產品經理的職責有三大類，並非只要把產品規格寫好而已。接下來的問題是，要從哪裡著手呢？
巨觀來看，不同的產品類型、面向不同使用者（2C or 2B）、商業模式、企業文化都會影響產品經理的工作內容、流程與協作團隊。關於這方面的內容，可以參考我先前的文章《產品團隊組織劃分- Product Organization Structure》。
而稍微聚焦到產品本身，不同的產品工作類型（Types of product work）也會影響產品策略、衡量成功的方式與流程。Reforge 近期的文章介紹了 Product Market Fit 之後的四種產品工作類型，以及產品經理常見的錯誤：一招打天下（如下文）。
One of the most common conflicts I’ve seen is when product leaders try to apply a single development process, measure of success, and strategy to all product work. For instance, while some of the steps can be similar, growth and feature work are fundamentally different and a lot of energy is wasted trying to make them all fit into the same process, success metric, and approach.
推薦大家閱讀原文《Product Work Beyond Product-Market Fit》，看看自己有沒有遇到類似的問題。
那不管產品類型、面向使用者、商業模式、產品工作類型為何，還是有一些比較通用性的方法來評估產品經理的切入面向。以下分享我常用的起手式評估方式，來決定要從哪些面向開始著手改善：
People 優先
Product 次之
Process 最後
People 優先
剛加入團隊時，除了快速學習各種產品知識外，另一必要的事情就是與夥伴建立好的關係，確認彼此工作的職責，讓日後的合作會更加順暢。
- 初次見面：當甫加入團隊時，我第一件事就是檢視我的協作夥伴、利害關係人有誰，按照親疏列出名單，並安排以自我介紹、工作介紹為目的的 Introduction 會議。我通常會在前兩週把最重要的 10 個同事聊過一輪，其他的就隨緣了。
- 保持聯繫：對於未來工作上合作會比較緊密的夥伴，雖然每個職務都有既定的角色定義與責任範圍（Roles & Responsibilities），我還是與對方討論確定雙方對 R&R 的理解是一致的。確定 R&R 之後，再進一步開始安排例行性的會議與 1 on 1，其中 1 on 1 的會議頻率也是有親疏之分，例如我跟產品主管與工程經理（Engineering Manager）的 1on1 是每週，但跟其他職務例如設計師、資料科學家就是雙週，與工程師則是每季兩次。
- 資源盤點：我也會趁此階段盤點團隊有哪些角色，欠缺哪些角色，未來需要哪些角色。日後需要爭取資源時，能夠搶先一步提出。
完成上述幾項任務，最多應該不會超過兩週的時間。人的問題總是最複雜的，接下來產品經理要在與團隊共事中去了解每個成員在意的點、能被激勵的動機，觀察成員之間的張力、衝突，有助於未來彼此的協作。
Product 次之
當協作夥伴都認識得差不多，例行會議、1on1 也都安排好了，接下來我會開始評估產品的狀況。要怎麼評估產品的狀況呢？我是以按照團隊對問題的理解程度區分：
- 理解程度低： 球來就打，有什麼需求就做什麼，對用戶問題不了解。
- 理解程度中： 團隊可清楚描繪用戶問題，但不知道如何定義產品成功與否。
- 理解程度高：團隊可清楚描繪用戶問題，也知如何衡量產品成功，但沒有長遠的策略與計畫。
- 理解程度極高：有產品策略、藍圖，團隊按照計畫行事，也能依照上線成果調整策略與計畫。
產品狀況評估應在加入團隊後第一個月內完成，處於不同產品理解程度的團隊，產品經理應提出適合的方法來提昇程度。例如在理解程度低的團隊，應推動與用戶溝通、使用者研究等相關的作法，而非直接開始制定產品策略與藍圖。在理解程度中的團隊，則可推動指標制定（metrics）。在我的經驗中，只有極少數的時候會遇到理解程度高與極高的團隊，如果你加入了這樣的團隊，你可以做一些比較策略性的規劃，把重心放在流程與執行。
各位可參考 Celine 的文章《理想與現實 — 產品路線圖（Product Roadmap）如何應用於日常工作中？》，看看有什麼不同的作法來達成產品目標。
Process 最後
很多產品經理喜歡加入團隊後，就立刻按照過去的經驗或偏好調整開發流程，然而，除非開發流程有明顯瑕疵外（例如沒測試就上線），我非常不建議一開始就去動開發流程。 原因是每個產品狀況都不同，每個團隊也都有自己習慣與偏好，產品經理應至少完整經歷一次產品開發上線的過程，了解流程的問題後，再提出改善方案。在此之前，產品經理能做的就是參與流程，並評估現有流程的狀況。我常用的評估方式如下，主要著眼在開發流程中溝通決策的方式與是否有文件。
- 流程完善度低：專案無固定的會議時間、開發流程各環節均無撰寫文件的習慣、也無品質驗收的概念。
- 流程完善度中：有固定的會議時間、有基本的文件如 PRD、技術文件、測試文件。但成員被動接受指令，彼此溝通較少。
- 流程完善度高：有固定的會議時間、有基本的文件、品質驗收標準清楚、成員自主性高會積極提出問題、團隊會定期舉行 Retrospectives 會議。
當你至少參與過一次產品開發上線流程後（可能此時你已加入團隊一、兩個月了），你就會知道目前團隊的開發流程完善程度。對於完善度低的團隊，我通常的第一步是定義專案的階段與目標產出（例如探索、規格定義、設計與開發、測試、上線等不同階段），通常會搭配甘特圖與撰寫 PRD 讓團隊擺脫混亂的流程。當進入到完善度中時，我通常會導入比較具有敏捷精神的實踐，例如 Demo 或 Retrospective，前者可帶來品質驗收的概念，以及讓團隊成員彼此有互動討論的機會（同時也讓成員有當責的態度，因為 Demo 爛掉很糗），後者是讓大家有追求持續改善的精神，主動發現問題。
關於流程不同階段該撰寫的文件，可以參考我另一篇文章《產品經理與牠們的文件》。
以上就是我自己常使用的「 People 優先 — Product 次之 — Process 最後」評估框架，透過此框架，你可以知道團隊目前人員、產品理解與開發流程的狀況，以及下一步該做的事情，進而決定你加入團隊的姿勢。
3.結語
本篇文章我們談了軟體業產品經理的主要職責，並非只是把產品需求規格做好，而還有人員協作與流程面的責任。也分享了當加入一個團隊時，自身常用的評估框架「 People 優先，Product 次之，Process 最後」，讓我快速釐清現況，知道哪邊是該著重的面向，希望對讀者們有些幫助。
不過如同文章一開始所提，不同的產品類型、面向使用者、商業模式、企業文化都會影響產品經理的工作內容、形式與流程，各位須先判斷好自己所屬的環境。
不知道各位產品經理是否有自己常用的起手式評估方法呢？歡迎分享～
