2 days ago

一直以來,對日本商家的「印象」都是服務「設計」得很好,以及招牌「設計」的很棒。但是如何好法,總是沒有個頭緒。

日本服務業的心法

疑惑 1 : 日本的「服務好」只是「一種選擇性的 style」?

講到想深入研究,旁人總會丟一句「不用研究啦,那是日本人的龜毛性格,台灣人做不來」。

自從我體悟到「Growth Hack」的原則就是「把服務做好」後,就對於日本的實體與線上服務就開始產生好奇心。這次來日本旅遊也特別留心注意周遭的服務設計,想試試看到底可以取經多少。

自從我發現「設計 Landing Page」是一種必要的選項,不是「一種選擇性的 Style」後。我也不再相信「日本服務好」只是「一種選擇性的 Style」。所以想藉此機會重新研究日本的服務業。

疑惑 2 : 為何日本的商店招牌,走在路上總可以讓人不小心掉到坑被騙進去?

之前來日本的幾次感想,都是日本的招牌設計太強了。雖然花俏,但是總可以讓人不小心掉進坑裡走進去。走在整條都是餐廳 / 居酒屋的街道,總是可以讓人決策樹崩潰。

這次重遊日本我也想研究到底原因是什麼。

1. Landing Page 之上的 Landing Page

我在上課時,總喜歡將 Landing Page 類比為「店餐廳外觀內裝潢」。

這次來日本才發現,日本為什麼拐客人這麼強,是因為他們在「Landing Page」上還再蓋了一層「Landing Page」

這是我從九州、東京、東北,拍到的店家外招牌:

撞球間

11909847_10153613287268552_555724854_n.jpg

小說店

2015-08-14 19.39.06.jpg

雞肉燒烤店

2015-08-23 22.38.18.jpg

居酒屋

2015-08-25 20.35.17.jpg

2015-08-25 20.35.26.jpg

可以看到他們都用了 Landing Page 結構做了包裝:

  • 一句話形容自己(對本店的形容)
  • 提供什麼服務 (直接秀食物)
  • How it works(直接拍餐廳內裝潢)
  • CALL TO ACTION (營業時間)(甚至有寫 Happy Hour 時間)
  • 消除疑慮 (招牌都會寫店內最大容納多少人,讓人不會有「店會不會滿了的疑慮」)

2. 高級旅店的 Check-in Onboarding

這次我來日本,有兩天是住了超過五萬日幣的高級溫泉旅館。一間是在箱根的「箱根吟遊」,一間是在函館的「湯之川 渚亭」。這兩家都有類似的 check-in 流程。

因為我是一個禮拜內連續碰到,發現這已經是一種 check-in 的 best practices。而且跟 growth hack 的 onboarding 概念是一樣的。

超高級旅店如何做 onboarding

1. hand-free

這兩間的飯店的 checkin 流程是,首先是到了飯店以後,行李就可以放手了,有人會幫你提。然後來人會先幫你提到 check-in 處。

2. welcome-drink first

check-in 處是小小休息桌,然後第一件事不是叫你拿 id,而是問你要喝什麼歡迎酒 / 飲料。坐下來看風景聊天。會有好幾桌。這樣就算很多人同時 check-in,旅客也不會不爽。

3. personalize check-in

然後快喝完時會有專人帶著筆電來服務你,這時候才會請你給 passport。都辦完了之後,

4. personalize guide

會有另一個專人帶你去房間,一樣這段是 hand-free,還是會有人有幫你提行李。進房間之後,專人會幫開始介紹房間各項設施怎麼用。進房前,則是會介紹路過的公共設施要怎樣用。然後跟你 book 吃飯時間與鋪床時間,才離去。

Summary

我實在很慶幸當初去學了 Growth Hack 這門學問。原本在沒有接觸這門學問以後,我認為許多服務的「好」,只是「一種選項」。後來瞭解了原理之後,現在參觀任何「傳說中」的好服務都會放心思在看主辦方的細節,到底是真心設計還是只是搬弄照抄。又有什麼好技巧可以師法學習。

特別是又來了「好服務」的大國「日本」。走在街上,真是特別多靈感。

 
3 days ago

之前有朋友希望我多寫一些 GH 實際案例,不過我手上有些 showcase 有綁 NDA 無法公開展示。想想,不如來寫「解構」系列,透過解構業界知名 GrowthHack 團隊怎麼樣設計系統,讓大家一窺後面的手法。

最近在旅行,住了不少 Airbnb 上的房子。剛好 Airbnb 的 GrowthHack 團隊是出了名的強,最近在被 Airbnb 催寫房客評價單,覺得這套系統真是設計的超漂亮,決定這次來解析他們的設計手法。

郵件不斷地提醒

首先,透過郵件不斷的提醒,在十四天內要寫評價。而且是雙向提醒,也就是如果你不寫評價,若房東有寫你的評價,你也會看不到。

螢幕快照 2015-08-26 下午9.22.52.png

強調是貢獻社區,而不是單向的被要求給 Airbnb 改善建議

提醒消費者,Airbnb 的社區改善(Traveler 與 Host 的 plan ) 是建立在大家的誠實 Review 回饋上改進。讓你覺得不貢獻有罪惡感。

14f57410934a5bb1.jpg

將問卷分段

問卷採分段式填寫,非冗長式的一次填到底,讓住客有興趣繼續填下去。這種透過 Gamification 的手段,通常比較常見在商店購物車結帳中。即使是複雜的填寫,也會讓人有動力填寫下去。

screencapture-www-airbnb-com-tw-reviews-43433671-edit-1440300950022.png

將體驗與 Feedback 切開

設計三欄,讓消費者明白「體驗」與「小差錯」以及「相對建議」應該分開寫。

這一點要是 App Store 或 Google Play,可以改採用這樣方式的設計,可以降低很多莫名其妙的1星,而且開發者能夠得到真實建議。而非憤怒的一星意見「老是 crash」。

screencapture-www-airbnb-com-tw-reviews-43433671-edit-1440300802022.png

細節評價

  • 協助房東在各方面改善的更好
  • 如果不好,以消費者的觀點應該「怎樣補強」
  • 是否推薦朋友來這個房源 ( Y / NO )

screencapture-www-airbnb-com-tw-reviews-43433671-edit-1440301190816.png

是否提名房東參加 Airbnb 大獎

  • 是否提名 Airbnb 參加最佳房東(未必是一件真實的比賽),但能驗證你推薦此房東是否真心。
  • 前面跟房東談了他應該知道的事情,接下來跟 Airbnb 談談這個房子 / 房東的狀況。

screencapture-www-airbnb-com-tw-reviews-43433671-edit-1440301252134.png

插入 NPS 問卷

我上個月在這篇,Referral 重要的指標:NPS 文章中談了 Net Promoter Score。

相較於很多團隊總在突兀的時刻,送出 NPS 調查。Airbnb 很準確地在消費完畢後的問卷插入 NPS 問卷。

screencapture-www-airbnb-com-tw-reviews-43433671-edit-1440301334025.png

提醒 Review 是雙向的

  • Review 是雙向的
  • 如果你不寫 Reivew, 房東寫的 Review 你也看不到

screencapture-www-airbnb-com-tw-reviews-43433671-edit-1440301355728.png

跳回 Dashboard 之後再請使用者做一次 Referral

之前的一篇文章中 Build proper Referral Program,我提到 Referral Everywhere 的重要性。

Airbnb 又做了一次精確的 Referral everywhere, 塞到了精準的 Referral 時機。

screencapture-www-airbnb-com-tw-dashboard-1440301387300.png

跟傳統的旅館 Review system 差異

我在體驗 Airbnb 房間後,過幾天跑去住了「箱根吟遊」,算是非常高級的旅館。這是他們合作的線上訂房網的 Reivew Request。

screencapture-japantraveleronline-com-Questionnaire-aspx-1440303396067.png

Summary

Growth 是 Conversion Rate - Churn Rate。

降低 Churn 的手法,在於能真實的聽到顧客心聲,改進。且在聽取使用者心聲時,小心地不觸怒顧客,且得到非敷衍的改進意見。從而改進服務,增加 Conversion Rate。

在這份問卷上,可以看到 Airbnb 在設計問卷時,深深的經典巧思。所以拿來頗析,分享給大家。

 
25 days ago

net-promoter-score-image.png

我在兩個月前寫了一篇文章Growth Hack : Build proper Referral Program,簡單講解了設計 Referral Program 的一些簡單要素(小懶人包)。

今天要來探討,什麼樣的狀況才適合啟動 Referral Program。

照慣例先講結論:產品必須要在 PMF 情況下,設計 Referral Program。 Referral Program 不會幫忙達成 PMF。

為什麼有些服務會使用 Referral 取代下廣告?

Referral 是常見的行銷手法。商家會用 Referral 式行銷的原因很直覺:

  1. 行銷成本遠較一般廣告成本低。
  2. 朋友推薦朋友速度快,在信任程度高的情況下,轉換率通常非常高。

不過常見的謬誤是,有些行銷者會得出這樣的結論:「任何商品」 X 「Referral」=「病毒式增長」。

Referral 使用的條件與時機

事實上用 Referral 的條件有幾個,否則實際上 Referral 非常難啟動。甚至還可能不但啟動不了,反倒引火自焚。Referral 的條件與時機如下:

  1. 產品一定要已經 Product Market Fit 。
  2. 產品給的 Referral 的 discount 至少要高過產品本身訂價或服務量的 10% 價格或至少提供 10% 服務量。
  3. 產品要 Net Promoter Score 夠高,才有辦法啟動,甚至「才不會造成反效果」。

1. 產品一定要已經 Product Market Fit

為什麼要 Product Market Fit?Product Market Fit 後,通常代表你提供的服務已有「穩定的服務品質」,穩定的利潤。

1) 要做 Referral 之前,產品品質一定要維持一定,否則口碑行銷容易出事。(消費者總不希望推薦朋友去使用一個服務,然後那個服務砸鍋,從此搞砸信用吧)

2) Referral 也是廣告的一種,你還沒抓熟成本。不知道 Referral 會不會造成澇賽,一 Referral 下去甚至有可能入不敷出,甚至倒閉。

2. Discount 設計一定要過 10%

那些用 Referral 很兇的 Dropbox, Airbnb, Uber, 無疑的是獨角獸。但你也必須注意看他們提供的 Referral 內容是什麼?

Yes.

1) over 10 % 的 discount。
2) 有品質的服務
3) Referral 成本對服務提供者來說減損到純利的狀況是很少的。

為什麼要 over 10% 的 discount?這樣消費者才會真正覺得,推廣是對我有好處也對朋友好處的。

我從Gogoro、Tesla 與直銷的競爭優勢 一文,觀察到某 G 牌機車在做 Referral。事實上我不太知道他們想幹嘛。G 牌機車,一台 12 萬 8 ,送一個月電池服務(大概折台幣 1000 吧)????老實說我不知道這到底會吸引誰去買誒。(這到底哪個天才設計的?)幫你推廣的消費者搞不好甚至覺得都不敢跟朋友推薦吧。講這樣的方案內容可能還被笑死 =_=

老實說, G 牌真要做 Referral 的話送一萬折價卷大概才會有消費者鳥你吧,我說真的。

但這又要回到,G 牌是否有 PMF, 1 萬才有動力,但是利潤根本沒有 1 萬啊。

另外一件事值得一提的是 Tesla 雖然推薦一個人是 1000 美金。(動力雖然對車主沒有很高)。但推薦到 5 台以上是贈送「稀缺資源」,這才是強烈動機。(這是另外一種 Referral 密技,我有空再講)(拜託 G 牌不要再送保留號碼,大家都知道你們車子沒賣完...)

3. Net Promoter Score

這是做 Referral 前最重要的指標了 超重要超重要超重要 要講三遍

Net Promoter Score 就是「願意幫你 Promote 的顧客分數」。Referral 能夠 Run 的前提是 NPS 要高,就我的經驗,分數要高到 5 以上。

nps-a-simple-calculation.jpg

如果你有興趣瞭解更多 Net Promoter 原理的話,細節可以看這篇:http://blog.clientheartbeat.com/net-promoter-score/

NPS 的運作方式,是送一個 1-10 分的問卷,只問一個問題,「你會不會推廣這個服務給朋友,為什麼?」

如果你的 NPS 不高,千萬別推 Referral ,因為

1) 輕則推不動。(我覺得這服務還可以啦,但是價格太高,不一定每人都需要)
(只要有「可是...」,服務提供者就要盡力去修)

2) 重則反效果。「笑死人,那麼貴那麼爛的服務還要做推廣,這種折扣貼出去超丟臉」。你寄希望幫忙做 Referral 的信給使用者,憤怒的使用者甚至會覺得他們被你騷擾了,開始幫你反行銷。

矽谷現在甚至有專做 NPS 的服務叫 Delighted https://delighted.com/

所以通常做 Referral 之前都會先 run NPS,而不是盲目的做 Referral。以免賠了夫人又折兵。

提供想設計 Referral 的人一個參考。

結論

產品必須要在 PMF 情況下,設計 Referral Program。 Referral Program 不會幫忙達成 PMF,切記。

 
27 days ago

兩個禮拜前,我寫了一篇 HomeJoy 陣亡的討論。今天我要寫另外一個面向的探討。就是 HomeJoy 究竟怎麼死的。

在這個切入點之前,我必須要先談 YC 與其他加速器最大的不同:他們的加速器不教別的,教創業者「Growth」。

創業者只需要學會「Growth」

市面上有很多加速器,坦白來說你也不知道他們在加速什麼的,有些你加入了反而「減速」。

好,不多扯這個主題了。每個加速器不太一樣,有的教你怎樣造 Traction,有的教你簡報技巧,有的教你募資技巧,有的帶你大量曝光。

但真真切切的,報名加速器的創業者真的需要什麼,就是學會「怎麼做生意」,然後「成長」。

(所以不是教你做生意的加速器,就省點時間別去了....)

創業「無法」也「不能」 Game the system

PG 本人說過 ": starting a startup is where gaming the system stops working."。他認為創業是唯一個無法靠作弊成功的領域。

何謂 Gaming the system?就是像你上大學,大部份人考試考高分,並不是真的了解這門知識,而是知道「教授會考什麼」。你知道教授想出什麼會出什麼,所以你考高分。

但創業不是這樣,他無法靠「game the system」達到你想要的終點,你如果始終想要 "gaming the system",這個心態會殺死你,只是死的時機點而已。

而 HomeJoy 就是這當中的一個例子。

HomeJoy 倒閉的真正原因:「Growth X Game the system」

雖然創業不能 Game the system,但 YC 還是找到了一顆「北極星」,那就是 Growth。並把這整個概念覆蓋到他們旗下的 startup 下。

公司圍繞著「成長」這個概念,可以讓創業聚焦。因為你要想辦法達到成長,所以你就不會浪費力氣在 big bang 式的媒體曝光,或者是砸大錢在廣告上。創業者會開始注重在產品的 AARRR。

好。那 HomeJoy 出了什麼問題呢?

OK。你要想想 HomeJoy 什麼時候從 YC 畢業的呢?2012 年七月。距離現在多久?三年。

三年拿到 10 億台幣資金,然後擴張到 31 個城市的 B 輪公司。你覺得這門生意是擴展的太成功還是太奇怪?創辦人才 20 幾歲。

這看起來反而像是類固醇打過頭的公司。

實體辦公室的迅速擴張

1) 首先軟體公司暴發式成長的公司不是沒有。但多是「純軟體」居多。就連當年爆發性成長的 Facebook,都沒有「實體 Operation辦公室」的快速擴張。但是 HomeJoy 擴張了 31 個點。

小孩玩大車,人數的迅速擴張

2) B 輪公司大多在 150 - 300 人規模。兩個年輕人要怎樣從只管 5 個人迅速「心智」上成長到可以管 150 人?
管 5 人,10人,20人,50人,100 人,500 人,都是不同等級的難度,需要時間與歷練。

而且還是 Operation-oriented base 的公司。

如果你上 HomeJoy 的 Glassdoor 一定可以看到類似的抱怨(對幼稚管理層的瘋狂抱怨)。而且還會是滿滿一大堆。

瘋狂盲目地燃燒資金,用「成長」去吸引下一輪投資者

3) 2012 開始剛好是 Uber like 的大爆發年,所以該年開始,只要你的題目是 Uber for Anything,都很好拿錢。消費者也很容易買單。

因為消費長也想要買單 Uber for everything。所以相關 O2O 題目瘋狂的爆發。錢變得很好拿。成長曲線也會很漂亮。(因為市場上從未有這一類的商品)

但是這就又燒出一個隱憂。拿到錢的人真的懂這個 Business Model 的成本結構嗎?

(當然台灣環境比較悲哀啦。所以根本沒有「拿到錢」的煩惱 XDDDDDD所以做 O2O 的通常是 run 幾個月就血流倒地了。)

矽谷都是燒錢式的把 business model 燒出來。不過這在 O2O 這一個領域開始踢到了大鐵板。Operation 真的非常非常非常非常地燒錢。

而且非常非常燒管理人才。我認為矽谷這樣 O2O 繼續玩下去,operation 的人才搞不好現在大概跟 Software Developer 一樣搶手吧。

清玉迅速展店都還是加盟主捧錢給總店,加盟金還是天價的高,都會迅速崩潰了。更何況是自己拿錢到處砸開「加盟店」。我想用這個例子你更能明白 HomeJoy 發生了什麼事。

一旦 retention rate 很低,幾乎就是賣 1 單賠 5 單吧。

不過 HomeJoy 需要錢,也有投資人的壓力。怎麼辦呢?反正他們有 Growth 曲線,就是繼續去募,他們也募到了 B 。
在這過程中,他們有思考自己的 model 問題在哪呢?我想應該也是沒有。

不然擴張 31 個城市還擴到其他國家(美國英國加拿大法國)這件事,看起來很屌,實質上在運營管理上根本像神經病一樣。矽谷很多觀念是很先進很成熟,但這是超越物理極限的事(需要大量管理人力以及運營經驗堆積),是不可能做到的。

HomeJoy 就如同他的僱員和同業批評的一樣:「盲目擴張,盲目追求增長」

一旦募不到下一輪,就趴了。

結論

O2O 雖然挑戰門檻極大。但並非不能做的生意。

Homejoy 的 CASE 正像海水退潮就知道誰沒穿褲子。接下來 O2O 界相信應該會有一系列海水退潮。

我自己覺得可以從 HomeJoy 這個例子裡面吸收的是:

  1. 要創業,慎選資金,沒辦法幫自己成長的資金與加速器少拿。
  2. Focus 在 Growth,可以省走歪路。
  3. 人員擴張,運營擴張,是成長結果不是成長手段。
  4. Never game the system

共勉之。

 
about 1 month ago

我今年下半年重開了去年評價很好的 Rails 商務網站 x 即戰力班。開這個班的目的,是為了讓市場上多一點即戰力能戰鬥的 Rails Developer。

目前今年暑期班已經上完第二堂。但因為口碑蠻不錯的。

skitch (9).png

原本打算晚點要公告出來的秋季班,也神秘的瞬間秒殺了。所以目前只剩下

課程內容以及設計理念

雖然網頁上我已經有公布上課大綱是什麼。不過有朋友還是希望我解釋一下這是在上什麼。所以我就大致上寫一下:

第一週

第一週我會教新手,「軟體規劃」,以及「規劃完怎麼樣慢慢實作完內容」

這是過去我訓練過幾十個 Rails Developer 發現大家的共同罩門。很多人學完坊間的 Rails 基本教材,會操作基本的 API 了。但是對於「要重新寫一個自己屬於自己的 App」有困難。

其實不要說自學了,就連許多公司裡面新雇用的 Rails Developer,很多人頭三個月都還只能實做「單項」簡單的功能,沒辦法說「規劃一個整塊功能」,在限時內寫完。

這就是我第一週想要傳授的能力。這個能力會在後面的課程中一直反覆的用到。

第一週其餘的內容,都會圍繞著

  • 「軟體規劃」
  • 「如何圍繞著軟體規劃,慢慢把軟體疊出來」
  • 「利用 gem 實作功能」。
  • 「如何問出不會被鄙視的問題」

同時鼓勵大家下課後去參加社群,寫作業,問問題。

第二週

第二週,份量會變得非常的重。

主要是「規劃一個整塊功能」並實作。
從 Helper -> View -> Controller -> Model 逐層的深入設計。同時透過這些一個一個功能,把 Rails 常見的功能觀念一個一個帶進去。

這一週的主題是

  • 實作購物車
  • 結帳
  • 生成訂單
  • 切換訂單狀態

同學會學到

  • Helper 常見設計方法
  • Model 常見設計方法
  • Controller 常見設計方法
  • 怎麼樣拆架構,「跳開還沒有頭緒」的架構

第三週

第三週呢,我們實際介紹如何介接「第三方服務」,以及處理第三方服務需要處理的問題。再來,因為前兩週我們把程式寫得很亂了,怎麼樣整理程式碼。

這一週的實戰主題是「寄信」以及「實際付款」以及「部署」。

  • 寄信是教 Mailgun
  • 付款是教 歐付寶
  • 部署是教 Heroku

部署這些第三方服務還會有一些「開發環境」與「正式環境」的差異。我們教如何處理相關的疑難雜症與 debug。

整理程式碼部分我們會教

  • View
  • Controller
  • Model

的相關 Best Practices 收納術,以及整理心法。

第四週

第四週呢,我們教實際從業 production 環境會遇到的各種挑戰。去年我們教了

  • 簡單的 SEO 與 Facebook Opengraph 資訊
  • Frontend 怎麼樣提升效能,
  • Backend 怎樣提升效能,簡單的資料庫設計以及索引原則,怎麼要找效能瓶頸點。
  • 開發時需要注意的簡單安全性問題
  • 求職履歷要怎麼整理

今年這些全部都會教。

另外我還會多教一些簡單的 MVP 與 Growth Hack 實戰。讓你知道一開始哪些產品功能可以先做,哪些不用做。還有簡單的推廣產品技巧。

為什麼這樣設計?

這套課程,內容都是一個 Rails Developer 從業 2-3 年(還未必會全)學到的課題。目前是沒有一本書以及線上教材所可以提供的。全是從我 Rails 從業八年來帶過非常多 Rails Developer 的 Training Cycle 所萃取出來的。

所以如果要說這個班跟其他人有什麼不同。

1) 首先,雖然我們上課只有四周,每次只有 3 小時。但是這 3 小時不是講一些 「網路上就找得到的基礎教材」灌大量時數。我們是教書本上沒有的東西,鐵錚錚的實戰累積經驗。

2) 我們上課是高度互動。學生一定要留時間寫作業(下課要至少寫3-6小時的作業,有解答),下課還來 meetup 問助教問題。每一上上課就能帶很多高度半成品的東西回家。

如果你有點子想自己實作,按照類似的架構就可以搭出有模有樣的東西。

而不是只教你單一個功能,你根本不知道為什麼會這樣設計。(如果要學這種東西,Railscast 很多)

3) 我們教的整理術是 rails 圈內已經演化到有最佳解的東西。所以學生不用浪費時間重新再進行這個 cycle 一遍,還不一定有方向。

這個班從設計的宗旨開始就是要教出:錄取後馬上可以打仗的人。不管是你想要換工作,或者是做自己產品,都可以自己有方向快速上手。

我們不會唬爛你說出來可以變即戰力,事實上每週都在教你網路上的 101。

講了這麼多,其實這篇文章也不是在重新推銷自己的課程,純粹只是分享一些課程設計的理念。因為秋季班已經完全爆滿了(一天內瞬間秒殺...,所以我秋季也沒東西可以賣了)。

如果你看完覺得有興趣的話,現在只剩下冬季班可以 book。我勸各位及早 prebook。這兩班沒有 book 到。今年就真的沒有位子了。

http://rocodev.kktix.cc/events/rails-e-commerce-2015-11-tp-prebook (台北)
http://rocodev.kktix.cc/events/rails-e-commerce-2015-11-ks-prebook(高雄)

現在先 book 起來,九月開放報名時就不用跟人再搶了。(會提早至少一週通知繳剩下的學費)

 
about 1 month ago

昨天剛傳出 HomeJoy shutdown 的消息。雖然行內認為這篇資訊已經夠多,但是我認為還是可以寫出更深一點的評論。

(P.S. 筆者曾在矽谷 O2O A 輪公司任職,擔任 Engineering Lead 且設計主導重寫擴展過整套 O2O 複雜的商業系統架構)。

這篇文章太長,所以我先寫結論。

  1. 如果你只能賭一家 O2O 公司,賭 Uber。如果你能賭第二家,賭 Airbnb。
  2. 初次創業者,不要來碰 O2O。必死。這行不是寫個 "Google Map" + "Billing" 就可以開始賺錢的行業。
  3. 在台灣搞 O2O,嗯...。(我不想直接寫會引發地圖砲的字句)
Read on →
 
about 1 month ago

幾年以來,我在執行專案時,一直是使用「使用者故事」的方式,與團隊一起進行敏捷專案開發。

開發專案時,捨棄寫 Spec,而改由撰寫「使用者故事」。可以讓團隊釐清,整個專案有多少角色,在什麼場景,執行什麼功能。我們再針對爬梳出來的 User Story,進行資源以及執行期限的限制篩選。擬定可以執行的方案。

但是,後來這一套方案在特定的狀況下遇到嚴重瓶頸。我們公司的架構當時是分隔台美兩地。Product Owner 在美國協助整理使用者需求,台灣團隊收到後執行。但是,以往管用的招式在此狀況下卻不管用。

原因是以前如果開發團隊都在同一個辦公室,使用者故事上「沒寫到」的細節或原始情境,透過快速的口頭補述交流,就可以補完。專案不至於執行偏差。但是在團隊分隔兩地的情況下,因為時差與團隊成員功力差異,許多「需求」的「原始情境」會消失。

「使用者故事」變成 Product Owner 的一面之詞,他憑著「自己的判斷」以及「喜好」,寫成了「無原始背景」的技術性用戶故事,加上公司又是 Operation-Oriented,有些細節必須要是在現場才會知道。這些「重要的細節」隨著 Remote 與溝通不良被蒸發,於是「使用者故事」又變成只是「簡單版的 Spec」而已。這讓團隊之間,摩擦又開始變得很大。

於是我掙扎著又設計協調出另外一份問題解決結構,搭配 User Story 執行。方式是這樣的:

  1. 我們遇到了什麼問題?
  2. 為什麼這件事會發生?
  3. 我們目前的限制是什麼
  4. PM 建議的解決方案
  5. (召集相關的開發成員)大家建議的解決方案是什麼
  6. (召集相關的開發成員)簡單的 vote

這份敘事的結構,目的有幾個:

  1. 讓「原始目的」與「原始情境」儘可能的被重現
  2. 讓團隊了解這個問題的資源限制,以作出最好的建議(一天之內要解決?一週之內要解決?或放著想根本沒差)
  3. 讓相關的成員有參與感,以及可以激盪出最好最適切的解決方案。(透過 Hackpad 討論,所以來回不會很冗長,通常一個工作天內會結論與表決同時出爐)。而不再是 PM 的一面之詞。

我們成功用這個架構 deliver 了很多大大小小 tricky 的專案。

本來我們也以為這套方案是獨家發明,後來跟一個朋友聊天分享過後。才發現這其實已經是麥肯錫內的架構解決 Best Practices 了。我在麥肯錫新人培訓七堂課 這本書內有找到更多這套方法的敘述與強化。

以下整理出方法重點:

1. 解決真正的問題

比如說老闆抱怨「最近生意不好」,所以我們要搞個「促銷」。此時重要的不是真的去寫「促銷」的 User Story。而是去找出「生意不好」是指「來客量不高」,還是「單個客人貢獻營業額不高」。

2. 定義問題、假設與分析、解決策略

執行這個步驟的重點在於「分離現象和原因」。利用邏輯樹找出問題結構後

  • 生意不好
    • 來客量不高
      • 每個客戶平均成交率低
      • 沒有花新力在開發新客戶
    • 單個客人貢獻營業額不高
      • 單品平均銷售額沒有增加
      • 顧客平均購買量沒有增加

然後再找出什麼是最重要的議題。(因為沒有美國時間一個一個去做)

3. 根據團隊目前限制針對最重要問題設計出有意義的解決方案

因為產品開發不可能無限制發散討論。一定要有得收斂,且要在「一定時間內」完成,否則超過時間限制,原始的討論也會變得一點意義都沒有,而淪為純清談。

解決問題時必須注意到的重點

  1. 不要受眼前的狀況和條件所限
  2. 經常意識到邏輯思考
  3. 不斷問為什麼?
  4. 為什麼?做什麼?怎麼做?

「為什麼?做什麼?怎麼做?」

在商場上,這三個問題就是把「哪些產品與服務,透過什麼方法,提供給哪種類型的顧客?」只要這三個問題沒弄清楚,就會搞錯方向,浪費資源。

這也是當初我們單純只讓 PO 使用「User Story」單純敘事的缺陷。

PO 少告訴了大家「為什麼?」,而 PO 單方面的決定「做什麼?」「怎麼做?」。

這個方法是一個把產品所有權回歸到整個團隊的好方法。

推薦給大家使用。

 
about 2 months ago

fight.jpeg

在這個話題上,很多團隊對於「Growth Hack」戰術以及 「Project Management」是否能同時並存且執行是存疑的。因為在傳統的分工架構與流程下,Project Management 強調的是職能分權以及排定優先順序。而 Growth Hack 「印象中」執行的場景是有不分組且跨領域的的 Growth Hacker 獨立的進行產品改造工程。

這兩件看似衝突的事如何一起執行?

產品是誰的?

在繼續講述這個公認為最難的主題之前,我想來先聊一個其他主題。我覺得很多 project management skill 與 framework 在很多團隊裡面沒有效果,其實是一個最重要的前提假設錯了。

這個最重要的前提假設是「產品是誰的?」通常,官方政治正確答案是「產品是大家的」。

但是在許多組織運作現有運作情況下,卻是「產品是 PM 的」。

以至於很多敏捷方法、架構、以及操作方法,在這樣的操作現況下,變得超級畸形以及沒有效率。

Read on →
 
about 2 months ago

2012 年我曾經寫過這幾篇文章:

每個人的困境(藉口)都一樣:「我不開心,但是我不想不孝順」

這幾篇文章常常讓我的臉書被密爆。起手式是這樣的:

Anonymous: Hey, Xdite 你好. 是這樣的, 我最近看到你的文章, 感觸良多. 我最近 "進了大公司", "醫學院念完", "考上公務員", "替代役當了一年", "剛考上公務員". 家人都為我很開心, 可是我很不開心. 他們都覺得我找到了很好的工作, 但我覺得上班很無聊, 看到你的文章, 我覺得你說的很棒很貼切. 「可以跟你交流一下嗎?」

Xdite: 你是想離職嗎?

Anonymous: .......有這個打算. 不知道你當初是怎麼跟父母講呢? 當初會做這個工作是因為 "家人逼我", "家人期待", "社會觀感", "岳父喜歡", 薪水也不錯也很穩定. 我不討厭, 但以後想到將來的 "值班", "開不完的會", "老屁股", "專業上沒什麼熱情", 就讓我很苦惱.

Xdite: 不喜歡的工作就不要做啊.

Anonymous: 很困難啦. 你不知道啦. 我每次透露出這個想法, 我爸媽就會覺得 "我是白癡", "你會餓死", "以後賺不到錢", "不穩定", "不會把女兒嫁給我". 我曾經想過 "先撐過三年", "先撐過專科訓練", "先拿到執照", "先升上主管", "先把手上這份工作上手" 在 "有空的時間", "下班的時間", "上班無聊的時間", 研究我喜歡的題目, 之後再換工作, 你覺得呢?

Xdite: 為什麼你有這樣的想法? 這樣不是很浪費時間嗎?

Anonymous: 沒辦法. 我不這樣做. 離開現在的位子, 父母, 女友, 岳父母 就會跟我鬧革命.

Xdite: 為什麼?

Anonymous: 因為他們會覺得 "我會餓死", "以後賺不到錢".

Xdite: 你會嗎?

Anonymous: 我也不知道. 現在的工作我也不討厭. 所以我很猶豫

Xdite: 不討厭 = 不喜歡

Anonymous: ......XD 對...

Xdite: 你喜歡的話怎會說不討厭呢?

Anonymous: 那你覺得應該怎麼做比較好呢?

Xdite: 辭職,去做你想要做的事。

==== 通常到這裏我會視對方鬼牆程度決定要不要再回應,或直接就放著把視窗丟著不理 ===

這一篇文章不是昨天某一個陌生人或熟人跟我的對話。我的 FB 訊息夾 / Email 大概有兩三百個類似的鬼打牆對話 XDDDD

已經 loop 到我可以直接用背的了。(Siri 到底可不可以內建本功能?)

如何快速打破父母這道迴圈?

其實我不是很想寫這個驚世文(每次寫完這種文章,兩年內我都會因為該文被公幹,兩年後才還我清白 XD),實在是我覺得這個解答邏輯已經可以 Programmable 了,而我沒有一直將來想要進行這種機械式對話。

翻譯:「你會餓死」= 「我不希望以後養你」

要打破這個迴圈,首先需要的是「獨立思考」。

說真的,我期待讀到這篇的讀者,既然你已經有逃離了念頭了,不妨再多花一些腦力。

這些看似打不破的迴圈不是打不破,而是你的大腦無法破題,無法破題的原因可能是因為害怕而抗拒進行解題,或者是一直以來都懶得思考(如果是懶得思考,這樣這篇文章可以直接 end,不適合你)。

父母的話「你會餓死」其實相等於 「我不希望以後養你」。

所以第一件事情要思考的是:「你以後做喜歡的事,就算餓到,你會跟父母伸手要錢」嗎?

翻譯:「你以後賺不到錢」= 「我怕你是廢人,達不到應有的成就」

父母的標準很簡單,只是表達形式糟。在台灣父母眼中「錢」= 「成就」。你可以很賭爛這個思維:「錢」= 「成就」,但這就是現實。

我相信有這些困擾的朋友們,都很會「考試」,所以一不小心被考試的高分沖到了一個自己好像不喜歡的地方。但「你會餓死」,「你以後賺不到錢」,好像沒有標準答案,而且是一種情感式的勒索。所以不知道怎樣答題。

其實標準答案,經過翻譯完就是:父母希望你的月薪至少 "XXX 萬",結束。

我家境沒有很好,所以當初我爸的標準大約是月薪 5 萬。認真幹程式設計師一兩年就有這個數目了,所以我很有把握的硬幹下去。超過 5 萬我就自由了。(如果按照他當初設定的路線,我大概要幹 robot 至少十年才有這個月薪)

所以你也可以設定一下,你想要的那個職業,要投入多少努力和多久才有這個同等收入。

  1. 三年內達得到。恭喜你,現在可以立刻就烙跑!(而且我保證,因為你非常有興趣做你想要做的這行,其實只要花一半的時間就辦得到了)
  2. 5-7 年才達得到。可以研究如何賺其他業外收入或加值收入(賺錢),湊在一起達得到。不要藉口說不可能,你不是很喜歡怎麼不可能?

可是做自己想做的事,好像違背父母的話,好像不孝順?我不想不孝順。

Hey, 仔細看看你父母在表達什麼?

「我希望你經濟獨立,並且變成社會上有成就的人」。

只是他們考試及格的標準,在現在已經 expire 了。就像你聽到「我國首都是南京一樣」會覺得非常荒謬一樣。

所以成為「經濟獨立,並且變成社會上有成就的人」,是很孝順的行為,沒有不孝順。

如何快速打破自己這道迴圈?

「可是,我當醫生、在竹科上班、在政府上班,也蠻有面子的,我不討厭,只是也沒有很喜歡,特別是 XXXXXX 情況很爛」。

Hey, 想想看, 為什麼你有面子? 為什麼人家給你面子? 是因為你是名醫? 你是工程師? 你是高官?

人家是給你的機構面子,不是給你面子

No. 人家是因為你後面的機構 = 有錢 / 有權。但是你本人 有錢 / 有權 嗎?你又真的覺得你的職位「有錢 / 有權」嗎?

你只是想要自己「有錢」「有權」,還可以「做自己開心的領域」

為什麼「你自己」不「做自己很開心的事又做得好」然後因為「專業權威」變得「有錢 / 有權」?

而要躲在一個「不開心的地方」「每天假裝開心上班」再「假裝自己有錢有權?」

鬼島標準:「年薪」= 「人生分數」,想逃跑至少要及格

寫完這篇,也許你會覺得我這個人完全變了個樣。以往在部落格老是大談「有熱情」多重要,賺多少不是很重要,對社會有多少貢獻才重要。結果這篇「錢錢錢」。

Hey, 面對現實吧,爸媽的緊箍咒,其實說穿了就是一張考卷,而 95% 的爸媽,及格標準跟錢有關。你對自己的緊箍咒,100% 跟錢有關。

更實際一點,「你現在的月薪五萬,而你想做的工作起薪三萬五,你想做的工作兩年後才會升到五萬。就算到兩年後才會一口氣升好了,兩年也才差 36 萬。36 萬可以賣掉你的快樂?36 萬等於一天 500 元。」

每天多 500 元跟每天上班都很快樂你要選哪個?何況兩年後都是領一樣的錢。更何況你每天上班都很快樂,兩年後你的月薪可能不是五萬,是七萬。

so, 為什麼你不現在就開始研究怎樣讓自己的興趣開始可以賺錢?

反正,最差的狀況,不管你會不會「變得更快樂」,最差的狀況也只是你會變得「更有錢」,而不是「更窮」。我想你的父母也很難因為「你更有錢」去討厭你。

只是記得告訴我,未來當你因為「玩自己的興趣」賺了更多一點錢的時候,你對「有熱情」跟「賺錢」跟「對社會有貢獻」是否會衝突的看法是什麼?:p

快去研究怎麼賺大錢吧!

延伸閱讀

==== 後續追加

網友路直讀後發問:「有個loop困境是就算自己跟另一半都已經超越及格了,但父母還是不滿意,請問如何處理?有些人跟無底洞一樣,永遠不會滿足。」

我的回答「我認識一種人更奧,就是我自己,我還是很不滿意我自己。我比我父母還要奧一百倍,所以我忙著處理我這種奧客,沒空管那些次奧的。」

 
about 2 months ago

38639937_s.jpg

網路公司的工程師或視覺設計師,在公司最怕公司高層宣布一件事:「這個月我們要來大改版」。

如果公司宣布這件事,往往就是預告著公司三個月後的「第二版」上線後,大離職潮的開始。

為什麼要大改版?

需要大改版的原因,往往是以下幾個原因:

  1. 原先網站太醜
  2. 原先網站動線不良,有太多結構性問題
  3. 交易成功率很低,而老闆覺得是「視覺設計」上的問題。

為什麼工程團隊最恨聽到大改版,以及大改版後會有離職潮。通常是因為在改版過程中每個團隊不可避免的照順序會發生這幾件事:

  1. 因為美、醜、動線的主觀性,所有同事大內戰,戰成一團。
  2. 內戰過後,最後只產生一個結論:由 PM 主持公道(a.k.a 都他來規劃,大家不要吵)。但是把最後決定權交給他,通常也等於把 deadline 交給他。於是這個大改版就會出現一個完全不切實際的上線日。
  3. 大家因為這個上線日瘋狂的加班,爆肝撐到終於上線。結果,原先舊的客戶用得非常不順手,信箱內客訴一大堆。但是,原先期待上漲的交易量也跌的更誇張,老闆震怒。但大家實在不想改版第三次。
  4. 因為大改版,所以網站內有些好用的舊功能,或者是 workflow,消失或爛掉了(當初沒辦法寫 Integration Test 或根本沒時間寫 Test,或寫 Test 也阻擋不了因為 UX 的改變造成的動線問題)。工程團隊忙著修理或 Revert 成原來的動線。
  5. 最後工程團隊又累又沒成就感又被眾人指責,憤而離職。

所以大家非常痛恨「改版」。

今天這篇文章就是要從 GrowthHack 的角度與手段分享,如何「無痛」的改版。

第一件事:找出關心的產品指標

為什麼要改版?改版說穿了就是希望產品能夠「更好」。

既然是「想更好」,那麼第一件事就是要精確的定義什麼叫做「好」。

產品的服務交易成交量低,那需要改善的地方到底是什麼?

  1. 你的產品多半是服務一次性客戶,所以想改善的是 Signup Rate 嗎?
  2. 產品 Signup Rate 很好,但是再買第二項產品的機率很低,所以你想改善的是 Retention Rate?
  3. 產品回購率可能還不錯,但是回購間隔非常的長,所以想改善的是購買頻率?
  4. 客戶看到商品往往都加到購物車了,但是購物車 abandon 率高達九成?

如果你想要改版產品,首先必須知道你想要「改善」改什麼。改版絕不不是「請美術新出幾張圖」,就叫改版。

想要改善產品,必須先知道究竟想改進什麼「過低的指標」。

第二件事:建立該指標的行為量測,建立 Funnel

很多做網商的人,很喜歡大談 Conversion Rate Optimization。

每次改版就嚷嚷我們要改善「Conversion Rate」,然後根據網路上搜到的一些懶人包,提出一些天馬行空的改進建議,這些 tips 有時候有效,有時候一點都沒效,還會造成工程團隊的困擾。

「交易成功率」不等於「轉換率」

傳統大家喜歡談的 Conversion Rate 其實講的是「交易成功率」,而不是「轉換率」。

轉換率的定義:在 Funnel 的想法中, A -> B ,B -> C,C -> D,每一個狀態的改變,都算「轉換率」。

比如說註冊量低,我們要改善註冊步驟。

註冊步驟分為

  1. 從 FB 進到首頁
  2. 從首頁進到註冊頁
  3. 註冊頁填完資料進到帳戶 Dashboard

比如說商品成交量低,我們要改善購物流程

購物步驟分為

  1. 從 Line 進到商品頁
  2. 從商品頁挑選商品進購物車
  3. 從購物車頁進到結帳頁
  4. 從結帳頁填寫地址到付款頁
  5. 從付款頁到見到交易訊息

很多人會誤認為轉換率就是「註冊數量」以及「購買商品量」。

事實上 Conversion Rate Optimization 談的是,從 1->2,2->3,3->4,4->5 的每一個步驟的優化。

客戶沒有辦法完成交易的原因很多。有可能是

  • 加入購物車的按鈕設計的很不好
  • 填寫地址的動線很爛,填一填就火大了不想填
  • 結帳頁沒有 HTTPS
  • 結帳頁看起來就像詐騙集團的頁面
  • 看到總金額,突然覺得這個月太花錢了臨時冷靜

如果想要「修」好壞掉的數據,應該確實找出壞掉的部分修好它,比如說 2->3 是好的,3->4 是壞的。

但傳統的「大改版下」,往往是在不明就底的情況下把 2,3,4,5 全改了。

3->4 沒修好不打緊,結果連當初沒壞的 2->3 都壞了,交易量反而下跌是很正常的事。

前端工程師不應該寫 Integration test 而是應該改關心 Funnel 漲跌數據

前端工程師對於改版最頭痛的地方是,Integration test 不好寫,而且改版通常還會牽扯到 CSS 與動線,這個部分幾乎大家不知道測試的尺度要拿捏到哪裡。

Well,我建議前端工程師應該關心的是 Funnel 轉換率的漲跌數據。

因為,「改版」的目的是希望「交易成功率」上升,而不是程式表面上的正確與否。「程式」就算沒有 bug,那也只表示程式設計「正確」,並不代表「程式設計正確的達成或改善目的」。

所以,改版應該關心的是 Funnel 的漲跌數據,Funnel 跌再去處理,比花大把時間寫 Integration test 有意義的多。(通常 Funnel 跌也可以順帶的知道程式爆炸了)

第三件事:一次只改一個部分,並 run A/B testing

前面提及的改版重點:

  1. 不要大改版
  2. 建立量測數據,找到哪個指標嚴重偏低
  3. 掛上量測工具,抓出整個流程步驟間所有的轉換率,抓懷疑病因

所以產品改版必須是小規模的針對性的修,而不是 big bang 式的改版。

接下來這段想談的是實務上「如何實作改版」:

改版通常牽扯到主觀的辯論(除非團隊內有壓倒性的強者),否則最後結論通常最後會有兩三份,再根據誰說話比較大聲,或鹽吃比較多,最後採納他的方案。

但是很多時候,UX 動線是很多天時地利人和的一個巧妙組合,未必這個技巧在 A 網站 work,就會在 B 網站 work。

也未必 C 醜 D 美,D 的轉換率就會比 C 高,可能 C 雖然醜,轉換率卻比 D 整整高了 20%。

所以務必 run A/B Testing。分配實驗比例,確保工程團隊沒有真的因為改版,一瞬間把交易量全滅了。

說得很好聽,如何實行?

有朋友跟我說,xdite,我覺得你現在產品 Tunning 理論最近講的都超漂亮,但是好像不是在矽谷根本做不到,要建這些工具與耗用人力,我們團隊根本負擔不起。

Well,這些技巧其實都不是外星科技,市面上已經都有第三方工具可以快速且容易的實作。

  1. Chartio 強大的 Query 工具,可以透過簡單的介面或手刻 SQL,拉出團隊關心的指標與數據。
  2. Mixpanel Funnel 量測工具,透過 event-based 觀測 funnel 轉換率的超強工具,也內建 messaging 與 profile history。
  3. Optimizely,強大的 A/B Testing 工具,只要有簡單的 jQuery 技巧就可以在網站上改得亂七八糟。可以隨機分配流量追蹤指標。未來還會推出個人化,鎖定具特定消費行為的使用者做 A/B deal testing。
  4. Geckoboard 之前我在做產品時,一次要盯幾十樣數據,確保今天的 deploy 不會無意中把某 funnel 炸得亂七八糟,還要確保不會發生爆炸了,五天後我才知道的事。我沒有辦法一次在 mixpanl 追蹤這麼多指標,所以我透過 geckboard 拉 mixpanel 去顯示我關心的數據,並且可以更細的針對前一天,每一週的數據去對比決策是否錯誤。

所以做這件事並沒有那麼難,只是需要多加一點功。

Summary : After having growth mind

要說我覺得從學會 growth hack 技巧後,心態上最大的轉變與感想是:

我覺得以「產品交易成功率」的產品改進策略,把軟體開發中的僵持難局,最後一哩路上的缺口都拼起來了。

軟體開發中最常出現的幾個膠著難題:

  • 專案管理中的角色切分權責大戰
  • UI 與 UX 的最終定案權
  • Testing 的顆粒度

都在這樣的模型中,有了很好很實際的解答。

我推薦各位也以這樣的角度,去重新審視產品開發的每一環,我相信你可以突然之間就發現一大塊新的天地。

 

宣傳連結

  1. Rails 實戰指南

    Buy Rails 101
  2. Rails 應徵寶典

    Land Dream Rails Job