選讀：Y Combinator SUS - How to Plan an MVP
選讀系列我會翻譯我覺得不錯的文章或影片。這篇我選了 Michael Seibel 在 Y Combinator Startup School 分享的 How to Plan an MVP，這堂課在分享如何規劃最簡可行產品。
Michael Seibel 是遊戲實況直播平台 Twitch 的共同創辦人，同時也是現任的 YC CEO 和 Partner。
https://youtu.be/1hHMwLxN6EM
內容 Jump to heading
嗨，我叫做 Michael，我在 Y Combinator 工作，我負責經營加速器的部份，在這之前，我在 YC 創辦過兩間新創公司，一個是 2007 時，另一個是 2012 時。
今天我要跟各位分享的主題是最簡可行產品，或稱作 MVP，我們總是告誡創辦人們不要用行話，但在新創的圈子裡還是有不少愚蠢的行話，MVP 就是其中一個。當你在想 MVP 時，你應該去構思一個超級簡單的東西，這是用來驗證你提供給你瞄準的首批使用者的第一個東西是否可以為他們帶來任何一絲價值，就僅僅是如此，這麼樣的簡單。
Some understanding of the problem is very helpful when building an MVP so please talk to your users before writing code.
當你在開發 MVP 時，對於你在解決的麻煩有些基本的認知是非常有幫助的，所以請再動手開發前先跟你的使用者聊聊。
我知道上週各位參加的課程是關於怎麼構想主意、怎麼找出你可以解決的麻煩，我想告訴你們的是儘管在你決定 MVP 該長什麼樣子前先和一些使用者聊聊會很有幫助，但那不代表你得先進行一個三年的研究或在相關產業工作十年，簡單的聊聊就會有幫助，如果你剛好就是自己產品的使用者會更好，你可以自己評估你的產品是否有幫助到你。我總是被問到一個奇怪的問題「我該如何找到我的第一個使用者？」，這老是讓我感到困惑，理論上來說，你決定要解決一個某人遇到的麻煩，那你的第一個使用者就可以是那個「某人」，如果你就是那個「某人」的話事情就更簡單了，所以如果你正在為一群未知的對象開發產品，你真該好好的思考一下，真的。
Goal of a pre-launch startup:
產品尚未上線的公司的目標* Launch quickly (MVP)
趕快推出產品 (MVP)
* Get initial customers
找到第一批使用者
* Talk to customers and get feedback
和客戶聊聊並取得回饋
* Iterate (improve the product)
迭代改善 (改善產品)
一個尚未推出產品的新創公司的目標非常的簡單，第一步，趕快推出產品，這是 YC 一直以來的核心精神，這十年來證明它是一個很棒的建議，接下來也一直會是，如果要說今天你可以從這場分享帶走些什麼，那就是趕快推出一個不好的產品，就這樣，剩下我要分享的內容都是在重新的闡述這件事。
第二個早期發展中的新創公司該做的是找到第一批客戶，找到任何一個人來使用你的產品，你不需要具有如何讓所有人都用你的產品的願景，你只需要某一個人去使用然後找出這個產品的價值，你會很訝異有多少創辦人的創業旅程在完全沒有使用者使用過他們的產品前就結束了，這非常非常的常見，所以拜託你們熬過這個階段，這非常的重要。
下一個是，在你推出 MVP 後，至少和你的任何一個使用者聊聊，並取得一些回饋，這部份也有一個很常見的錯誤，許多創辦人的心中對於他們想做出什麼樣的東西有想法，所以他們會有種奇怪的感覺「在我的產品還沒完全達到我心裡想像的樣貌前，去蒐集眼前這個爛東西的回饋有什麼用，這當然沒有，這還不是完整的產品，完整的產品可能需要三年、一千萬的資金、一個完整的團隊，所以針對這小小的進度的回饋一點用也沒有」，事實是，你想像中的完整的產品，那個超棒的主意應該就留在你的腦海裡，你得保持非常大的彈性，因為有可能你想像中的完整產品完全不是客戶想要的東西，我常說「握緊你想解決的麻煩、握緊你的使用者、輕握你的解決方法」。
最後一個重點，迭代改善，我想解釋一下迭代改善和改變方向的區別，許多創辦人在想出要開發什麼產品後就愛上了那個產品，所以當這個產品對某些使用者沒有幫助時，他們就會想「讓我想想這個產品還可以解決些什麼麻煩」，這就有點像「嗯，這支螺絲起子沒辦法用來鎖緊任何一顆螺絲，讓我想想它還能用來幹麻」，然後他們就會說出「或許它可以用在料理上」、「或許它可以用在清潔上」，不！使用者的麻煩是他需要鎖上某個螺絲，這個使用者可能是一個技師，如果你的螺絲起子沒辦法幫助技師解決麻煩，留下技師、留下需要鎖上螺絲的麻煩、修好該死的螺絲起子！這才是有問題的部份，有問題的不是技師也不是他們需要鎖上某個螺絲。所以迭代改善，持續的改進你的解決方法，直到它解決了那個麻煩。
Lean MVP (in most cases)
輕盈的 MVP (大部分的情況)* Very fast to build (weeks not months)
能夠很快開發出來 (幾周而不是幾個月)
* Very limited functionality
非常有限的功能
* Appeal to a small set of users
吸引一小群使用者
* Base to iterate from
有個基礎可以迭代改善
絕大多數的情況，大部分的人都該推出很輕盈的 MVP，我們的意思是，你應該要能很快的開發出來，幾周內而不是幾個月。這可以是一個軟體，或我們甚至看過有些新創只有登錄介紹網頁和一個表格，大部分的新創公司可以很快的上線。第二是非常有限的功能，你必須濃縮你的使用者的需求，你的早期使用者的需求，成很簡單的幾件事，常常創辦人會想解決他們使用者的所有麻煩，和所有的潛在使用者，而事實上他們應該聚焦在一小部份的早期使用者，和這些使用者最重要的麻煩，然後推遲所有其他的一切，你應該要有很大的願景，很小的 MVP，而這只是迭代發展的根基，就只是個起始點，它沒有什麼特別的，你需要就是開始，所以請不要認為你的 MVP 很特別。
這是一個經典的案例，這是 Airbnb 的第一個登錄介紹頁面，我記得是 2008 時，你可能會對 Airbnb 的第一個產品感到有興趣的部份是，它沒有付費系統，當你在 Airbnb 上租了某個房間，你必須親自付錢給房東，不用我說你也能想像那是一個大麻煩，但他們就在沒有付費系統的狀況下上線；它沒有地圖瀏覽功能，你們都知道在 Airbnb 怎麼找房子，你可以看到房子在城市裡的哪個地方，抱歉，那時候沒有這個功能；而開發所有程式的人 Nate，是兼職的。大家都在流傳打從一開始每件事都是完美的神奇故事，Airbnb 一開始並不完美。
下一個，Twitch，這是 Twitch 第一天上線的樣子，認不得對吧，或許有一點像，裡面有個影像，裡面有個留言板，除此之外都不一樣，Twitch 上線時叫做 justin.tv，是一個即時的實境秀，裡面只有一個頻道，就是 Justin，你必須跟著他過生活，如果你不喜歡他的生活，你只能離開這個網站，當時就只有這個，當時的轉播解析度超低，有件趣事是，曾經有個投資者問我「噢，這不是很怪嗎，你們的公寓裡有個攝影機，如果你們有些機密的文件，大家不都看得到」，我的回應是「你幾乎無法看清我們的五官，更不用說我們的文件」，更重要的是，那時候完全和遊戲扯不上關係，除了當我們在公寓打電動時，那是遊戲唯一會出現的時候。所以要做到這樣的程度很容易，現在的 Twitch 已經變得複雜許多。
最後一個，Stripe，當然還不叫 Stripe，它叫作 /dev/payments，何不可為呢，取一個非常容易記得的名字。這是 Stripe 第一天上線的樣子，沒有和任何銀行合作，我沒辦法透露他們確切如何進行付款流程，但那是一個非常「新創」的方法；幾乎沒有功能，更酷的是，如果你想用 Stripe，Stripe 的創辦人會到你的辦公室去為你整合，多麼棒呀，一方面是因為他們迫切的希望有人可以用他們的產品，另一方面那是一個可以趕在使用者找到 bug 前先把 bug 找出來的方法。
這是三個有著超簡單且超快能開發的 MVP 的例子，這些現在有著數十億估值的公司都從大部分人認為很爛的產品開始。
Heavy MVP (in very few cases)
重型 MVP (很少部份的情況)* Significant regulation (insurance, banking)
重度法規限制的
* Hardtech
硬底子的科技
* Biotech
生物科技
* Moonshot
如同登月般大膽的計畫
只有在很少數的情況下你得開發一個重型的 MVP，Heavy MVP 是我兩天前在準備這場演講時自創的名詞，說不定它會紅起來。如果你是身處於受到很多法規規範的產業，例如保險業或銀行業，無人機有時也是，要上線比較困難，你得先合規；如果你是在硬體科技產業，例如你在製造火箭，要在幾周內開發出火箭很困難；生物科技領域，要在幾周內發明癌症藥物很困難；如同登月般大膽的新創計畫，我隨便舉個例子，要在幾周內在地底鑽隧道並提供超快的交通工具來取代汽車很困難。如果你是這個狀況，請記住，你的 MVP 可以是一個很簡單的網站，來解釋你在做些什麼，在和使用者解釋和說明你在做些什麼時，有個可以事後參考的東西會很有幫助。這可以是你的起始點，你可以在幾天內建立一個網站，而不需要幾周，某些情況下，你可以用一些特別的方法讓你的重型 MVP 比輕盈的 MVP 更快上線。
接著我想談談關於產品上線這件事，因為很多創辦人對於產品上線有些誤解。他們看了大公司產品上線的方式就認為新創公司也應該一樣，事實上他們看到的是他們「以為」是新創公司的大公司，Facebook 其實已經不再是新創公司了，但當他們看到這類公司有許多媒體報導、有許多話題等等等，他們心裡以為成功的公司在上線時應該都是這個樣子。我想問各位一個問題，在場有多少人記得 Google 上線的那天？沒有。那 Facebook 呢？好。那 Twitter 呢？沒有。很好，這代表上線這件事一點都不特別，如果想為你神奇的點子來一場轟動的上線，放棄吧，上線根本沒那麼特別。
Launch simply means to start getting customers.
產品上線僅僅代表開始取得客戶。
你的首要任務是找到一些客戶，為了讓那些人心裡舒坦一些，讓我們試試重新定義一下上線的意義，例如「上線指的是當你有任何一個客戶時」，例如「新聞發表會指的是有人寫了一些文章，然後你得到了一些話題」，讓我們推遲新聞發表會，然後將「取得任何一個客戶」的上線端到面前，這才是我們的目標。
Learning from customers is easier with an MVP than without.
有 MVP 比沒有讓你更容易從客戶身上學習。
當你的客戶沒有產品可以體驗時，要從他們身上學習任何東西困難許多。你可以整天進行使用者訪談，但你不會知道你做出來的產品是不是真的能解決他們的問題，如果把你的產品擺在他們面前，你馬上就能知道。世上的研究都很棒，但只有在你端出具體的東西時你才會知道他有沒有用，所以花一堆時間在製作簡報遠比不上動手做出任何東西給你的客戶來的有價值。
Hacks for building an MVP quickly
一些很快能夠做出 MVP 的秘訣* Time box your spec
先訂下時間限制
* Write your spec
寫下規格
* Cut your spec
刪減規格
* Don't fall in love with your MVP!
別愛上你的 MVP！
最後，一些很快能夠做出 MVP 的秘訣。
首先，訂下上線時間來限制你的產品規格，你的產品規格是在上線前你要開發出的東西的列表，先訂下上線時間吧，例如「如果我想要在三週後上線，我該做些什麼？」，那在產品規格上的東西就該是我三週內能夠做出來的，這讓你的人生簡單許多，這讓你刪掉那些你在三週內做不出來的東西。
第二，寫下你的產品規格，這聽起來很直覺，但大多數的人都搞砸了，在你的產品上線前總是很容易變動，因為你從來沒有把規格寫下來，你開始動手開發，然後你在和你的使用者訪談時聽到「噢，我絕對不會用這個東西！」，或老天保佑的你在和你的投資者聊聊時聽到「噢，這不可能有商業價值！」，因為投資者對任何事情都「很懂」，所以你決定改變你正在做的東西，而因為你沒有把規格寫下來，你根本沒有意識到自己改了規格，於是你的三週計畫變成了三個月計畫，如果你當初有把規格寫下來，你至少可以坦承自己老是在改規格。
下一個是刪減你的規格，在你的三週計畫經過一週後，你大概會發現加了太多東西到歸格裡了，你大概無法在期限前完成，沒關係，就把不重要的東西刪掉，如果沒有不重要的東西，那就開始刪掉重要的東西，這時最重要的目標是想辦法生出一些東西到這個世界上，一旦你生出了一些東西到這個世界上，要讓這東西持續轉動的動量會非常的強，如果你什麼都沒有做出來，那就會很容易陷入無止境的延期。
最後一點是別愛上你的 MVP，有太多人愛上他們腦海裡的願景，我先前展示給你們看得產品中，沒有一個最後一個成為它們當初的願景，所以請不要愛上你的 MVP，這只是旅程中的第一站，你不會愛上你一年級時寫的文章，但你的 MVP 通常就是那樣的程度。
問答 Jump to heading
好，這些就是我要分享的，我們有一點時間可以回答問題，有沒有什麼問題？很好，沒有問題...
Q1: 在使用者訪談的過程中，我遇到需求很零碎的狀況，有些人想要這個，而另一群人想要那個，因為每一群人都很小，所以分佈很均勻，我該...
A1: 很好的問題，你和使用者進行訪談，他們回饋了許多不同的你想做的東西，而其中沒有很高的重疊，我可以給你一個根本的答案，絕對不要問你的使用者想要什麼功能，絕對不要讓你的使用者告訴你他們想要什麼，選擇要發展什麼功能不是使用者的工作，那是你的工作，使用者的工作是告訴你他們的麻煩。當你在和你的使用者進行訪談時，我猜測他們都有一連串的麻煩，而他們不知道該怎麼解決，所以他們會給你一長串他們認為可以解決的方法，而不是花時間告訴你他們的麻煩到底是什麼、他們多久遇到一次、這個麻煩都嚴重、他們是否願意花錢解決、他們是否知道有哪個人也有一樣的麻煩，這些問題才是我們真的想要使用者回答的，如果你察覺到受訪者開始談論功能面，像是「噢，你知道嗎，我愛微軟的 Word，但我希望有人可以開發這樣那樣的功能...」，這時你應該引導回「噢，為什麼你要樣這樣那樣的功能，你遇到什麼麻煩、你多久遇到一次」，讓他回到麻煩本身，這是你如何可以避免功能索求的絕境，這是非常常見的情況。
Q2: 我發現我在兩個狀況來回遊走，一端是專注在當下的 MVP 上，另一端是因為發現更好的主意而改變 MVP。我開始開發某個 MVP，並且進行使用者訪談，接著我就遇到「不不不，我們得做這個，我們得做這個，我們得做這個」的情況。我應該要服用過動症的藥物，就專注在一開始的方向，或者我該在什麼時候改變方向？
A2: 好，你的問題是「我被困在持續改變 MVP 而無法上線的輪迴中」，我看見很多人陷在這樣的輪迴中，而對於很多新創公司遇到的問題的通用答案是，停止你現在的行為，就不要在繼續，你不需要一直改變你的 MVP，你會想要改變你的 MVP 的其中一個原因可能是你認為你的 MVP 很特別，如果你不要這樣想，你就不會想要追求新的方向，你就會停止改變它。
Q2-cont'd: 我不太懂。可以再解釋一下嗎？
A2-cont'd: 如果你認為你的 MVP 很特別，你就會認為它需要是完美的，如果你認為他需要是完美的，你就會花很多時間在上面。如果你假設它應該要是很糟的，就像如果要從衣櫃裡挑一件襯衫來彩繪，最終把它丟了，你就不會想要花時間縫補它，對吧，所以如果你把你的 MVP 想得不是那麼特別，你就不會花太多時間修補它。
Q3: 假設你的 MVP 上線了，你想要尋求一些使用者的回饋，有哪些重要的問題是你會問使用者的？
A3: 這是一個很簡單的問題，當你想要針對 MVP 向使用者尋求回饋，有哪些重要的事是你會想要了解的，這個 MVP 是否有解決你想要解決的麻煩，就這個，你可能會得到八十種不同的答案，但如果你很清楚你要解決的麻煩，其實你甚至不需要問，如果它就在使用者的面前，你會看得出他們是否按照你預想中的方式使用，或是你可以從數據看出來，如果這是一個他們每天會遇到的麻煩，當你向使用者介紹了這個產品，他們隔天是否有再主動找上門來。我從沒看過有哪個產品解決了人們頻繁遇到的麻煩，真的解決的那種，而使用者卻不再使用的，這些答案會有一些細微的差別，但那無所謂，重點是使用者有沒有做了那件你認為可以解決他們麻煩的事。有沒有其他問題？
Q4: MVP 應該要進行到什麼時候？我的意思是，當你開始成長，下一步應該是什麼？
A4: 你知道創業有趣的地方是什麼嗎？我不喜歡在推出 MVP 前去想時程和規劃未來的方向，沒人知道會發生什麼事，先推出產品，然後再去找出答案。你決定要創業，而創業的一個特性是，要如何從 A 點到 Z 點是未知的，所以如果你太專注在像是「我知道推出 MVP 是 B 點，但我現在正專注在 找出 C、D、和 E」，我會告訴你「嘿，先解決你眼前的麻煩如何？」
Q5: 你如何平衡改善 MVP 以增加使用者保留率和把精力用在獲取和開發新客？
A5: 在 MVP 上線後，你應該要專注在獲取新客還是留住老客戶，我愛這個問題，這是世界上最有趣的問題，因為我可以老是回答同樣的罐頭答案，兩者皆是！沒錯，事情是這樣的，很多創辦人心裡知道創業是一個多變數的問題，但因為多變數的問題很困難，所以他們試著把他轉化成單變數的問題，所以他們總是問那些神秘的顧問「噢，哪個比較重要，獲取新客還是留住老客戶？」，這就像在問「哪個比較重要，洗澡還是上廁所？」，然後得到「第二」這樣的答案，我希望你兩者兼顧，抱歉，兩個都很重要，身為一個創辦人，你得學會同時拋多個球。
Q6: 你有經驗是一個新創公司沒辦法找到使用者聊聊，因為他們鎖定的使用者不想分享遇到的麻煩嗎？以及他們怎麼解決這個問題？
A6: 讓我釐清一下問題，當你的使用者有一個麻煩卻不想分享，你要怎麼進行訪談，何不你告訴我那是什麼麻煩？
Q6-cont'd: 第二型糖尿病。
A6-cont'd: 第二型糖尿病，我很有信心你可以找到十個願意聊聊他們的第二型糖尿病的人，我想問你的是，你創業以幫助患有第二型糖尿病的人，而你卻不知道任何一個願意和你聊聊的病患，我想這就是一種錯誤的假設，就像「我否定這個問題的前提」，好，下一個問題。
Q7: 在向投資者報告前，MVP 要有多少註冊使用者或是活躍使用者才夠？應該要參考什麼數據？像是市場規模之類的？
A7: 這是一個很好的問題，如果我要簡化這個問題，那會是「我距離能找投資者還有多遠？」，我想要先不回答這個問題，接下來會有一堂課專門在談什麼時候該找投資者，所以請等一下那門課，不管是誰教授那門課都能很好的回答這個問題。
Q8: 什麼樣的數據可以證明你的產品通過驗證？
A8: 我要重新闡述一次這個問題，「你要怎麼知道你有 product-market fit？」，好，經典的答案，事實上也是正確的，而創辦人們都很討厭的是，如果你在問這個問題，那就代表你沒有，當你有 product-market fit 時會發生什麼事是，你有太多使用者以至於你放下手邊的任何事情只為了設法維持你的產品保持運作，這是 product-market fit 看起來的樣子，你會停止構想新的功能，你會停止思考如何改善轉換率，你會停止思考如何將產品散佈的更廣，你會像「天阿，我不知道該怎麼服務明天將湧進來的客戶，我現在不知道該怎麼辦，下週我也不知道該怎麼辦，我確定我們要垮了，因為我們有太多使用者」，有趣的是，當我這樣定義，你很容易的知道你是不是已經達成了，而很現實的是，幾乎沒有人可以達到 product-market fit，幾乎沒有人可以，幾乎沒有。很多人嘴巴上老是掛著這個名詞，很多人喜歡把他重新定義成「有人在用我的產品」，那不是這個名詞，「有人在用我的產品」的名詞是「我有使用者」，這樣很好，但這不是 product-market fit。
Q9: 當我們和愈多使用者進行訪談，我們所定義的麻煩就變得愈來愈大，我們該如果定義出 MVP，我們從其中一個使用者開始，接著我們做了一個小小的實驗，但我們卻找到更多麻煩。
A9: 當你和使用者接觸，在你愈了解這個麻煩時卻發現麻煩擴展的愈大該怎麼辦，這完全沒有關係，其實這是預料之中的，但我想分享的是，創辦人常犯的錯誤是，他們認為他們得解決所有人的麻煩，比較重要的是，當你發現有一個使用者有這樣的麻煩，一個不錯的方法是找出有沒有其他像這樣的人，一個有趣的方法是就直接問這些人，「嘿，你知道有任何人也遇到你這樣的麻煩嗎？」。當你試著退一步去看任何一個麻煩，而且去思考這個創辦人的願景，你會發現它們包含了一整組的麻煩，而我認為人們真的搞砸 MVP 的原因是，他們有很大的願景，但卻不願意從一個很小的 MVP 開始，他們覺得如果他們沒有事先考量到所有的潛在客戶就是失敗的，而有很多時候新創公司或創辦人們得同時兼顧兩件事情，大的遠景和小的 MVP、獲取新客和留住舊客、YC 常常在講的對投資者的推銷和對客戶的推銷，這些都非常不同，而創辦人們總是想要把他們混在一起或犧牲其中一樣，因為把它想作一個事情比想作兩個對立的事情簡單多了，「怎麼可能我們想要提供給所有人用的支付功能，但我們只有一個小小 API，而它難用到我們得親自為人整合」，但兩件事情都是我們想要的，你必須習慣這樣的情況。好，最後一個問題。
Q10: 在製藥業裡，我們使用者應該是科學家還是病患？
A10: 在製藥業裡，誰是你的使用者，我想這個問題應該要問你自己，是你在創立公司，你知道你在打造些什麼，你知道你在解決什麼麻煩，你知道誰有這個麻煩，這些我都不知道。好，很開心能夠跟各位分享，謝謝大家。
Published