Prod/Eng mindset shift: From 500M to 500 DAU
身為一個曾經在 FB/IG 開發產品長達五年半時間的菜鳥創業家，對於大公司給予我過的訓練時常是又愛又恨。愛的是完整的系統性學習讓我很自然的能把過去建造產品的經驗複製到現在的開發流程中，壞的是舊有的一些理所當然的習慣，現在卻成了我的最大阻礙。
在進入到兩者差異化比較之前，我想先簡述一下在 Facebook 時期的產品經驗。
Facebook產品流程 SOP
我在 Facebook 曾經待過兩個不同的組，雖然產品本身很不同，但流程方面其實是大同小異。你的小組一定屬於某個大組，這個大組又再屬於某個更大的組，一路往上推到 Org 層級。而這每一個層級都會背負一個 metrics goal，可能是營收、用戶時間、月活躍人數或是用戶感受等等。但身處你在的小組，你其實只在乎從上面分下來你要負責的那個 metric，就算隔壁組正在如火如荼徹夜加班的挽救用戶感受，如果你們組目標是營收，用戶感受的變化於你也只是背景的一個微弱的雜訊（除非你真的讓用戶感受下降太多毀了隔壁組一季的心血，那他們可能會拿刀來質問你）。
所以，你有一個清晰的目標，你有一個健全的團隊（包含PM, Eng, Design, Data Scientist, Content, …)，更重要的是，你的 playground 是一個 500M DAU的 App (以 Instagram 為例），不管推出什麼樣的新功能，按下 launch 按鈕的那刻就會有 million 等級的訊號給你反饋，更棒的是這些數字化的統計會連信心水準都自動幫你算好，你的工作只剩下確定你關心的那條 bar 是不是綠色的就好。
於是在 metrics goal 確認了之後，不外乎會有以下的流程進行：
- PM 帶領團隊進行各種 brainstorming 跟討論，大家各自提出什麼樣的實驗可能有助於達成團隊目標，PM 評斷優先順序之後跟團隊確認。
- Design & Engineer 團隊分別開始規劃時程表及實作。
- Engineer 會先產生 design doc, 主持 tech review 尋求其他 engineer 的意見，確保工程設計足夠 scalable，也能兼容於其他組的程式碼之上。
- Coding & code review, 大家對於 readability & scalability 的設計特別注重。
- 在產品實作的尾聲會有一連串的穩定性測試，包含組內測試、QA team 外包測試、內部用戶測試等等。
- 產品 launch，然後等著收集 data 看看成效，再由最專業的 data scientist 分析實驗成果，完成一個循環。
以上描述的產品開發流程，在我辭職離開 Facebook 之前，幾乎以為它就是通用的真理了，因為這樣的循環已經在 Facebook 被千錘百鍊的測試，怎麼可能會有不適用的地方？
新創產品流程SOP = 矇著眼睛打怪實戰經驗
扛著我沒意識到的 FB 大包袱，我開始打造 Cooby。首先就碰到了第一個問題，我們要訂的 metrics goal 是什麼？習慣眼前有根別人釣的胡蘿蔔要追著吃的我，根本沒想過如果要自己畫出那根胡蘿蔔該怎麼畫，甚至在根本沒有產品的時候，數字要怎麼訂才合理？然後，產品開發的界線應該要怎麼劃分？雖然我們一直強調要推出 MVP，但要花多少時間、要做到什麼程度才能上線？上線了以後要怎麼知道使用者喜不喜歡我們？一樣也可以用數據來判定嗎？
我花了半年的時間，試圖將包袱裡的一個一個錦囊妙計拆開來用，卻發現我學的少林寺武功，在伸手不見五指的黑暗世界裡根本派不上用場。創業對於目前為止的我來說，就像矇著眼睛在未知的世界打怪，不要說要學會什麼武功才能走到終點了，連路在哪裡，哪裡可以點燈都沒有任何指示，一切只能靠自己的經驗跟直覺往前進。
在目前為止的路途中，我漸漸意識到我現在此刻所在的地圖與過去在 FB 的差別，開始逐步建立黑暗世界的生存方法，試著歸納出以下幾點分享給大家：
1. Speed is the only thing that matters
產品推出速度至關重要
雖然說 Facebook 一個很有名的標語就是 Move fast and break things，跟其他大公司相比 Facebook 可能真的算快的，但實際上這樣的速度在新創是遠遠不夠的。在新創每多浪費的一天就是多燒一天的錢，尤其是在產品還沒有推出的時候。產品沒有推出，你沒有辦法拿到外界最即時的反饋，你就不知道你自己在家裡養育的這個寶寶到底受不受歡迎。
Cooby 在最初也花了很多時間（半年左右）才推出我們的第一個版本，即使當時我們嘴上一直說要只做 MVP，但還是不小心勾了一大列我們認為是 MVP 的功能，注意，是我們團隊認為是，而不是用戶認為是。這就造成了實際產品推出的時候收到四面八方各種不同的意見，甚至有些功能花了很多時間做根本就沒有人使用，造成了資源跟時間上的浪費。在這邊我想要強調的是，從一個 idea 到收到使用者反饋的時間要越快越好，團隊的人再怎麼用心仔細的去想也都不是真正的使用者。只有使用者能夠告訴你你做的事是不是他要的。
產品開發速度
身為一個有強迫症又被FB訓練過的工程師，在開發的時候，我自然而然的就會把一些過去非常被重視的 scalability 與 stability 帶到團隊來。老實說這不是一件壞事，但卻是一件跟速度會互相牴觸的事。當你花很多時間在思考怎麼讓程式更有可擴展性，用很多漂亮卻花時間的方法實作產品，你得到的可能的確會是一個在未來開發更快速，在此刻又更穩定的產品，但，你真的確定你未來還會繼續往上開發嗎？
別誤會我的意思，我並不是説 scalability 不重要，而是當你在做出想要著重 scalability 的決定時，請再三跟自己確認一遍這個產品真的有很大的機會需要被 scale。創業有太多未知的可能，在這段摸索的過程中，有太多的原因會讓你改變功能，甚至是改變產品本身，只要市場回饋給你的東西不同，你過去的所有超前部署可能都會化為烏有。在 Facebook 的 scalability 之所以重要，是因為 scaling 就是這個階段的FB最重視的事情，如何在這麼龐大的組織同步推出這麼多龐大的功能，engineer 的程式擴展性就是決定性的因素。但在新創，活下去才是這個階段我們最該重視的事。
此外，stability 在 Facebook 絕對是一個沒有第一也有第二重要的事情。身為一個 Facebook 工程師，最重要的事情就是你的產品夠穩定，如果有嚴重的 bug，絕對是會半夜奪命連環 call 把你 call 起來修到好才可以睡的程度。但那是因為 FB 用戶就等於錢啊，而新創，你真的有這麼多的用戶嗎？如果連使用者都沒有，誰真的會碰到你剛寫的那個 bug 呢？
Again，這裡並不是在說穩定性不重要，如果你的產品天天噴 error 到根本不能用肯定是會失敗的，只是當它不是到最嚴重的程度，而且跟速度相抵觸的時候，我認為速度還是更重要的。Bug 可以晚點再修，但消逝的時間就是你能再早一點測試市場的機會，過了就沒有了。此外，其實早期的使用者對於錯誤的容忍性比你想的還要高很多。如果你的東西真的扎扎實實的解決了他們的痛點，一些產品的小瑕疵頂多換來一些抱怨，是沒有那麼容易流失客戶的。相反的，如果你花了很多時間，把你的產品修到完美無缺卻沒有真正解決使用者的問題，那才是真的失敗。
2. Do things that don’t scale
在 Facebook 的訓練，因為使用者是以 Million 甚至 Billion 在計算的，不只是產品開發上 scalability 重要，在收集反饋看 data 的時候，scalability 更是重要。FB 內部開發了各式各樣的工具幫助大家更好的判讀 data，因為大數據時代，這些數字就是答案。可是，早期新創根本就沒有這些數據可以看。老實說，我花了好長一段時間才領悟到這個這麼簡單的道理。對我而言，設計足夠好的 logging 就是推出前不可或缺的事情，因為沒有 logging 就沒有 data，而 data 就是我以為的唯一獲取反饋的方式。但我忘記在新創的數字，其實小到根本沒有參考價值，而且數據根本不是最重要的反饋管道。
使用者深度訪談其實才是這個階段的產品最重要的收集反饋管道。因為你還在打磨你的產品，你對用戶有無限多的 assumption，這些 assumption 必須要靠一個一個訪談才能慢慢釐清楚。在訪談之中，用戶會告訴你他的背景是什麼，他怎麼使用你的產品，他還希望你的產品增加什麼樣的功能，你甚至可以看到他的情緒。這些都不是在二維圖上的一個點能告訴你的珍貴資訊，而這些資訊就是你新創路上很重要的明燈。
除此之外，Cooby 還在這次推出產品後，在 user onboarding 上做了很大膽的 things that don’t scale的決定：我們放棄了可以讓使用者自己摸索的 self-onboarding 管道，開始 whitelist only，使用人工教學幫助用戶 onboard 的模式。這個意味著每一個來試用產品的人，都得花上團隊至少30分鐘的時間教學，一個一個功能告訴他該怎麼用。這看似拖慢速度的方式，卻讓團隊多了非常多珍貴的跟使用者面談的經驗。你可以看到他們對什麼有興趣而願意花時間跟你 onboard，看到你介紹到什麼功能時他們眼睛一亮，看到你說出「抱歉這個我們還不支援」的時候他明顯的失望。這些都是實實在在的使用者反饋，灌溉給我們讓我們能改進出更好的產品的養分。我當然不是說這件事情該一直這樣持續，但是在產品早期，這樣的方式給了我們很棒的收穫。
3. Optimize for marginal user
在早期新創的團隊，獲取夠多新用戶就是團隊的唯一任務，所以在產品的設計上，新用戶跟在猶疑邊緣的用戶就是你最該服務的客群。反觀在 Facebook，世界上已經有2B的人在使用這個產品，絕大多數的功能都是設計給這些已經在這個產品上的人，也許有黏著度高低之分，但他們都是已獲取客戶，全部都是在產品設計時需要顧及的對象，你一個也不能犧牲。所以你要顧及語言適用性、平台適用性、甚至是身心障礙者的適用性，一旦做不好很可能直接一狀被告上法院。新創的很大的優勢就是你沒有這些包袱。已獲取用戶很大部分是 early adopter，他們看上你就是看上你，的確可能會因為你推出更多他們愛用的功能而更愛你，但不會因為你少推出一個新功能就馬上離開。但是你還沒抓到的客戶卻是有最大的話語權的，成功獲取這些人的芳心才能夠幫助你增長足夠多的客戶數量。所以我認為不管是新功能選擇，設計上的 focus，都該要以 marginal user 這一群人來當成主要服務的對象，你才能更專注於最重要的事上。
以上是我目前為止打怪的實戰經驗，這場仗才剛剛開始打，我也還有更多更恐怖的怪獸還沒遇到，我會在這場戰役裡繼續越挫越勇磨練武功，期待我包袱裡的錦囊妙計能有重新派上用場的一天！
