當自己產品的用戶

pablo (14)

[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),因為無法判斷到底樣本能否代表整體表現,盲目跟從頗為危險。

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

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

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

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

好的產品幫的不只是用戶

pablo (21)

前幾個月在舊金山不斷收到Uber和Airbnb的電郵,他們想讓我作為一個用家幫忙填一些請願書,好讓他們能和政府討論「白牌車」、「白牌旅館」在法律上的限制。回到香港後發現法律爭拗亦已蔓延至此,只是還沒有收到任何請願書(而且對香港政府請願應該也沒甚麼用處)。

很多公司都是因為資訊在不同的人群、行業之間難以流通才得以存在,資訊越不流通,需要輔助完成工作的工種越多,但工具的發展就是不斷地把不同的工種淘汰(同時也製造新工種),歷史上可以觀察到的通訊新發明如電話、傳真機已不知不覺地製造了也淘汰了不同行業(例如電報員)。

互聯網與手機只是其中一種加快資訊流通的工具,所有行業都受到通訊普及的巨大影響,科技業已不只是科技業,而是滲入了所有行業,他們的共通點是利用科技把現有的行業規則、流程改善,讓用戶可以更方便快捷地獲得所需要的服務。

把用戶獲得的方便撇開不談,其實原行業中人也能享受新方式的好處。在舊金山遇過一個Uber司機,大概50多歲,他說他以前是計程車司機,每天都要工作--要不就會虧掉那天的車租。但換成當Uber司機後,時間都能自己控制,太累想早點下班就停,需要幫忙帶一下孫子的時候就停開一天,至少沒了每天都要交車租的煩惱。

在台北用Airbnb住進了一所非常在地的民房,房東是表姐弟,一個在外國留學完剛回台北,一個正在台北唸書(也準備出國留學),剛好家裏多了兩個房間,索性當起全職房東。因為位處台北市中心,很快整個八月都被訂滿了--他們根本不用花時間宣傳。

無論現在合法與否,這種造成N贏的產品在將來應該是必然會繼續存在的--只有不願意改善/改變的人才會被輕易被淘汰。

從Get hands dirty到Scale

pablo (83)

媒體很喜歡報導Startup成功的故事,而且只報導他們輕鬆和成功的一面,因為這樣才夠Juicy夠醬爆。

可創辦人在不同的場合說當年的辛酸史其實更有價值,只是大部份媒體都不會報導。幾乎每個人背後都有著那麼幾個鮮為人知的奮鬥史。他們真切地捲起袖子去幹(Get hands dirty),去體驗每一個步驟,瞭解當中的困難和流程,才能想出更好更適合的方法去繼續擴展,把整家公司都變得Scalable。

Homejoy的創辦人

有一家在矽谷發展得很快的家務助理線上平台Homejoy,創辦人是兩姐弟。姐姐Adora為了知道家務助理要做甚麼、客戶需要甚麼,還真的當了一段時間的家務助理,替人家執拾家居,當然也包括洗廁所(雖然他們創辦Homejoy的目的其實是不用做家務)。

經過這段經歷,她不只清楚知道了家務助理的整套流程,而且發現了很多可以改善的地方,當然所學所得都反映在Homejoy的整套流程裏。有多少「創辦人」會為了學習甘願去當家務助理替別人清理家居?

Zenefit的創辦人

另外一家最近發展得非常快的Zenefit也是一樣。在2014一年內他們的年收入從100萬美金增長至2000萬,20倍的年增長就是一個每家Startup都想找到的Hockey Stick。年初去過一個活動,有一段分享是Zenefit創辦人Parker Conrad和他的銷售副總裁Sam Blond講他們在2014的高速增長。作為一個以貌取人的香港人,我一開始就搞混了他們倆的身份。Parker穿得可說是非常「頹廢」,和街上看到的流浪漢相比只是乾淨一點而已,而Sam就人型衣著也型。

Parker說作為一個Engineer出身,他其實不喜歡講話做銷售,只是作為CEO怎樣也需要知道客戶要甚麼,也需要知道自家產品的強項,他也逼自己去真正面對客戶,真正瞭解要做些甚麼,才知道到底怎樣的人可以幫他做得更好。他笑說Sam加入後他鬆了好大一口氣,終於可以不用擔心銷售那邊的情況,而且因為他自己做過,才能更清楚知道Sam到底做得多好。

Zenefit

Parker和Sam

Uber全球擴展得很快,很少聽說創辦人有甚麼特別故事。但知道Uber有一套城市拓展流程簿,就是找到適當的人選後,讓那個人跟著流程簿上要注意的事項去開拓Uber在那個城市的佔有率,減低重覆犯錯,相信那套城市拓展流程也是經過很多次錯誤和修改後才有現在遍地開花的效果。

最近和不少客戶接觸過後,意識到OneSky最優秀的功能也不是特意計劃做出來的,而是幾年來慢慢處理過幾百個客戶投訴後演化而成。幾乎所有的公司都係一磚一瓦拼起來的。Startup教父Paul Graham說過:「Do things that don’t scale」,下一句應該是「Build things (product & process) that scale」。

身體力行去做好那些麻煩瑣琗事,把所學所得變成產品或流程,然後就能真正地Scale up,讓機器或其他人也能很快地做到相同的效果。如果因為辛苦或不願意做而一直避免Get hands dirty,哪有方法瞭解箇中特點?

非常極之無耐性

pablo (33)

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

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

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

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

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

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

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

聖誕追債追上門

pablo (63)

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

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

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

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

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

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

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

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

我們還是見面吧

pablo (43)

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

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

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

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

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

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