團隊變形記（上）- 小型軟體產品團隊中，產品經理的多重人格
你看那多工的過動兒，一邊做歌一邊做功課，發展出到底是多風格還是多重人格？
— 熊仔《凶宅》我之前加入了一個快速成長的跨國團隊，在任職的兩年間，台灣團隊從 20 人成長到近 200 人。加入當時，PM 1 人、產品團隊 5+ 人（Designer, Full Stack Engineers），做的是 B2B2C 的 SaaS 產品，已經在其他亞洲市場初步驗證過，正要積極打入台灣市場。
剛開始，團隊分散在一個 co-working space 裡，工程師在共同工作空間租了幾個位子（隔壁就坐著其他公司的工程師），其他成員則是擠在一間小會議室裡面面相覷。台灣只有我一個全職的產品經理不打緊，重點是這還是本人此生第一次擔任產品經理的職位呢！只能說老闆跟我心臟都很大顆😎
以下是我剛上工時每天記錄的 Work Log，從中可以看出一些端倪。
你的職責包含（但不限於）以下事項
每次看到職缺 JD 上面項目寫著「你的職責包含（但不限於）以下事項 / Responsibilities include, but are not limited to」我都有種想摧毀螢幕的衝動，不過這就是社會現實啊！
了解產品＆使用者
TOOL — Intercom, Zendesk
熟悉目前的產品用途、使用者的使用情境，是一開始最重要的任務。上工頭兩週每天早上一來，除了使用產品、寫 FAQ 外，我也會用 intercom 跟 CS 團隊一起回覆使用者遇到的問題、蒐集客戶提出的回饋。
我也充當 Account Manager (AM) 去瞭解大型客戶的需求。客戶老闆親自出席外，也帶了第一線每日每夜操作我們產品的員工來，提出一拖拉庫的建議，讓人超深刻感受到使用者才是專家，而我本人什麼狗屁都不是。
產品研究、規劃、測試
TOOL — Google Doc, Excel
跟產品規劃相關的事情，包含蒐集回饋、決定下個要做的功能（當時還沒學到 prioritize 這個詞和它的博大精深😂）、研究、設計、寫 PRD、開發（專案管理）、測試、上線、維護，原則上沒人做的事就是我的事。
這時候的策略是「球來就打」，最多使用者要求的功能就先做，並沒有仔細分析使用情境和 use cases，而是抱持著先求有再求好的心態，快速上線超陽春的 beta 版本，有問題、有回饋就快速 iterate 並盡快推出新的版本。當然也因此踩了很多雷。
欸，其實很多雷是我自己親手埋下去的。
最可怕的東西就是產品穩定性了！沒有專門的 QA 負責測試，所有的 test cases 都是產品、工程師、CS 共同建立在一份 Excel 裡，常常漏掉測項外，各種功能之間的 dependency 錯綜複雜，上線時發現產品壞掉馬上 rollback 的經驗也不少。
總之每天都在冒汗、被罵，下個部分組織團隊與建立團隊流程真的超重要！
組織團隊＆建立團隊流程
TOOL — Slack, Excel, Trello
小團隊說好聽是彈性、說難聽是混亂，建立工作流程幫助我們釐清問題、提高效率，並瞭解之後必須招募什麼樣能力的人加入，來補足流程中的斷點。
產品規劃的流程優化是從我們每次寫的 PRD / spec 內容、產品上線後的反饋來學習我們少考慮了些什麼。舉例來說，產品文件內 use cases & user stories 的要寫到多細、test case 由誰來寫等等，把這些規則與流程文件化，讓團隊內每個成員都可以更新。
專案管理一開始是用最簡單的 Excel 表單紀錄，欄位包含功能、負責的工程師、完成狀態、優先順序。後來改為使用 Trello 看板管理，請參考 Trello Inspiration。
跨部門溝通主要是接收來自 CS、Sales 等會接觸客戶與使用者的團隊提出的需求、BUG 修復，因為需求管道太多、內容也太多，所以我們主要用 Slack channels 來區分。
#issues 處理即時需要修復的問題；
#features 代表功能建議，後期我們也請其他團隊整理在 Excel 表單裡讓我們統一看；
#keyaccounts 則是大型客戶提出的需求，優先級會比一般需求更高。什麼才是最難的事
欸，最大的困難就是流程、產品狀況一片混亂，現在要做什麼、明天要上線哪個功能，常常都藏在某 Slack channel 對話串、Google Drive 某處或某個人的腦裡。對團隊現況有足夠的認知，才能努力不被洪流沖著走。
身為一個團隊成員…
- 沒有人會主動告訴你該怎麼做，因為大家也都不知道該怎麼做
- 面對混亂時，保持積極的態度去釐清問題、提出解決方案，並相信團隊能一起克服難關
- 接受自己、團隊會犯錯的事實，但要不斷從錯中學，如同產品不斷迭代
- 老闆決策說變就變，隕石開發沒在跟你開玩笑，重點是要了解決策改變背後的原因。如果合理，就說服團隊一起朝新的目標前進；如果不合理，就跟老闆多多溝通囉～
身為一個團隊負責人…
- 要團隊跑得快，就要給足夠的權力與資源
- 要產品成長快，就需要有更成熟的工作流程、更專業的成員加入。但最困難的事，就是說服資深工作者、高階經理人加入小公司（下篇來討論吧）
什麼才是最重要的事
回想起我們團隊成長（又痛又歪的長）的過程，這些小堅持功不可沒。
一、溝通頻繁、目標明確、會議時間短
無論是產品會議、需求會議、討論流程的會議，開會前一定會先將 Meeting Agenda 發出來、會後馬上整理會議記錄與 Action Items，這讓我們的時間分配非常有效率、工作也很目標導向，所以可以跑得快。
產品與工程師每天都會有 10 分鐘的 stand-up meeting 來了解彼此的工作事項與需要幫忙的地方，如果對於工作方法、使用的工具、團隊分工有疑問也都可以在這時候提出來很快的討論。
舉例來說，每個任務需要幾個工程師 code review、Trello cards 增加欄位或標籤，這種提議是可以現場決定並開始執行；deployment 流程優化這種比較複雜的議題，我們就會再另外找時間討論細節。重點是任何人有想法都及時提出，及時改善。
[stand-up meeting notes]
1. 昨天做了什麼（專案管理與追蹤）
2. 今天要做什麼（確認優先級）
3. 遇到什麼困難需要團隊協助（團隊合作排解問題）二、老闆與團隊的每週 1 on 1
一開始還沒有主管時，會跟 CEO、COO 1 on 1，後期則對到產品主管、技術主管。面對面提出自己的疑問、建議、回饋給團隊經營者，能幫助他們快速下決策；而他們對我工作方法上的真知灼見也總是很受用。如果提前跟老闆約好 1 on 1 時間，我也會先把問題、建議都列出來（延續上一點，效率！）
[1 on 1 meeting notes]
- 這週過得還好嗎？（什麼爛開場白，但每次開場白都是這樣哈哈哈哈哈哈！）
- 跟團隊工作有遇到什麼問題嗎？
- 各種任務的時間分配與優先級為何？哪些佔了很多時間？我覺得那是我該做的嗎？
- 團隊還需要招募什麼樣的人、提供什麼資源，才能幫助到我？
- 有什麼是公司該做卻沒做的嗎？有什麼有趣、有潛力的產品方向嗎？
- 其他建議、回饋、疑問當每個人都在努力的成長，團隊才有機會快速成長。
延伸閱讀《The 4 questions you should stop asking during your one-on-one meetings》
這一篇，寫得好像做事很有架構、邏輯，但其實都是事後整理出來的結果。當時每天都不知道在幹嘛，發現A問題就先處理A、出現B問題就插件弄個B，只能混亂中求生存、叢林中找出口。
下一篇，會分享我們招募新的產品成員進來後，他們帶來了什麼超棒超讚的改變，而又有哪些痛苦的根源正在發芽。
同場加映：入門書籍推薦！早期還不太會規劃產品時，《使用者故事對照》提供了很多想法與切入點。專案管理則是從《人月神話》、《看板實戰》這兩本書吸收了不少心法與執行方法。想看讀書心得的請舉手 (._.)/
謝謝你的閱讀！如果有任何疑問、想聽的主題，歡迎留下 Private Note 或留言給我 📒如果單純想給我一點鼓勵，請給我 1–10 個拍手；
如果覺得文章對你有點幫助，請給我 11-20 個拍手；
如果想看更多合作與溝通的文章，請盡情長按拍手（50個拍好拍滿也沒問題）讓我知道 👏🏻想要持續追蹤我們的最新文章，請追蹤產品三眼怪實驗室 (◉◉◉)
