【PM總動員】如何從 0 到 1 建立組織產品文化？FunNow 產品經理的實戰分享
【PM總動員】是產品三眼怪的每月定期客座單元，挖掘邀請海內外業界產品開發相關領域的大大們和大家分享！本月邀請到的是 FunNow 產品經理謝沛剛，曾在 Gogolook、KKTV 擔任PM，並於2018下半年加入了主打「都會享樂即時預訂」的 FunNow，開始了一段從 0 到 1 打造一個產品團隊的旅程。過去這兩年，產品團隊從 5 人成長到將近 20 人，公司也從 30 人成長到超過 100 人。本文想與大家分享，作為一個產品經理的角色，做了哪些嘗試來試圖建立起一個高效的產品團隊，而過程中又有哪些學習。本篇文章包含
✔ 為什麼加入了 FunNow？
✔ 穩固基礎：溝通的基礎建設＆工具導入
✔ 打造團隊：專注於價值的流程＆文化
✔ 發揮產品團隊的影響力：從專注「交付」往規劃「產品策略」邁進
▍為什麼加入了 FunNow？
「選擇你熱愛的產品，才能將產品做到極致。」
FunNow 是一個解決資訊落差的平台，從 2015 年開始營運，主打都會生活各種享樂活動的即時預訂，包括餐廳、酒吧、按摩 SPA、旅宿、美髮、美甲美睫、運動課程、KTV…等等，讓使用者能即時掌握周邊有位子的店家，不需要排隊也不需要打電話就能預約。Last Minute 預訂或是選擇離峰時段還能享有不錯的優惠。而對店家來說，FunNow 能幫助他們將閒置的資源透過平台的曝光賣出，減少浪費、創造更多的營收。除了在大台北、台中、台南、高雄…等台灣城市有服務，也進軍到香港、日本、馬來西亞…等海外地區。
職涯累積
從踏入職場，開始擔任產品經理這個角色後，前後歷經了四個產品團隊，有最後被大公司併購的小新創，也有已經在全球擁有千萬用戶、公司近百人的跨國企業。過程中累積了許多寶貴的學習，曾經打造過全新的產品，也有在既有成熟的產品上做優化和用戶成長的經驗，但還沒有從零到一親手建立過一個產品團隊。因此，當時在了解 FunNow 正處於一個準備擴張、需要建立團隊的階段，就引起了濃厚的興趣。
精實團隊
當時 FunNow 的產品團隊（當時叫做 IT 部門）只有四位工程師，卻可以建構出一個成熟穩健的即時預訂平台，撐起一年數千萬的營收。除了台灣以外也擴展到香港和沖繩，準備要進軍吉隆坡和東京，也獲得許多知名品牌的信任，與米其林指南、LINE 和數家銀行都有深度的合作。以一個當時只有 30 人的公司規模，能做到這樣的成績是很難得的，促使我想要加入這個精實剽悍的團隊一起努力。
對產品的熱情
我在加入的一年多以前，偶然間從 App Store 上發現 FunNow 後，就一直是愛用者，因此當時想要做職涯的轉換時，第一時間就開始找尋是不是有能加入 FunNow 的機會。對我來說，要把產品經理這個角色做好，選擇自己很有熱情的產品非常重要，唯有如此才能有源源不絕的動力把產品做到極致。
▍穩固基礎：解決溝通問題
2018 年的下半，FunNow 剛結束 A 輪募資。搬到了大兩倍的辦公室，也準備開拓兩個新的海外城市的營運，預計在一年內員工人數會有兩到三倍的成長。當時台北辦公室大約有 30 名員工，包含工程、行銷、設計、業務、營運、客服…等部門。這樣的團隊規模，已經開始出現一些溝通問題，例如團隊成員對專案目標不了解、溝通效率低，尤其是跨部門的協作過程中容易會有漏球的狀況。
當時團隊使用 LINE 作為主要的溝通工具，包含部門內的溝通、跨部門的專案協作、客服及系統問題的回報追蹤。在團隊還小的時候，用純通訊軟體來做溝通還能勉強應付。但當時 FunNow 處於準備要進行快速擴張的時期，一個高效溝通的平台會是非常重要的基礎建設。
先前在其他團隊使用 Slack 的經驗很好，光是基礎的訊息功能就比 LINE 強大很多 (畢竟 LINE 是專注於朋友聊天的情境，Slack 則是專注於工作溝通的情境)，像是能夠快速建立不同主題的頻道、有 Thread 討論串、方便的權限控制以及方便的歷史紀錄和搜尋功能。另外還支援許多第三方工具的整合以及打造各種自動化機器人的彈性，不論是新創的小團隊到上千人的大企業，都能客製成適合的樣子。
但是，要怎麼改變大家的習慣呢？
大學時，資訊管理課的教授就曾跟我們說過：導入任何工具/系統，最困難的永遠是「人」的問題。當團隊已經習慣了一種工作的方式，要採用新的流程，大家得要花額外的時間來學習和轉換，如果沒有好的變革管理，推動起來可能會曠日費時，甚至可能失敗收場。
在這個過程中，我使用了兩個步驟來讓事情進展得更加順利：
1. 先導入少數團隊：鄉村包圍城市
當時工程師們原本就有使用 Slack 來做一些系統異常通知和 log 收集，大家的電腦中都有安裝著 Slack，也比較能快速了解整合其他服務 (JIRA, CI/CD, Github…) 進通訊系統的好處。因此當時先從工程團隊開始推動，讓大家的溝通從原本使用的 LINE 群組，慢慢轉移到 Slack 上的 channel，也藉此測試看看要先在上面進行哪些設定，才能讓大家順暢的使用。
當工程團隊都習慣用 Slack 而漸漸不用 LINE 溝通公事之後，其他團隊要討論一些產品主題或是回報系統問題時，就也必須嘗試轉移到 Slack 上。像這樣從一兩個小團隊開始，再慢慢向外擴展影響其他人，像是一種鄉村包圍城市的戰術。
2. 做出 show case：感受實際價值
要鼓勵大家改變，最好的方法就是讓大家看到改變後能帶來的實質效益。當時在 FunNow 的所有夥伴都需要輪值客服，藉此讓大家從第一線了解使用者與店家在使用平台服務的過程可能會遇到什麼問題。在沒有任何管理工具的情況下，有需要後續處理的客訴問題，都是記錄在 LINE 的群組中，客服主管必須在冗長混亂的訊息記錄中一一爬文和回覆處理狀況，操作起來相當不便，也容易有遺漏的狀況。與客服主管和工程團隊討論後，我們使用了一套表單工具 Airtable，並整合進自家的後台系統和 Slack 中。有訂單發生客服問題時，輪值的客服夥伴可以從後台的訂單管理功能中自動帶入訂單資料到表單中，填寫送出後會記錄在表單中，並且自動在 Slack 上發出通知，若有需要討論的部分，也可以直接在 Slack 上進行討論。
這個改變帶來的效率提升非常顯著，大家很快就感受到 Slack 帶來的好處，便開始陸續將各部門、各專案的溝通都轉移到 Slack 上。一直到現在，FunNow 的 Slack 上已經有近 200 個 channel 在進行各種主題的協作溝通。
後續也推動了 Asana、Google Docs …等協作工具的使用，也是使用相同的方式：先從一兩個小團隊先開始嘗試、做出 show case 後再推行給所有人。
▍打造團隊：建立文化與流程
Step 1：建立文化
在我加入 FunNow 時，當時的工程團隊叫做「IT 部門」，由四位工程師組成，已經有一段時間沒有產品經理，僅有的一位設計師則是兼任行銷視覺設計和產品設計。當時的團隊狀況像是一個 Delivery Team (可以參考 Marty 的 Product vs. Feature Teams 這篇文章)，比較負責產出 (output)，而忽略帶來什麼成果 (outcome)。比起已經有穩定基礎的大公司，FunNow 處於剛驗證完 Product-Market Fit 的階段，產品應該不斷的創新、創造價值，才能實現快速的成長和擴張。
對資源很有限的新創團隊來說，想要持續成長、獲得更多使用者和市場佔有率，進行高效的產品創新並持續提供真實的價值給使用者是非常重要的。為了打造一個能專注於成果 (outcome) 的團隊，首先我們先將團隊的職能補齊。花了大約半年的時間，團隊人數從 4 人成長到 10 人，有專職的產品設計師 (包含較專注於了解使用者需求、設計使用流程與資訊架構的 UX 設計師和較專注於介面設計的 UI 設計師)，工程師也開始能切分出專職前端、後端的角色，甚至還有了專注提升開發效率和系統維運的 DevOps。
接著，我們也將部門的名稱由原本的「IT 部門」改變為「產品部門」，不僅負責系統開發，更重要的是負責所開發出的產品是否能真正為使用者、為店家、為公司帶來價值。
FunNow 的產品部門負責三套系統的開發和維運，包含面向消費者的預訂平台、面向商家的控位進單系統以及公司內部使用的管理後台。除此之外，還有許多和外部夥伴合作串接的專案。一個開發週期內，同時在推進的專案可能有五、六個，還有既有功能需要維護。這樣的團隊規模要負責這麼大的守備範圍，建立起團隊成員的責任感 (ownership) 非常重要。大家為了團隊整體的目標努力，也為產品的成敗負責。我們時常提醒團隊的成員：「我們都是產品部門的一員，雖然大家的職能不同，但我們的目標都是要把產品做到最好！」
除了建立責任感 (ownership) 以外，團隊合作時能如何達到高效率，我們主要採取以下三個具體的實踐方法：
- 透明溝通：凝聚共識、自省進步
要讓團隊能發揮高效，首要任務就是要凝聚大家的共識。當所有人都往同一個方向努力時，才能產生最大的影響力，而不會因為每個人想法落差大，產生許多拉扯而虛耗資源。
產品經理作為團隊內外溝通的橋樑，我們常常和 CEO 討論公司的短/中/長期目標、進攻市場的策略、資源的配置…等等。接著帶回團隊中，讓每個成員都能清楚了解公司的狀況，大家站在同一條船上，一同思考如何面對挑戰。
透明直接的溝通，也能讓團隊或個人遇到的問題即時被反應出來。在團隊中，我們鼓勵大家直接的給予彼此回饋。隊友做得好，給予正向的回饋和鼓勵，讓好的事情繼續推動。覺得隊友有能改進的方向時，也勇敢的提出建議。有做得不夠好的地方或是有不小心的失誤也不用愧疚，誠實的面對、深刻的反省，大家一起討論有什麼可能的改變可以避免再犯同樣的錯誤，有自省能力的團隊才能不斷進步。
2. 相互補位：團隊目標最重要
團隊有了一定規模之後，適當的分工是很重要的。拿工程師來說，一般軟體公司若資源充足的狀況下，會將工程師分為專職前端開發和專職後端開發的角色，而同樣是後端工程師，可能也有人比較擅長架構的設計、有人比較擅長與合作夥伴的系統對接。除了技能和經驗以外，個性上也可能有人喜歡做探索性的新功能、有人喜歡重構既有的功能進而提升效率和可維護性。根據每個專案的性質和階段，盡量讓每個成員能主責自己擅長的部分，能夠更有效率地向前推進。
有了專業分工，更重要的是必須要有相互補位的觀念，兩者缺一不可，才不會因為分工而造成每個人自掃門前雪的狀況。補位是團體競賽中很常見的行為，例如棒球比賽時，對手打了一支短打，一壘手衝向前追球，一壘空了出來。眼看打者就要上壘時，投手即時趕到一壘壘包上，接住一壘手傳過來的球完成了刺殺。雖然投手平常主要的任務是投球，有需要的時候也需要協助各個壘包的防守，這就是有好的補位觀念。如果投手只在意自己的投球而不參與守備，就像工程師只關注程式碼而不在意交付的時程，或是設計師只關注設計而不管實作的可行性和公司的商業目標。也許自己的工作範圍內並沒有缺失，但整個團隊卻以失敗收場。
在 FunNow 的產品團隊中，大家相互的補位的情況非常常見。先做完手邊工作的成員，會主動協助其他隊友。隊友碰上困難，其他成員也會幫忙找尋解法。甚至，在產品經理比較繁忙的時候，也常可以看到設計師或工程師直接擔任一個專案的負責人，直接負責整體的規劃、對內對外的溝通以及時程的控管。
3. 流暢協作：為隊友多做一點
進行自己手邊的工作時，也為隊友們多想一步、多做一點。設計師盡量將流程細節定義清楚，讓工程師開發時能更順暢。工程師完成開發後，先自己進行多次測試，確保品質後再交付給測試工程師驗證。不僅讓整個團隊推進的速度更快，也兼顧了個人更多方面的技能和經驗成長。
Step 2：團隊流程建立 / 優化
工欲善其事，必先利其器。有了合適的團隊文化，也要有好的協作流程來讓成員間的協作更順暢。
▍文件化
在我剛加入的時候，團隊正在進行一個大改版的開發，包括預訂平台、商家系統和內部後台都整個重新構築。但當時主要只有一張張介面設計圖可以參考，其他的文件都很缺乏。當時，因為想要了解各種交易折扣計算的邏輯，我用初步開發完成的系統來做測試，選了一樣的商品、使用了一樣的優惠折扣，結果三個平台 (iOS / Android / Web) 計算出來的結帳金額都不一樣。深究後發現是因為因為幾種不同的折扣方式可以疊加、又可能有不同幣別的轉換，折扣計算和四捨五入的順序沒有明確的定義和文件可以參考，因此大家實作出來的結果不一致。進行一陣討論後，才將規則清楚定義下來，但原本已經開發好的程式又需要進行調整。雖然團隊很扁平，溝通很快速直接，但沒有適當的文件紀錄來輔助溝通和記憶，常會造成開發時需要來回重複確認，或是開發完成後又需要修改，造成重工的狀況。
於是，團隊一起討論後，決定挪出一些資源來將開發的規格文件補齊。我們主要使用 Axure RP 作為撰寫文件的工具，文件中會包含像是模組架構、使用流程、顯示邏輯、錯誤處理…等等明確的流程定義。當然，對資源有限的新創團隊來說，在完備性和速度之間作平衡是很重要的。在競爭激烈的環境中，不太可能可以完成停下來等文件都完成了才繼續往下開發。因此我們先從最重要的預訂及交易流程開始進行，再慢慢補上其他比較次要的功能。一直到快兩年後的現在，整個產品已經大約有 80% 的部分是有清楚的規格文件可以參考的。不僅幫助開發順暢，也讓 QA 工程師在測試時有明確的預期結果可以驗證。當團隊有新進的成員時，也能夠快速的了解整個產品。
▍開發/發版節奏
團隊採用敏捷的方式進行開發，基本上以兩週為一個 Sprint。但有可能因為要做的功能太大又無法切割，而變成三週。也有可能因為要小步快跑衝刺，而改成一週一個 Sprint，根據公司策略與目標的不同保有調整的彈性。
在一個 Sprint 過程中會有四個主要的會議：
- Pre-planning Meeting
在 Sprint 開始前，產品經理、設計師以及前後端的 lead 會與 CEO (也是 Product Owner) 進行討論，對焦近期公司的策略方向、將 backlog 進行排序、討論各功能的目的、討論初步的設計以及實作的可行性和粗估需要的開發資源和時程。 - Planning Meeting
Sprint 的一開始，大家會一起討論這個 Sprint 的主要目標，包括要完成的功能、需要修復的問題。設計師會和大家講解規格和介面、流程設計。之後工程師會繼續討論實作的細節和分工。 - Refinement Meeting
(Part 1)
在 Sprint 進行一週以後，大家會花大約半小時的時間來討論目前實作到一半的部分有沒有遇到什麼困難以及有沒有需要調整實作的 scope （其實大部分困難都會在每日的站立會議中就已經被提出和解決）。
(Part 2)
接著，會再花大約一小時的時間，討論 backlog 中近期準備要實作的功能。會先由產品經理和大家說明需求的背景，像是需求的目的、想解決的問題、針對的目標客群、和公司的什麼策略相符…等等，也會搭配一些量化的數據或是質化的研究結果來讓大家更能掌握需求的全貌。呼應前面所說：我們都是產品部門的一員，雖然大家職能不同，但是讓產品變得更好是每個人的責任。因此，在設計初期，我們會在這個會議上盡可能的說明完整每個需求背後的脈絡，鼓勵大家從使用者的角度出發，一起討論激盪出最好的解法。這樣不僅能夠幫助設計師在前期就能收集到許多靈感和回饋，也讓工程師們更有參與感，對之後的實作更有責任感 (ownership)。 - Retrospective Meeting
在一個 Sprint 結束後，團隊會對這個開發週期中發生的事情進行回顧。這是我認為非常重要的一個會議，大家會列出覺得做得好的部分，之後可以繼續保持或是往那個方向繼續推進，也會表達對其他成員的讚揚和感謝 (好意思的話也可以表揚自己啦XD)，能讓大家感受到自己貢獻的價值，也讓成員間互相協助、為團隊目標努力的風氣更興盛。更重要的是，大家也會列出可以做得更好的部分，並進行投票、選出重要的問題，進一步討論可能可以改善的行動，避免重複發生一樣的問題。有學習檢討能力的團隊才能不斷優化調整，往更流暢高效的方向進步。
▍發揮產品經理的價值：往策略規劃邁進
以上是針對建立團隊文化和流程的分享，接下來，想和大家分享這個過程中，作為一個產品經理自身的成長學習。
大家應該都看過這張圖，說明了產品經理的職責就是要負責在技術 (Tech)、使用者體驗 (UX) 和商業 (Business) 三個重要的領域中穿梭，平衡各方面的考量，規劃出現有資源下最佳的產品解決方案。
而產品經理在解決產品問題的過程大致上就是一直在問題探索 (Problem Discovery)、策略假設 (Strategy Hypothesis) 以及方案交付 (Solution Delivery)這三種活動中來回穿梭 (可以參考 Jason 的這篇文章了解更多)。
▍從專注交付 到 思考策略規劃
以自己的經驗和看到身邊許多朋友們大多都是先從偏設計端或技術端起步來開始產品經理的職涯。一開始可能是從專案經理 (Project Manager) 或是產品企劃 (Product Planner) 的職務開始，大部分都是已經接收到公司決定要做一個功能/專案，而自己的職責是負責執行和交付，例如控管一個專案的執行或是撰寫產品規格文件 (PRD)。主要都是在解法空間 (Solution Space) 針對已經被定義好的問題來規劃解法和交付產出。
對於基礎的知識和技能（例如：流程設計、規格撰寫、時程管理…等等）有了一定的經驗累積後，可能會開始往需求端前進，在使用者身上尋找值得被解決的問題，這時候會接觸到比較多研究的方法，包括質化的使用者研究和量化的數據分析，在問題空間 (Problem Space) 中進行探索。
當給定需求能交付出不錯的解決方案、給定市場能探索出精準的問題與需求時，應該就可以算是合格的產品經理了。但是，在相似的需求、相近的解決方案之間，不同的團隊可能會使用不同的策略來進攻市場。
「是要大幅補貼擴張來搶市場先機還是要先專注做好小區域的市場？」
「是要主打客單價高的精品還是要主打 CP 值高的實惠商品？」
「是要整條產業鏈都一手包辦還是要和其他公司策略聯盟？」
除非你的產品有很強大的競爭壁壘，像是 Tesla 的電池有獨特的專利技術或是中國的國企有國家的資金和法規保護，否則，當市場中有許多同類型的競爭者時，策略的規劃和選擇就會是能否在激烈競爭中出頭的關鍵。
掌握用戶和市場又了解團隊技術能力的產品經理很適合往策略規劃嘗試和學習，就我自己來說，也是從原本專注於設計與技術來解決使用者的需求，開始更著重商業面的各種考量。
▍策略規劃：一切關乎於資源取捨
所謂策略規劃，追根究底就是因為團隊資源不足，所以需要進行取捨，把資源放在正確的地方，設法將效益最大化。對於產品經理來說，每天在各種需求間做優先排序 (prioritization)、規劃產品路線圖 (product roadmap)，在有限的人、預算、時間之下設法達成目標，就是在進行策略規劃。在這兩年多的過程中，我時常在做各種決策時都非常掙扎，如何在當下有的資源之下運籌帷幄來達到最大的效益，需要許多的智慧和經驗累積，而常常在不同的階段也會有不同的觀點去做決策。但總體來說，我大概有以下幾點的學習：
- 估算效益幫助選擇
當有很多可行的方案時，估算能幫助我們選擇潛在效益最大的方案來執行。RICE Scoring Model 就是一個簡單好上手的估算方式。雖然估算的準確度很取決於團隊對市場的理解和對技術的掌握度，一開始可能會算得很不準，但就算是比較個相對分數，也會比只靠直覺來決策可靠許多。 - 對齊公司策略
如前面所提，當團隊中所有人努力的方向都一致時，才能發揮最大的效益。在決定產品開發的順序時，對齊公司的整體策略方向很重要。產品的功能開發完成後，也要有相對應的資源跟上（好的行銷推廣、足夠的營運人力…等等），才能發揮綜效。 - 推進和固本間的平衡
新創公司在追求市佔時，常為了要搶得市場先機而一直不斷的快速推進。雖然對齊公司的策略很重要，但除了短期的擴張目標，中、長期來說產品是否還能快速推進，也是產品經理該把關的地方。如果在快速推進的過程中，累積了太多的技術債或是傷害了使用者體驗，也需要適時的把一些資源拉回來解決穩固產品基本面的維護。 - 「現有資源」不是無法改變的限制
作為專注交付的個人貢獻者 (individual contributor) 時，很容易被限縮在「現有資源」之下。但當身為一個執行策略規劃的管理者時，不應該把現有資源當成是無法改變的限制。只要你對市場和團隊的掌握度夠高，能估算出若增加一些資源，可以多增加多少產能（例如現在團隊的瓶頸在於設計的產出，多增加一個設計師可以讓團隊整體推進的速度增加五成），那就勇敢的和老闆要資源吧！
你可能也會有興趣：
如果單純想給我們一點鼓勵，請給我 1–10 個拍手；
如果覺得文章對你有點幫助，請給我 11-30 個拍手；
如果想看更多硬體產品領域相關文章，請盡情長按拍手（最多50個）讓我們知道 👏🏻想要持續追蹤我們的最新文章，請記得追蹤「產品三眼怪實驗室」(◉◉◉)！
我們每週末都會認真更新文章唷！千萬別錯過了✨
