上星期初到阿姆斯特丹出差，剛好遇上一個有豐富經驗的科創投資者分享如何做好產品。其中大部份資訊以前都從不同渠道了解過，唯有做產品的需求金字塔剛好回答了我最近的疑惑。

和人類需求層次理論（就是Wifi在第一層，水和空氣在第二層那個金字塔）一樣，做產品也有個類似的金字塔。由下至上分別是：功能性（Functionality）、易用性（Usability）和快樂（Pleasure）。

產品需求金字塔

大部份的產品都有功能性，看過說明書或參加一個星期的培訓的話都能用到那些產品（用得爽不爽不在此列）。

手機普及後易用性不斷抬頭，產品的用戶群越來越廣，所有產品都有功能性，沒人願意去看說明書（你看過說明書嗎？）或上「如何把照片上傳至 Instagram」的教學課，只有更易用才能抓住用戶。我認為這也是為甚麼近幾年 Mac 可以慢慢從 Windows 手上奪取個人用戶市場的關鍵。用了 Mac 大概 8 年，已經沒辦法再在 Windows 裏慢慢設定這個那個了。

最頂點就是 Pleasure，抱歉我是一個悶蛋工作狂所以這也是最弱的一項。

我的經驗大都是做 B2B 的產品，也就是工作上才會用到的產品。在我眼中工作和快樂沒甚麼關係，從小的教育就是學習和工作都要認真，只有做無聊事的時候才會快樂，所以快樂和浪費時間/沒產出幾乎是等號。

就此我也問了那個前輩的意見，因為我覺得 Pleasure 似乎是 Facebook 或 Instagram 等個人產品才需要的特性，做商用產品其實不太重要。

他說：「上班的時候已經夠苦悶了，如果工作時能遇到一些小細節可以笑一下，這才是成功的商用產品。」我有種茅塞頓開的感覺。「你正在做的 Kipwise 不是在 Slack 上的產品嗎？Slack 雖然是工作上的產品，但小細節做得很好很有趣，所以能讓用戶感到快樂從而在這幾年受盡喜愛。」我茅塞又多開了幾下。

當易用性可以打敗只有功能性的產品，能提供「輕鬆快樂」感覺的產品想必在將來也會是主流。再推敲下去就需要有快樂工作的團隊才能成事。除了產品方面，這也啟發了我們團隊可能的運作方向。

Have fun 不是亞洲常見的工作方式，面試的時候建議穿著得很正式， Email 或溝通模式也傾向「專業」且冷淡。但剛到愛沙尼亞的時候公司卻常舉辦不同的派對，和這個科創前輩第一次見面的時候也是在東京的一家卡啦 OK，他所投資的愛沙尼亞公司剛去東京開完董事會，一伙人接著去卡啦 OK 大聲唱歌。雖然人還是穿著正式服裝的 CEO 、COO 和投資者，但就像一群老朋友般嘻嘻哈哈唱怪歌，我那時候還有點不習慣，覺得這群人很不認真。現在回想，工作以外 Have fun 並無不妥。太認真嚴肅的上司和環境難以讓工作變得有趣，而且最近就算是在文化比較保守的中國，科技龍頭騰訊也開始有所改變。

把團隊成員的快樂也作為一個重要的因素來運作，讓每個人從工作中獲得除了薪水和成就感以外的快樂，從而讓那股 Pleasure 從產品中滲出來，而讓用戶能每天笑一下，也能喜歡我們的產品多一點。

想像中的團隊需求金字塔，有待測試 🙂

[English version: Eat your own dog food]

繼OneSky後在9GAG工作了3個月，也確是一段有趣的體驗。在9GAG讓我更為感受到「當自己產品的用戶」的重要性，也是以後做產品更需要牢記在心的法則。

OneSky是一個網上翻譯系統，大部份客戶都是手機應用開發商，但OneSky沒有認真做手機應用或幫應用做全球推廣的機會，所以只能從客戶那邊學習各種需求，因為早期很緊密地和客戶一起工作，所以產品也能盡量滿足客戶的要求，只是這樣做總是缺點甚麼－－因為客戶總是不會把所有問題都提出來。

我在9GAG的主要工作是設立iOS和Android應用的國際化流程。撇除創辦人的身份，我還是選擇了OneSky作為9GAG的翻譯管理系統，因為在芸芸類似服務中，OneSky在翻譯手機應用方面還是做得最好的。這也讓我有個機會從一個客戶的角度重新審視OneSky。

OneSky在手機應用翻譯流程都能做到很穩定和方便，而且翻譯的質量很好。9GAG的德文版上線後沒有收到翻譯錯誤的投訴，這都得感謝德文的翻譯員（9GAG的其中一個用戶），她問了很多有用的問題，除了讓她能提供更好的德文翻譯外，也讓英文版本也一併改善，為以後其他語言鋪下更平坦的路，當然這一切也是因為OneSky的翻譯管理員把她從翻譯員堆中找了出來。

除了應用翻譯，還有其他林林總總的東西需要翻譯成德文，像是iTunes商店裏的應用描述、關鍵字、螢幕截圖等等。

因為有著創辦人的偏見，我以為OneSky也可以很好地處理上述的用法，但結果我錯了。使用OneSky翻譯以上的內容無法讓我覺得非常順暢，比如iTunes的關鍵字翻譯並沒有為100個字符的限制而特別處理，無法處理應用描述在Google Play和iTunes重覆內容的問題，也無法簡易地翻譯螢幕截圖。

我非常慚愧，因為以前處理產品的時候並沒有注意到這些用法，客戶也沒有為此大吼大叫（小聲的話幾乎都會裝聽不見…）可是就因為沒有其他人在這方面做得特別好，我們就只推出了一個「還好」的產品，只因為這是做產品最有效率的做法。可當我變成客戶後，我卻覺得這種流程難以接受，翻譯的質量雖然還是不錯，但流程就是很不流暢，沒有讓人眼前一亮的感覺，而且我自己也要花額外時間才能讓9GAG的翻譯流程變得順暢。

這說法在9GAG也是一樣。我本來不是9GAG的活躍用戶，也許一個星期或一個月才用9GAG一次，幾乎無法發現用戶們遇到的大問題。剛加入的時候挺迷茫，因為完全不了解用戶。後來只好花時間去回答用戶的疑問，多了解一下他們怎樣使用9GAG。可還是無法完全了解用戶的心理。

我只好多花更多時間在9GAG上（聽起來是一個不錯的事），但這確實是一個很重要的步驟去了解9GAG用戶的心理和期待，因為幾乎整天都會用9GAG，所以更能提出適合用戶的建議。

我也常和其中一個9GAG創辦人一起討論產品，他是9GAG的活躍用戶，常有一些改善9GAG的有趣想法，我從他那裏得到了很多啟發－－不是因為他是創辦人，而是因為他是活躍用戶。

說到底，這需要的就是對用戶的同理心和了解。說起來非常容易但執行上來很難，因為要確確實實地花時間去觀察用戶、了解用戶、變成用戶之一。

離開了9GAG，但Startup的旅程也沒停下來。現在還不知道會往哪去，但給自己定下了一個目標，下個產品我要和100個活躍用戶交上朋友，了解他們的用法，了解他們對產品的期望，變成他們的一份子，然後才能更好地解決他們所遇到的問題。

最近正在幫一個有千萬用戶級別的產品處理國際化的流程，每天產生的數據都是人腦無法處理的級別，所以需要從數據中篩選出有用的資訊再加以改進。

我非常相信統計學，所以更相信樣本數量的重要性。數據在足夠大以前只能是一堆雜訊（Noise），因為無法判斷到底樣本能否代表整體表現，盲目跟從頗為危險。

上一個處理的產品活躍客戶數量少，才百多兩百個，加上每個的需求不盡相同，一直覺得數據能幫的不多，所以非常依賴跟用戶聊天。這也是為甚麼很多成功的團隊早期都特別注重和用戶的溝通，比起小數據，讓用戶說話更為有用。

除了準確程度，取得數據上的時間也是一個很重要的因素，在產品尚未成熟前除了某些大方向外（比如用戶數或收入），很難訂立更仔細的數據－－常常有個情況就是訂立了數據，花了時間獲取，然後那個數據已經沒甚麼用了－－因為早期的產品變化太快。

到後期產品和數據都成長到人無法處理的時候，解析大數據才有了意義－－無論是準確度或穩定性都應該比早期產品更為適合。

大數據的話題常讓不同團隊一頭撞進了用數據說話的迷思，可在數據長大前，聽人說話、讓人去判斷才是最有效率的方法－－要不創辦人比起加入才三個月的新成員能有甚麼特別？

最近和比較傳統一點的團體打交道，有時候Email等一整個星期收到回覆，那星期裏還特意在Gmail搜尋是否自己錯過了回覆。

在Startup工作的其中一個變化是變得很缺乏耐性，很想潛在客戶快點付錢；很想舊客戶快點回覆問題；很想新功能快點上線；很想前面的大叔走快一點；很想老媽少嘮叨幾句⋯⋯

和不同的團隊成員做過訪談，才發現不少人加入才一年左右。過去一年像在打仗，一大堆新成員，一大堆新功能，一大堆新客戶，一大堆新問題。覺得每個人都做了好多事情，原來還不夠以前考一次A-Level的時間長。

衝刺了一段時間取得足夠市場資訊後，以前偷偷摸摸留下的「好問題」也逐漸浮現。「好問題」是指一早知會出事、但出事即代表做得還不錯的事，當時多數「頂住先」，是極為短視但快速的舉動。比如當初寫系統早知道如果有客戶上載大檔案會出事，但那時候連上載小檔案的人也還沒有；當初早知道如果有中國的客戶連去美國的伺服器會很慢，但那時候連美國也沒客戶。

為了解決「好問題」，做產品的團隊接下來好一段時間都要Refactor整個系統，從Database到Server Clustering，從Code Architecture到UI Flow，一步步把整套系統換掉－－而且為了別驚動現有客戶，常要在假期或週末偷偷摸摸地換。

由於身兼做產品與賣產品，很清楚賣產品的不會關心Refactoring的難度，而且因為更了解市場步伐也會更快，所以對翻新工程的耐性也更少，常常在github上嘮叨做產品的成員－－就跟老媽一樣：「我都係關心你（啲progress）啫。」

這幾個月很多很多事要做，既然已經爬到這裏，也沒有耐性再爬，很等不及與大家一起跑過此關後看那全新的風景。

這是個挺特別的聖誕假期，因為很多時間都用作Refactoring。

還記得對不寫程式的同事為Refactoring作過如此解釋：

整套系統其實就像一張桌子，當只有一兩個人用的時候，無論多亂都能找到想要的東西。當你媽罵你為甚麼不收拾桌子的時候能理直氣壯地說：「為甚麼要收拾？我知道東西放哪裏。」

當用桌子的人數增加、桌子上的東西也慢慢增加的時候，有一天突然發現要花上好久才找到想要的東西－－因為實在太亂了。然後只好死死地氣收拾桌子（Refactor），好讓用桌子的人能快點找到想要的東西－－要不花在「找」（Trace Code）上的時間就比「工作」（Develop）的時間要更長。

公司的產品不知不覺經歷了三個多年頭，每時每刻都在變不在話下，過去一年變得尤其多：人多了，資訊多了，增加新功能的速度快了好幾倍－－程式債也增加得很快，桌子開始亂到不行。一堆大的小的有的沒的問題都源自於那堆程式碼，那為了快速回應客戶而匆匆寫上去的部份。

很不幸地最主要的組件也是亂得最快的，因為它正是最多人修改過的組件，亂到了一個改一句動全身的地步。由於大改動牽連甚廣，就想著趁客戶幾乎都在放假的聖誕至新年假期來個了斷，把潛在影響減至最少。這同時也代表了產品來到了一個穩定的地步，大部份的客戶需求都能幫到，不用急著加新功能，剩下的就是如何把UI和整個系統收拾一下，然後再邁向下一個階段。這是一個挑戰，也是一個里程碑。

有同事戲言，這次Refactoring應該加個標籤叫「煙花」，因為可能在推出的時候爆出一大堆大大小小的bug－－多燦爛。

聖誕快樂，放個煙花，然後新年更進一步。

這幾個星期跑了幾個國家，見了不少客戶，幾乎都是對產品有所不滿或有所要求的，每次都要硬著頭皮熬過那些會。

有個前輩說過：「我從沒讓那些見過面的客戶流失掉。」他認為客戶願意見你是因為他對你的將來有所期待，就算你現在的水準還不夠。

由於客戶大多在美國或歐洲，身處香港要見他們也不容易。曾試過比較簡單的方法－－用電郵詢問過他們有沒有遇到甚麼困難，但很少會很詳細地回答－－寫電郵太麻煩了，尤其是滿肚子怨氣的時候，誰還有心情通過長長的文章來細訴？

通電話或Skype成了折衷的辦法。的確比起電郵的效果好上不少，至少客戶都會盡量描述一下遇到的困難，可是這種關係還是微薄得很，而且不可能叫客戶每次都把所有負責過的團隊成員叫過來開會－－所獲得的信息還是會有所遺漏，而且時差也是一個很麻煩的問題。

直接跑上去客戶的辦公室有最好的效果。對面談話的時候，比較容易從他們的表情或肢體動作了解到所說的那個問題到底有多重要－－有些甚至麻煩到令他們的臉皺成一團；看著他們直接使用產品的過程能發現一些他們嘴上沒說但手上會碰到的問題；更重要的是他們很容易就把相關的同事也一併拉進會議室聊上幾句－－因為用的人和開會的人幾乎都是不一樣的，只有真正在使用產品的人能完善地表達他們所遇到的困難。

不論多麻煩、多花時間也好，就算不能見面，至少也要和客戶通個電話、開個Skype會議。聽完抱怨和要求，而最重要的是要把他們的要求切切實實地做下去，把那個承諾的將來實現出來。

剛讀到一篇Garry Tan（其中一個Y Combinator合伙人）的訪問，他說YC不鼓勵成員去太多社交活動，因為一家新公司要關心的應該是把產品做出來、還有賣出去。難怪遇到的YC Founders都很冷漠，Email來往也只一句起兩句止，可是當碰上和產品有關的事他們的引擎就能馬上熱起來。所以我還是很喜歡他們，喜歡他們那種把時間都花在刀口上的執著。

的確，見太多人會造成Signal Overflow－－太多Signal就變成了Noise。前段時間每個星期去五、六個活動和會議，幾乎見的每個人都有不一樣的困難，不一樣的要求，更麻煩的是每個人都好像願意付錢。但在資源有限的情況下，一下子做很多事情的結果大都是一事無成。幾個星期前不小心掉進不專注的陷阱－－差點做遠了，還好有更強的Signal將我拉出來。

除了活動，互聯網上也有很多團隊分享各種經驗，有些團隊很執著產品，從不談市場營銷；有些團隊則很執著營銷，從來不談產品，這些極端的公司相對地更喜歡分享，所以相關的文章也特別多。很害怕一不小心就掉進他們的框架裏－－那個也許只有他們的產品、市場才適合的框架。

不久前才和朋友抱怨過：「在Startup工作常有很茫然的感覺，找不到框架，連兩星期後要幹甚麼都不知道。」他說：「這不正是Startup的魅力嗎？」

他簡單一句話讓我記起初衷－－不要跟隨別人腳步，把其他人的經驗消化後，走出最適合自己的步伐。

做完一段時間的Startup，只有一句話還沒被推翻：「Make something people want.」

無論見多少人、讀多少文章，最後還是要把適合市場的產品做出來才是功德圓滿。

讀過幾本Kevin Kelly的書後很是著迷，他總站在宏觀甚至有點冷血的角度看世界，但從那卻總能看到很精彩的畫面。

Kevin Kelly是很純粹的技術支持者，他說新技術只是提供了人們選擇的可能性，任何技術都是中性的，只有用法才會分好與壞，沒有絕對的負面。他相信人性本善，一個技術長期下來會向好的那邊靠近，世界也因而進步。他舉了一個很簡單的例子，如果原始人因為石錘可能會造成人命傷亡而全面禁用，那今天我們也還和猩猩沒有兩樣。另一個更貼身的例子就是現代汽車所帶來的方便和車禍引致的傷亡，但能減少傷亡同時不損方便的Google無人車也已經不遠了。

有了新技術，才會有新的選擇－－讓世界走向更好的那個方向。

開發了幾年產品，深深感到這概念的重要性。增加新功能會為整個系統帶來不穩定，修改已有功能也有造成新問題的可能性。所以產品開發的主要問題很容易流於「要不要做這個功能？」；「要不要改這個地方？」沒人願意面對系統的bug和投訴，很容易會讓本能牽著走，邁向故步自封的陷阱－－沒改變就沒bug，多自然。然而產品就只能一直停留在老樣子，一直在向前走的競爭者總有一天會把差距拉開。

商業模式也一樣，最近有幾家公司都以新模式在各地引起很大爭議。Airbnb出租的房子在舊金山以至世界上大部份城市裏仍然是「違法」的，倫敦的計程車司機也剛抗議完Uber的「違規」。

可作為一個用戶，比起住酒店的無聊和刻板，和Airbnb房主交流讓我更能多了解當地文化。在倫敦遇過一個混身大麻味道的計程車司機，看到目的地的地址後說不知道在哪裏，不讓我們上車。然而遇到的Uber司機卻都很有禮貌，Lyft的司機更是十分健談。我徹底地感受到新選擇帶來的額外價值。

有魄力的創新者不會因為一些老頑固而停下腳步，世界終究會被他們推向更好的方向。