訂閱本網誌: Facebook, Google+, 電子報, RSS

「Just Do It」不夠,你要「Just Ship It」

March 5th, 2012 by Jamie

This product is shit. –Steve Jobs

「我最近在做一個產品,可是它還沒有好,等到完成度比較高的時候,我再拿來給你看…」這幾乎是我最常聽到的一句話,問題它也是一句非常不合邏輯的話。如果你拿產品來給我看,是想聽我的意見,那與其等到快做完了,才發現其中有一些設計是我認為不合理的,不是應該早一點知道比較好?同樣的道理,如果你的產品是想給某個 TA (Target Audience) 使用的,那你也不必等到它快完成了,再來發現 TA 根本不需要這樣的東西吧?

大家都喜歡講 Steve Jobs 批評 Apple 同事的作品是「Shit」的故事,但很多人沒有注意到的是,他也常常讓這些「Shit」被拿去「Ship」。MobileMe 就是最好的例子,這個服務 2008 年從「.Mac」衍生出來,Jobs 還公開在台上推薦它,但私底下卻把整個開發團隊罵到臭頭。AppleTV/iTV 又是另一個例子,Jobs 顯然對這個產品一點都不滿意,每次上台都直說「AppleTV is just a hobby」。

為什麼?因為如果不「Ship」,你就得不到最珍貴的市場反饋,那產品也永遠無法「真正的進步」。不,你自己在家裡加的 800 個功能不算進步,很多時候還讓你的產品與市場越來越遠。對於新產品,人們往往喜歡簡單的東西,而不是複雜的瑞士刀。

至於工程師為什麼不敢 Ship 產品,我有兩個理論。第一,他們怕失敗。因為從小耳濡目染的「大眾市場」邏輯教我們,如果一個知名品牌丟了臉,那對於商譽的毀損無法衡量,客人可能永遠不再回來,公司甚至從此關門大吉。問題是,你的小品牌其實沒有很「知名」,說穿了丟臉就丟臉,也不必擔心有人記得,最差最差大不了換個網址再上不就得了。至於那小貓兩三隻的客人,我不是說他們不重要,但事實上你遲早會得罪某些人的 — 即使你把產品「做完」再上市,誰又能保證所有人就會一試成主顧呢?更重要的是你要認清你無法討好每一個人,所以實在沒什麼好怕的。

而更有趣的理由,是身為一個優秀的產品人員,根據定義,你對自己的產品往往永遠不會滿意。Andrew Chen 前幾天說了一個故事,他去 Pixar 拜訪一個朋友,Pixar 做了這麼多超棒的動畫,大概是大多數人心中最棒的 3D 卡通電影公司,結果當 Andrew 問他朋友:「你最喜歡你們家哪一部電影?」他的朋友居然答不出來,苦笑著說:

這實在是一個很難的問題,因為所有的電影都很不錯。但於此同時,我其實不忍看任何一部我參與過的影片,因為我花了無數個小時在其中,完全清楚所有我的小決擇、所有的小捷徑、所有其實可以更大膽的地方,但最後我沒有做,因為我害怕無法在排定的時間內完成。所以當我看這些電影時,我眼裡看到的,是這些種種的缺陷,而直到我把目光轉向家人、朋友們臉上,我才有辦法忘記它們。

沒錯,大多時候,你跟你的產品已經相處太久,早已到了無法用客觀角度去判斷它好壞的程度,甚至你還有可能會越鑽越深,永遠沒辦法滿意 (等等,這些 bugs 要修掉才能推出!)。但很多時候,你的產品早已遠遠超越市場的期待,你再繼續做下去,額外的邊際效益極低 (有多少機率消費者會碰到那個 bug?),甚至還有可能是負的 (首頁每多出更多功能,你的跳出率就會更高)。

所以,該如何解決這個問題?很簡單,就是跟 Pixar 一樣,有不能修改的 Deadline。在做一個產品之前,明訂一個「Shipping Day」– 最好是一、二週以後,最長也不要超過一個月。然後所有人,無論如何,到那天,就是要「Ship It」,沒有任何理由,沒有任何討論的空間,無論完成度如何– Just Ship It!

接著,你的產品開發就會起很有趣的化學變化,因為當大難臨頭,大家根本沒有時間在那邊務求完美,只會專注在最最核心的功能上面。沒錯,這就是用外力來達到 MVP (Minimum Viable Product) 的方法,也就是為什麼 appWorks 每個禮拜、每個月、期中、期末,一天到晚在 Demo 的原因。既然優秀的產品人員,沒辦法主動的做出 MVP,那我們就必須用別的方法,強迫 MVP 被做出來。因為從市場的角度看過去,「Just Do It」一點意義也沒有,只有在你「Ship It」的時候,你的產品才能真正和使用者互動,也才能真正開始找到方向。

有興趣參加我們的「創業新兵訓練營」?第五屆 appWorks 育成計畫歡迎你的加入。

(Photo from mikebeard, CC License)

  • 不如再寫一篇工程師如何敞開心胸接受這個環境的文章?

  • uuuiii00

    看到一半時就覺得要解決這個問題就要訂一個無法修改的deadline,個人經驗也是。去昭告大家你要推出產品的日期,這招真是怕失敗的愛面子人最好用的一招! 比起失敗,說話不算話也頗令人困窘XD

  • 看到一半時就覺得要解決這個問題就要訂一個無法修改的deadline,個人經驗也是。去昭告大家你要推出產品的日期,這招真是怕失敗的愛面子人最好用的一招! 比起失敗,說話不算話也頗令人困窘XD

  • tui

    請問各位
    如果做的是手機 App,當產品發佈的時候,此時的使用者很少, 我要怎麼從這少數使用者中得到寶貴的意見?

  • K00

    還好我從一開始就有在看 Jamie 的文章,或許稍微知道這個論點對於”網路 APP 產業”可以這麼做,因為其生產成本都建構在網路平台,軟體更新亦可背景自動作業來達到不斷強化的目的。

    但僅就個人觀點,對於其它產業就不一定是這樣的玩法,在各方面有限的情況下,以這樣的思維去提供 “有形” 的產品可能會玩死自己和reputation.  

  • 即使是”網路APP產業”, APP STORE在上周到達250億下載, 每只iPhone裡平均超過100個APP是很平常的事, 這是個非常競爭的市場, 個人觀點是, 把產品”丟”到市場上讓使用者給你意見這件事, 愈發只是種浪漫的想法, 即便要這麼做, 也有很多配套措施(版本更新通知, 評價促進, crash report處理流程), 畢竟你總要給”熱心的使用者”一條綠色通道吧?  台灣有許多開發者或其團隊, 連這些基本的工作都沒有做好, 就想要學習”一兩年前”外國Lean Startup的成功模式, 如果只學到皮毛而已, 最後fail也是很正常的

  • Tom

    不是很多軟體都會記錄使用者操作的過程並自動上傳到伺服器,例如記錄使用時間有多長,記錄離開你的app之前最後使用的功能項目。
    甚至在他選擇移除軟體時跳出問卷調查畫面(試試看關掉你的FB帳號他會問你多少問題)
    甚至最簡單的就是在app內提供email讓使用者告訴你他的想法(請參考小弟的android app作品「車上安心睡」,我從這簡單的email意見回報功能就收到許多使用者的回饋)。
    方法太多了,只是你不願意花時間去想而已。

  • tui

     hi Tom
    我有用 Flurry 來追蹤,確實看的到 App 使用時間有多長,還可以和某個種類的 App 來做比較,看看自己的表現如何。我甚至記錄了選項的點擊次數,但是這些數據,可能只能告訴我自己做的好不好,可是,到底哪裡不好?我下一步應該改什麼?我從數據中無從得知。

    所以,我才會問,有什麼辦法可以得到別人寶貴的想法。

    我是在我的 App 選項頁放上 Rating Me,但我發現,根本就沒有人點擊。你說的放 e-mail 意見回報,我試試看,感謝。

  • tui

     hi Tom
    我有用 Flurry 來追蹤,確實看的到 App 使用時間有多長,還可以和某個種類的 App 來做比較,看看自己的表現如何。我甚至記錄了選項的點擊次數,但是這些數據,可能只能告訴我自己做的好不好,可是,到底哪裡不好?我下一步應該改什麼?我從數據中無從得知。

    所以,我才會問,有什麼辦法可以得到別人寶貴的想法。

    我是在我的 App 選項頁放上 Rating Me,但我發現,根本就沒有人點擊。你說的放 e-mail 意見回報,我試試看,感謝。

  • 如果不嫌棄, 可以提供app連結來, 我很樂意給意見

  • Steelblued

    Steve Jobs didn’t expect MobileMe to have so many service failures, if he knew, he wouldn’t have shipped it

  • 這很難,我也還在摸索

  • 是,那也是一個很棒的方法。

  • That’s an assumption.  Maybe it’s right, maybe it’s wrong.  But I think the fact is he shipped MobileMe without knowing for a fact that it worked the way he wanted it to work, which to me is him taking a risk to ship before he is absolutely certain.  And that’s the main point of this post.

  • 邀請使用者來直接聊更快

  • MVP 的 V 是 Viable 的意思,所以不是功能少就是 MVP. 😉

  • 所以小團隊的優勢就是沒什麼 reputation 要擔心,那就要利用這個優勢

  • InfinityLai

    這個道理與一種稱為「極限編程(Extreme Programming) 」 的軟體工程原理完全一致,規範短的開發週期、不斷反覆、接受回饋、擁抱變化。

  • 是,Extreme Programming / Agile Development 裡面的許多邏輯,和 Lean Startup 是相通的。

  • JChouIsHere

    Steve sure knows the trick to turn sh*t into “THE” sh*t!

  • 是啊,以毒攻毒

©2018 MR JAMIE.
網站由 Allen Hsu 設計 | Logo 動畫由 Wen Chen 完成