[翻譯] 身為唯一的產品經理，加入組織的前 90 天，你該做什麼？
原文在此：Your First 90 Days as the ONLY Product Manager
對於產品經理來說，加入成熟的產品組織通常簡單得多。這類組織已經擁有框架、已被建立好的產品價值，而新的產品經理進入組織之後，也有 mentorship 與其他支持系統；總之，onboarding experience 是比較好的。
然而如果你是組織內唯一的產品經理，加入組織後會面臨超多責任 — — 你需要建立 product function、讓其他同事明白你與專案經理的不同（這兩個角色常常被搞混），以及從混亂之中形塑秩序。
你所加入的很可能是：一個只有極少數人理解或相信產品職能的價值的組織。
同時，你還必須管理組織成員對你的期待。
我曾經擔任過幾次這樣的角色，也曾經犯過不少錯誤。在這些錯誤之中，我學到最重要的事情是「架構」；如果你缺乏可以依靠的架構，擔任組織裡面唯一的產品經理，會非常無所適從。
說到這裡，你一定想問：「所以前三個月，到底該長什麼樣子呢？」
在進入這個主題之前，我們必須先認清一件事。作為組織裡面唯一的產品職能角色，壓力會非常大。你必須保持敏捷的思維，頻繁地在不同脈絡之中切換思考；當然，這會是忙碌又有趣的體驗 — — 前提是你願意做這件事。產品經理如同迷你的CEO，必須接觸公司的各種面向，而相關的知識並不是都能夠被「讀」到的，所以準備好使用你的武器庫裡所有裝備吧，借、懇求，甚至是偷，想辦法讓自己快速成長！
除此之外，和過去的工作相比，擔任組織裡唯一的產品經理，你也必須建立更多更緊密的關係。
不過你不需要太崩潰。請穩定自己的速度，保持開放的心態，以長遠的視角來思考自己所面對的狀況。此刻你所學習到的一切，在職涯中期可能無法直接派上用場，但相信我，未來回望這段經歷，你會發現這段時光非常充實。
前 90 天的重要任務：站穩陣腳
和 product roadmap 一樣，在實際跳進去開發功能之前，你必須設定主軸。以下是通用的版本，你可以依據自己身處的組織與你自身的性格調整排序，不過我會更建議大家同時處理以下這些面向。
🚩 記得：先花 3 -5 天的時間，確保自己在正確的軌道上
產品職能通常沒有明確的權威性，但得承擔所有的責任，因此最重要的事情是你必須在跨職能之間建立影響力。與你合作的團隊必須要將你視為專家才行。
那麼，你該如何站穩陣腳呢？
了解你所處的環境
我會將環境分成 4 個面向：
1. 人（People）
了解共事的人，以及組織之間的權力結構，對產品經理來說至關重要。例如 CTO 很可能對你擬定的 product roadmap 有相當大的話語權（他/她很可能就是那個說服組織招募產品職能加入團隊的推手）。
在進入團隊的前兩週，你可以透過安排與每個 stakeholders 的會議，來了解「人」的面向。
記得，stakeholders 並不必然是 C-level。尤其在小組織裡面，營運或是行銷很可能和 C-level 有差不多的重要性。
在與 stakeholders 的會議當中，需要試著了解以下 4 件事：
・他們對產品的抱負
・他的（以及他的團隊的）痛點
・他可以如何協助你
・他認為現有的產品 / 功能有哪些值得立刻被優化的地方
最後一點可以幫助你辨識你的 quick win。以我來說，我在前一份工作的前兩個星期當中，在與 stakeholders 的會議中發現行銷部門的需求始終都被排除在開發流程之外，他們的需求也從來沒有被拉上檯面；而他們最大的痛點，則是沒有適當的數據分析。
在這個會議當中，你必須建構你可以為他們帶來的價值。說明策略、機會，讓他們覺得你是一個有遠見的人 — — 讓他們將你視為專家。
📒 小提醒：不要給予承諾。有同理心的紀錄他們的需求，適當的回覆未來的「可能性」，但不要給予承諾（再次強調！）。
2. 流程（Process）
除了人之外，了解現在的流程也是很重要的。重點在於了解，而不是評價；如果可能的話，即使你徹頭徹尾反對現在的流程，也要盡可能搞懂為什麼流程會是現在的模樣。（舉例而言，現在軟體圈流行敏捷，但對於某些有外包需求的新組織來說，瀑布式開發簡單很多）
接受它。了解它。
了解流程可以幫助你明白跨職能之間是如何相互協作的。身為組織的新人，你可不想誤觸了他人的權責範圍，對吧？
3. 協議（Agreements）
在你加入組織之前，各個部門之間可能有著已經達成的協議；像是行銷部可能說好要有一個新的dashboard，營運部說好要有一個新功能。任何的協議都涉及到雙方，而你需要釐清所謂的「雙方」是誰，你在其中又扮演什麼樣的角色。你還無法掌握全局，跨部門之間已經確立的協議不該在你加入之後就被立即改變。
和未來待在公司的時間相比，前 90天非常短暫。
改變不需要急著在你的前 90天發生。
4. 數據（Data）
數據是產品經理的核心守備範圍之一，你需要先理解數據的可用性和準確度，包括：過去有產品的相關數據分析嗎？有任何追蹤或回報產品表現的工具嗎？
只有在建立好基準值之後，你才有辦法進一步展現「優化」所帶來的效益。
所以，找出你的產品 KPI 以及基準值，並理解目前的數據狀況；不論數據存在與否，背後都有隱含的意義 — — 如果有些數據不存在，這代表目前組織處在「沒有這個數據也活得下去」的階段，而這也意味著之後你應該要嘗試建立數據驅動的策略。
藉由掌握所處的環境，你可以完成以下 3 件事：
- 釐清架構和階層
- 行銷/宣傳自己
- 釐清未來要做的事
而你可以進一步將蒐集到的資訊，運用在接下來的幾個步驟當中：
取得 quick win
在你了解環境之後，quick win 的選項們會很自然地浮現（「流程」不該是 quick win 的選項，針對流程的優化，如同前面所談，是你度過前 90 天之後才該進行的任務）。一些簡單的調整和優化就可以打響你的名號，取得主管對你的肯定；不過當你在做這些事的時候，記得務必使用比較合宜的方式展現，才不會招來反效果。
評估 quick win 時，我個人是使用以下框架：
如果你可以讓管理層和 stakeholders 認同你的資源安排是對應到正確方向的，你就能夠以「好的產品人」的角色站穩腳步。
溝通、溝通、溝通
如果溝通不是你在前 90 天的核心主軸，那你的方向就錯了。在這段期間，你需要視 stakeholders 的偏好，慢慢地、逐步增加與不同 stakeholders 的溝通。
在進行溝通時，必須做到這 3 件事：
- 早點溝通（Early）：先知會對方你會做哪些事情，然後再做
- 頻繁溝通（Often）：透過設定好的溝通節奏，告訴對方你要做的事情
- 簡明扼要的溝通（Concisely）：直接展現給對方看你要做的事情，而不只是給一大堆文字
除此之外，你的 90 天規劃也需要與你的主管討論和溝通，如此一來才能幫助他們理解你會如何進入產品經理的角色。
如果一切順利，在 on board 90 天後，你應該要：
- 證明自己是可靠、有架構的、和組織業務有關聯的人
- 展現你的角色所能帶來的價值
- 為接下來要做的事情打下基礎
常見的問題
1.我應該成為一個通才，還是找到屬於自己的明確專精？
這還只是你加入組織的初期。你可能是個 data 狂熱份子，但在你尚未建立穩定的產品需求處理機制以及更有效率的團隊管理之前，你會被迫成為一個守備範圍很廣的通才。定義明確專精當然沒有問題，但別讓這件事成為你最關注的核心。
2. 同事一直把我視為專案經理！但我的角色明明就不只是在做專案管理！
專案管理是產品管理的一部份。如果組織對你的期待是「管好開發團隊的工作量」，那就把這件事做好，但你仍然要在商業機會、實驗與值得加入的優化等面向發聲。
有時候你必須要主動提高組織對你的期待：完成他們交付給你的主要任務，但展現出你遠比他們所期待的還能做到更多。
3. 其他人為什麼不聽我的？
反過來問，他們為什麼要聽你的？人們只會相信專家說的話，而你根本還沒有證明自己的能耐。這的確是件苦差事，不過也是每個人在尚未對團隊證明自己的可靠度之前的必經之路。
4. 有太多東西要改了！每個人的需求都好重要，我該怎麼辦？
信不信由你，但在前 90 天，你的「保證人」，aka 那個「認同產品職能價值的人」，是最重要的，你需要優先針對他的需求進行交付。HiPPO（Highest Paid Person’s Opinion / 辦公室裡拿最多錢的人，話語權最大）、FIFO（First In First Out / 先進先出）或先搞定辦公室裡的雜音製造者（Noise maker first）這類非典型或反邏輯的框架，反而是你需要參考的。
你的角色是帶領組織前進。先接受這些混亂以及自己必須參與其中的事實，但別讓這一切來定義你。
假設把握度夠高，「在混亂之中建立秩序」以及「策略發展」也可以納入你的 90 天計劃。
記得，身為組織裡面唯一的產品經理，「變革管理」和「產品管理」一樣重要。
享受你的旅程吧！
🖋 寫在後面： 翻譯完這篇之後，覺得好像又將裡面的概念更內化了，知識的output果然是很重要的。度過這份工作的前90天之後，我會再寫一篇文章分享自己的90天，有哪些可以與作者的建議對應，又有哪些面向發生了出乎意料之外的發展（現在已經出現了🥲...） 如果你喜歡我的文章，歡迎拍手或留言讓我知道！