在這一章。我們先不談創業方法。我想改談一些創業路上我所走過的坑。
我認爲，在創業前改變一些視角，提升創業成功的機率，遠比學習方法論更重要。
一路以來，在創業路上走過不少坑，可以說把程序員創業會跳過的坑都跳遍了。
這些坑，與其說是坑。還不如說是創業市場上的反常識，創業市場是一個很反常理的領域，絕大多數你在公司當高管或資深程序員時，所學到的最佳實踐，在創業時反而沒有效，很多時候甚至還會害死你。
我希望分享這些創業路上的故事，能夠爲大家帶來一些啓發。
我在創業前，是一個頂尖的程序員。
2012 年到這本書寫作（2018）的時候，過了 6 年。這六年，我覺得基本上是一個unlearn 的過程。什麼叫 unlearn？就是所有我在程序員世界學的 best practice，在這六年以來都崩解了。
我曾經信奉的最高信仰教條，在我創業的時候全部都崩解了。
這當中最讓我感到矛盾衝突的地方在於，我以前的角色是程序員大神。我意識到這些秩序陸續在我面前崩解，而且我意識到我以前信奉的都是錯的之後，後來再跟我後來創業公司裏面的程序員分享這些領悟的時候，他們「不相信」。
比如我跟他們說：
「創業項目不需要太注重code的質量，趕快他媽的先上線纔是王道」。
他們就會覺得我是不是不會寫 code，纔會講這種反常識的話。
還有我可能會說：「創業剛開始就不需要注重擴展問題，code quality不重要」。
他們聽到以後感到都很震驚。紛紛懷疑我當年的功力是不是假的。
當然，我不是沒有技術功底。如果我沒有技術功底的話，ico.info 與 OTCBTC 這兩次風口閃電戰，不可能打的這麼成功。
這兩個產品都是瞬間上線，然後上線第一週就有非常大的在線壓力與迭代壓力。
所謂的「不需要注重擴展」，只是我的一個「選擇」。
我覺得程序員創業會遇到的的最大的一個盲點，是他們本身會把之前上班的時候學到的best practice帶到創業起步的觀念裏面。我認爲這件事情是最恐怖的。
因爲程序員，是一個特殊的工種。程序員會在公司出現的階段，通常是公司已經「穩定」以後，纔會被僱用進去。
甚至它們的工作，就是被用來重構那些混亂的「生意邏輯」與「不堪用的代碼」。
所以很多程序員是不太知道「生意是怎麼做起來的」，甚至還會認爲「自己是救世主」，被派來拯救這一團混亂。
而會選擇出去創業的程序員，通常背景會是「資深程序員」或者是「程序員大神」。
到了這個級別，通常纔會自覺得有資格有實力出來創業。
甚至這個級別的人。甚至對於「擴展」這個技能，已經練到登峯造極了。
程序員這個工種。主要的工作職責是：
- 將重複的過程自動化
- 將系統優化再優化
- 讓代碼結構乾淨，可擴展
整個生涯領域，都是朝這個方向不斷的在打磨。
但是程序員所身處的公司階段，通常是一個處於有盈餘且公司並沒有生死存亡的問題需要面對的階段。
所以程序員可以「好整以暇」的慢慢打磨產品。而做好這些擴展，重構，都需要耗上大量時間。
不過，創業時就很不一樣了。
創業從0到1這個階段，時間資源是很貴的。如果幸運在創業時遇到一個風口，如果你的項目不在時間窗口上線，這場遊戲就會完全沒有你的份。
而且創業的重點，是在於做出「有價值的產品」。至於產品內部的質量，那是活下來，有資源以後才追求的事。
對於大多數人（甚至是 100%）來說，有時候創業有點像是一場賭博。
很可能你做的產品，只有你自己需要，但是別人可能沒有需求。又或者是你的產品，可以有幸擴大，讓很大的族羣使用。
但這件事情，在大多數的情況下，很碰運氣。
如果創業一開始的作法，就是專注在於打造一個底層很棒很能擴展的牛逼產品。這個策略就有點像是上賭桌時，一開始就 ALL IN 在一個很容易 GG 的選項。有很大機率會陣亡。
而且，人有一個奇怪的傾向。就是傾向於相信自己一開始的決策是對的。所以既然一開頭ALL IN了自己的所有資源，而且也花了兩個月的時間寫了代碼。自然就不太願意相信當初的選擇是錯的。
所以後續很正常的就會錯的選擇決定上，一再迭代，拼命希望它是正確的。
所以我最常看到很多程序員創業失敗的標準典型：
覺得自己做的產品這個很好，代碼也寫得很漂亮，當初也花了許多時間籌備，但反覆迭代了六個月，最後還是起不來。
但，事實上創業會成功的那些人，反而是那些不太會寫代碼的創業家。或是懂得寫代碼，卻覺得創業一開始不需要寫代碼的連續創業者，光是用Landing Page驗證點子，就賺到一大堆錢。
所以創業實際上是很反直覺的事。
因爲因爲你沒有辦法相信，自己練了多年的武功，在創業這個世界是沒毛用的。
我第一次認知到這件事情時，打擊很大。
因爲我最初剛剛開始的時候，我想要創業，但我不會寫代碼。於是我就去學寫代碼，練了多年以後，終於變成了高手。變成高手以後，終於出去創業了。
但創業以後，卻發現學了那麼多年代碼與架構，是一點毛用都沒有的。所以我內心是很崩潰的。
創業開始接下來的六年，這當中，我基本上是一直試圖在忘記我曾經學到的東西，那些東西會害死你。
Over Engineering，我覺得這個是會害程序員最慘的一個習慣。
如果你仔細觀察，國外創業成功的Startup，YC 投資的那些 Startup。創辦人都有一個特點，要麼他不會寫code，要麼他只會寫一點點code。
不過這個事實，害讓程序員對它們感到嫉妒，感到很不公平：「我是一個牛逼的程序員，我這麼會寫代碼，理當應該創業比它們牛逼阿」
雖然頂尖程序員內心會這麼想。但實際不是這樣發生：「你很難看到程序員代碼高手，最後成爲成功的創業家的」。
這當中的差別，在於：
- 成功的創業家，內心根本沒有「乾淨的代碼架構」這個包袱
- 成功的創業家，反而是看到強大的市場需求，捲起袖子馬上就先幹再說。
Github 的創辦人，他們也承認它們創業一開始，裏面並沒有Git的高手。而是發現這個需求後，開始寫了一陣子，才找Git高手進來。我認識Github裏面的程序員，他說早期Github裏面code也就是爛的要死。
很多人覺得 Github 是程序員的神聖殿堂，代碼怎麼可能很差勁。但是早期裏面的代碼，基本上真的慘不忍睹。甚至，很長一段時間，他們的代碼都還卡在 Rails 老舊的版本號上。不能升級的原因，還是因爲沒有寫測試，所以升不了版本。
我創業前，待的硅谷創業公司，是做外賣服務的（2014）。
創辦人一開始在創業的時候，也根本不會寫代碼，YC 投了它們，然後逼創辦人去寫代碼。所以服務的 API 與後臺，是創辦人自己寫的。
系統的代碼是我擅長的技術：Ruby on Rails。
我當初剛進入公司，被僱用的職責主要是帶領技術團隊，擴展重構這個服務。
但是上班第一天，我把代碼拉下來，然後呆了一個小時。爲什麼？
正常情況下，我們在開發時，都會要求資淺程序員，在一個 Controller 檔案裏面，不得寫超過 200 行的代碼，寫超過 200 行，就表示業務邏輯複雜，需要重構。
然而，我拉下來的這套代碼，一個 Rails Controller，足足有一萬多行。
足足把我震驚住了。難怪功能加不上去，改不動。
所以，我進公司的第一個工作，就是把這一支一萬行的代碼，分拆乾淨。而且線上不能爆炸。我都要發瘋了.....
一支一萬行的代碼，在一般正常程序員團隊裏，簡直是不可想象的。
所以當團隊在重構時，大家一邊重構一邊罵，爲什麼創辦人都沒規劃就在亂寫代碼！根本是沒想清楚，想到什麼業務邏輯，就先加上去。代碼醜得像一沱屎。團隊裏面的每個程序員都在狂抱怨。
問題是輪到我自己創業的時候。特別是那兩個非常火爆的服務平臺 ico.info 與 OTCBTC。那時候也遇到相同的狀況，遇到什麼需求就馬上加 code。因爲客戶需求實在他媽太大了。幾乎所有的功能，都只能先 workaround。
很多程序員，會有這樣的想法：
我創業一定要按部就班，一切規劃完美，然後執行上線。因爲我老闆就是創業時亂寫東西，搞到後面很多要打掉重練。害得生意無法快速擴展。所以我自己創業，一定要吸收這樣的教訓。一開始就把代碼寫好。
但是，我必須坦白說。這件事情是不可能存在的。
如果這件事情存在並且有人做到。這個程序員，一定會大寫特寫博客大肆炫耀，仔細記錄自己如何完美規劃，並且有效執行上線的。
但是一直以來世界上沒有出現這件事。這就表示這個幻想（仔細規劃，完美執行上線）這件事情存在的機率，是相當渺茫的。
程序員界現在很流行一個 buzzword，微服務 micro service。micro service 就是把每個功能，都拆成一個封裝完備的小服務，由小服務堆積來成爲大服務。以追求效能上的擴展。
「水平擴展」這個詞，有點像是程序員界的春藥。聽到就容易高潮。
很多人對於比較有名的服務都存在一個幻想。有名的服務一定是用了牛逼的技術，水平擴展，各種高大上技術。但是，真實的場景真不是這樣。絕大多數公司，都是加機器加機器，死命狂撐，撐到有大神加入來救他們。。。。因爲每天光忙業務改版就來不及，哪有時間與能力改架構。
舉例來說，我們 OTCBTC 雖然有很多服務。但本身也不是用 micro service 打造的，OTCBTC 從頭到尾就是一個 monolith 服務（就是把所有服務都放在同一個 Rails App 裏面）
有些程序員在面試的時候，聽到這樣的架構，覺得很震驚。爲什麼開發這麼多服務，卻不是拆分成 service 呢？這樣的架構才能水平擴展。
但是，當我們回答，這是因爲創業精力有限，沒有時間拆（那時候創業都剛半年，但生意已經很大）。我看到程序員的眼底，就露出「不屑」的神情（大概這樣的回答讓對方覺得我們團隊沒實力吧...）。
不過，其實我對這樣的反應，也挺不高興的。（我內心的 OS 是「你他媽懂什麼...」）
真不是我傲慢。
因爲我在程序員生涯，真的沒見過多少個例子，創業一開始就是用微服務搭建項目，然後馬上就大獲成功的。
反而看得比較多的例子是：一開始創業，就採用微服務架構搭建，反而害死自己的。
之前 2016 年中國知識付費風口時，當時我在某知識付費服務講課的時候，它們的底層服務就是用 micro service 搭建的。micros service 一開始每個模組都拆得很小。
雖然很小，有辦法維護，看起又輕便。（因爲這個服務一開始就要承載幾千人上線）但這是一種錯覺。幾十個小服務，疊在一起還是一個大服務。而且每個小服務，互相呼叫，都是有通訊上的 over head 的。所以一旦流量灌進來的時候，很難知道真正瓶頸在哪裏。
在知識付費的風口上，雖然想搶佔風口。但是他們的服務在業界口碑極差。因爲這個服務可用度極低，每當線上超過千人在線時，服務就會卡掉。偏偏每堂課都是線上直播。搞的老師跟同學都很尷尬。所以很多老師用過一次就生氣就走了。同學也對這個平臺的質量不敢苟同。
在知識付費的風口上，這個服務就一直遲遲沒有辦法達到基本的可用度。所以最後就倒了。
原本他們想要用微服務，一開始就先預先擴展，但聰明反被聰明誤。反而被這種架構整死。
但是如果一開始，土一點，直接用一個大的成熟框架開發，可能就不會有這樣的問題。
- 內部沒有 overhead，搭建迭代速度很快
- 框架通常夠成熟，又開源。反而容易 google 知道那邊有可能瓶頸最大，問題好解決
- 再不行就直接把機器換到最大臺，直接收工。
但是這套服務，是由無數自己寫的micro service組成。要去徹底 debug，就非常困難。因爲這些的micro service，只是按照當初的假想去拆的，根本不是因爲服務遇到了現實的瓶頸去分拆的。反而活生生搞死自己。
創業的重點，真的不在於底層架構如何設計。預先 pre-scale 反而變得無法除錯。
反而是那些程序員不齒的一大包代碼架構。反而是容易擴展的選項，要提升效能，用錢就能夠解決了。
錢反而也不是什麼困難的事。一旦產品有了市場任口，就有了流量，有了流量就有錢。有業績，就容易拉得到投資。到時候想請幾個架構師，重構都行。
這個例子是我看到，最經典的微服務害死自己的例子。
很多程序員都非常熱衷於這種過度架構 Over Engineering。
我必須再次強調，我個人不是反程序員。我自己以前還是技術精湛的程序員。我只是想強調，過去我也曾經被這些觀念害得很慘。
所以現在，在聽到這些 buzzword 的時候，心裏常覺得不以爲然。
因爲很多事情，真的是得踩過坑的人，才知道這有多痛。
而多數程序員，並不知道這些觀念對創業來說，都是很毒的毒藥。
第三個冤枉路，就是完整的流程。
很多業界的朋友出來創業，有一個執念。
就是希望自己規劃的產品，有一條平整的道路，它們深信經過仔細的規劃，完美的執行，產品就會取得很大的成功。
而這種因果邏輯來自於：
業界是廝殺很殘酷。不是每個人都有機會贏。你一開始這場遊戲，就會有人出來跟你競爭。一旦競爭開始，雙方會員就會開始比較。然後開始遷移。
業績掉了以後。內部檢討通常會歸因爲：「自己的服務漏了這個也漏了那個，所以才輸對方」。
接下來繼續的推對，再深一層的探討就會演變成「一定是當初規劃沒有完美。然後因爲規劃沒有完美，所以消費者因爲這樣選擇了別人。所以導致我們收入降低。別人有我們的這些功能，一定是我們當時沒有想到」
所以，當自己一有機會創業，能夠 100% 掌控規劃打造產品的時候，就想要一切規劃的更加完美。去彌補「以前所犯下的過錯」。
這也是很典型的「倒果爲因」。
我必須要說：「如果你的服務沒有人要用。不是功能寫的不完善，就單純是沒有人要用而已。」
沒有人要用的原因，有幾個：
- 你可能切不到痛點
- 你隔壁的雖然bug很多，但是你的產品沒有比他的好十倍。人家沒有動機，要來轉換來你這裏玩。所以不是code沒規劃完善的問題。是其他的問題。
創業最貴的其實就是時間。如果創業者執著將時間花在寫出完整的規格，那麼錯過風口基本上是必然的事。
要精確比擬的話，我覺得創業很像是規劃出門旅遊。
出發前覺得前面道路是一直線，然後估計旅程大概是50天，就可以走到目的地。一開始你在路上走，規劃旅程中途要買什麼，住什麼旅館，然後訂什麼餐廳。一開始規劃的好好的，甚至出發前也花了很多時間去做裝備補給，以及規劃路線圖。
但真正上路完全不一樣，你會發現什麼事情都在出包，好像永遠走不到你的目的地，甚至中間就被人家搶劫，還被打的要死。
如果這當中，你一直要維持當初做的計畫，這段旅程，很可能會搞得你極其痛苦。
我在第二次創業以後，意識到一件事：創業根本不是能規劃的事情。
創業，要做的其實只有儘量避免在路途當中別死掉就好了。
最後到不到目的地，甚至都不是重點，重點是有沒有 enjoy 這個過程，在這當中又學習到了什麼。
- 很多人一開始Over Engineering，花太多準備的功夫，然後還沒走到中間，錢就燒完了
- 或花了太久的時間，只在一個小鎮打轉
- 或是出發前，沒有對一些意外做基礎的小保險，路上踢到小坑就摔死了
創業這條路上，是充滿著 workaround 的。
我在風口上創業時，不諱言的在初期，都用一些很dirty的workaround，去繞過眼前的難題。因爲那是瞬時之間，我們能想到的最佳解。
比如說 ico.info 一上線就遇到萬人在線的規模了，但是技術跟不上。資料庫沒辦法做到萬人在線。怎麼辦？
我就想辦法在流程上做了一些小障礙，比如說在搶投過程加一個 captcha。這就不需要實際做到萬人的壓力同時在同一個頁面，這樣做法就變成分批幾千人在線那就好了。這也是一個解法。
創業路上，滿滿都是這種高難度問題。但現有資源跟不上，唯一的解法只有不惜一切用奇怪的低科技或者是暴力解決。
就像前面有石頭擋路，正常神智的程序員會做的就是：大家圍著石頭，研討用切割機，算力學原理，以損傷周遭最低程度之類的方式處理搬走這顆石頭。想出最完美的解決方法。
你知道創業家會怎麼做嗎？
- 不要走這條路，繞過去
- 如果真要走這條路，用炸彈把石頭炸掉，走過去
- 或者是去弄一個彈簧牀，跳過去
創業家的的作法，簡單粗暴，就是 GET SHIT DONE。
甚至極端一點，我認爲在創業路上，任何一個狀況，只要花上超過三天的方法去解決，就是蠢方法。
另外一個反常識是：多數創業當中遇到的挑戰，是沒有辦法預先規劃解決的。
沒辦法規劃一個月以後的事情，只能規劃三天之內的事情。
在 OTCBTC 成長最驚險的生死關頭，在於我們創業五天面臨沒有明顯的大增長，而且強敵也上線了類似的服務。眼看著就要被幹死了？
那麼最後我是如何突圍的。我當時想出了一個千一活動：
這個千一活動細節是這樣的。Localbitcoins 的手續費是千十，當時我們爲了搶市，所以打出了一個手續費暫時千一活動。千一手續費這個設計目的在於，很多微信羣的羣主，手續費是千五。所以千一能夠把所有競爭者掃平。而比千一有競爭力的手續只能是免費。但免費對於千一來說，並沒有足夠的比較殺傷能力。
但是會員試用了以後，比較有疑慮的部分是想知道「暫時千一」的活動會到什麼時候。
所以當時我做了一個極度大膽的舉措。我寫公告推出了一個「永久千一」活動。我宣佈站上會員，即日起只要成交超過 2000 塊錢的訂單，超過五筆。就送一個千一永久資格，限量 200 名。
當時我的同事很緊張的阻止我，他的擔憂是：
- 永久千一會不會太過份。會不會利潤過低，害我們做不下去
- 就算要做。也不能只寫一個公告吧，讓使用者申請的申請後臺我們也沒寫阿？
我跟他說，我不做這件事情，明天就沒人玩死掉了，你還問我他媽code在哪裏。
我把這個公告貼出去的幾個小時，這個活動在幣圈就viral了。大家開始狂刷千一資格。每個幣圈微信羣都知道這個消息，大家都在狂下單。（本書後續章節會拆解千一活動更精妙之處）
瞬間我們就打開知名度了。
而這個兌換系統的程式代碼，在公告後的兩天我才寫出來，但是效果已經達到了。
重點在於，當時那個生死存亡之際，沒人用你的服務，留不住目標用戶的注意力，瞬間就被競爭對手勢頭蓋掉了。沒人玩這個服務，代碼再好也白搭。重點真的不在於代碼，而在於你怎麼想出辦法去解決眼前的難題。
有些程序員很不習慣，創業公司爲什麼做產品是沒有spec的，反倒充滿了workaround以及政治不正確的作法，覺得很不正規。
但是這纔是創業公司，每天做產品真正殘酷面對的事情。
創業公司所有遇到的挑戰都是都是動態生成的，動態生成的挑戰，是沒辦法預先規劃解法的。
我現在比較幸運，團隊成員都比較沒有這些包袱。這當中很大的原因是因爲，很多人都是我當時Rails補習班的學生，後來來跟我一起做公司的，因爲它們之前不是職業程序員，所以並沒有那麼多包袱需要忘掉。
我開始創業後，我自己最大的誤區是以爲創業就可以賺到很多錢。
許多創業員創業的初衷其實很可笑「我一身好本領，老闆當初給我的薪水低估我的身價」。憑什麼老闆賺走那麼多的錢，我自己功勞那麼大，但是我並沒有得到很合理的報酬。
甚至很多程序員，看到自己老闆賺那麼多錢，覺得心理不平衡。覺得老闆又不會寫代碼，老闆能夠賺很多錢，還不是我幫他寫的代碼可以讓他把產品賣出那麼多份。
創業應該沒那麼難，反正在寫代碼時已經知道老闆的 Knowhow，只要出去開一個 me too，去跟他做一樣的事情，甚至做得更好，就可以賺比老闆更多的錢。
這是多數程序員創業時，比較天真的想法。
下一個衍生出來錯誤的決策是這樣的：
創業一開始，不論是誰，都需要資本啓動。但是創業一開始，我自己並沒有錢，身上有的只是技術。所以一開始我可以先幫別人寫程式代工接案，賺第一桶金。邊接案邊做產品。
這是創業我走過最冤枉的一條路。
所以每當程序員要創業，跟我請教創業相關議題。我都會勸他們：別接案了。想創業去跟銀行借一筆錢，直接去做你想要的產品，別繞一大圈路。
爲了「想創業」而去創業。是一個完全錯誤的開始。
怎麼說呢？
沒有錢也不知道怎麼開始冷啓動，說難聽一點，這個問題根源在於你自己不知道「如何創造價值」（諷刺吧，想創業卻不知到如何創造價值）。所以想到的方法只能賣自己的技術，幫人做外包。
但是做外包這件事最坑的在於，外包的本質不是在「賣技術」，而是在「賣時間」。接案這件事的本質，就是「你的時間只能賣一遍」。
而且接案是一個挺痛苦的行業。接案的壞處在於：
- 接案的時候，就算你的產出是100分，業主也只會覺得這些產出是60分。做120分，業主覺得這剛好在他心目中也頂多是80分而已。但是，如果你做60分80分，他會覺得是20分。
- 而且接案有淡季，淡季有旺季。而那員工看你旺季很賺錢，但他卻不知道淡季不賺錢。Billing hour 是很容易被知道價錢的，他覺得老闆在billing hour 上賺那麼多錢，卻怎麼都沒有分員工。
- 而且接案公司員工，也不喜歡自己反覆在做不同的新產品，他會覺得沒有跟着產品共同成長累積。所以這些剛訓練好的員工，在剛訓練好能夠獨當一面的時候就走了，流失率很大。
所以接案這個行業，本質上等於
- 只是在賣時間
- 幫人家在代訓程序員，自己公司並沒有累積資產
我後來認爲，與其去接案得到這樣的結局，真的還不如繼續上班。
行業有一個理論：就是如果創業沒有賺超過以前薪資的三倍，根本是賠錢的一件事情。所以我建議適合創業的狀態，是你知道自己確定能做出什麼有價值的產品，再出來開始。
萬一沒有錢開始第一筆資金又沒人投資你，那就去跟銀行借錢。
接案這個方向是下下之選。
因爲接案所賺到的金錢，跟剩下來時間是不夠用來開發產品的。這樣緊迫的資源，會產出一個不怎麼樣的產品，同時產品開發的時間，也會拉的過長。等你做出來之後，風口也過了。
這是我認爲這是最不值得的一條路，所以我完全不會建議程序員創業一開始去去接案。
創業怎麼樣挑IDEA？
我見到一些人，對於風口上興起的企業，挺瞧不起的。
「風口上的豬，有什麼牛逼的，還不是幸運遇到風口而已？」我以前也有這種偏激的想法。特別是那些幸運兒，說實在，我們旁人在旁邊，看這些企業，也覺得實力也不怎麼樣。憑什麼他能夠站上去？
但後來我真的站過幾次風口之後，我才發現風口上能飛的真不是豬，都是神人。
因爲風口裏面被幹死的人，真是多到沒辦法想像。在風口裏面，勉強站穩都很困難了。更何況是能穩穩飛上去的人。
我幾次比較成功的創業，都是飛在風口上。我第一次在風口中央的時候進去。第二個在風口前，第三個我自己在風口還沒打開的時候，嗅到那個壓力很大，趕緊衝上去。
有的朋友很羨慕我，覺得我老是想到正確的 IDEA，一炮而紅。老實說，真不是這樣的...
我在這裏舉個真實發生的有趣故事。大概三
四年前，我還在苦苦掙扎時，我遇到一個很有錢的創業家，請我幫他找程序員。我說我挺羨慕你這個生意挺 niche 挺獨賺的。你怎麼會想到做這個IDEA？這想法真是太聰明瞭，一般人都沒有想過。
沒想到，他竟然跟我抱怨：「你知道我根本不想做這個，我根本不喜歡這行業，做這個行業這不是我熱愛的行業，當初只是不小心踏中風口而已。雖然這很賺錢。我做這個行業，很糾結，也很累。你不要以爲我現在很有錢，其實他媽超痛苦。我一天到晚想把這生意賣了去做我想要做的行業」。
我聽了就覺得，這是幹話。不跟我講就算了，你還跟我說你不喜歡這門生意，只是無心插柳。
但是，我後來跟一些成功的創業家朋友聊天，他們也一樣都跟我講同樣的垃圾話。我覺得它們很小氣。
但是後來其他創業家來請教我，爲什麼我一天到晚可以想到風口上的生意點子，還賺到不少錢。然後我就跟他們分享我的「肺腑之言」，它們的反應卻聽起來像我當初聽到垃圾化一樣。。。。。。。。哈哈哈哈哈哈哈哈
要真說起來，我人生的夢想是去作一個，SaaS服務。像是slack那樣的軟件服務，正向擴展賺大錢。怎麼可能是去教書？
你以爲當初去教書做教育事業是我希望做的事嗎？（特別是程序員去當老師還會被同業看不起，認爲是混不下去了纔會去教書）
或者是去做比特幣交易所，是我從小的願望嗎？怎麼可能！
這些行業，完全不是當初我想做的事業。我只是在時機到的時候，發現有需要，站在那裏做出來。然後就爆紅了，現在搞到我的生命裏面就只有虛擬幣，我也挺痛苦的。
我是一個教育家做幣所，這種內心太掙扎了。
第一次創業的程序員，常好奇要怎麼找到創業的 IDEA?
我以前也問過硅谷的那些創業家，它們的回答是，要做你熱愛的事情，去解決領域裏面沒人解決的事。我在 2012 年前，聽到這種回答，也是嗤之以鼻。因爲那時候我的生命裏面，只有寫代碼。
你知道熱愛寫代碼的程序員，創業會寫什麼題目嗎？
「項目管理軟件」，所以市面上到處都是一堆「項目管理軟件」（程序員最痛苦的是開發流程）。
你不要以爲我沒開發過這種產品，我真的有寫一個，但是最後沒上線。
我之前當程序員的時候，是沒有人生的。沒有人生怎麼辦？
後續當然是尋找我的人生。
我後來真的開始賺錢的是從開Rails補習班開始。這是我另外一段人生的開始。我因爲很會寫代碼，所以我有辦法教人寫代碼，後來我甚至擅長教人寫代碼。我對教學開始有熱誠之後，就花了很多時間改善教學效率，並且有辦法做到大規模水平擴展。
這就是我新的人生。
我回想從前，難怪以前我做什麼都不是很成功。因爲根本沒有人生啊。
程序員的世界是一個很單一的世界，我以前思考很單一，很單純，甚至很薄弱，很狹隘，很可笑。就像現在有時候我也會覺得程序員視角很狹隘一樣。因爲我以前也有過那個時祺。
但是如果在這個世界上，要真正能夠賺到錢，唯一的途徑就是貢獻自己的社會價值。這件事得擁抱現實，擁抱人生纔有辦法做到。
以前程序員在公司，都覺得銷售部門提的需求都骯髒，客戶服務部門提的需求都很麻煩。認爲這些提需求的都是奧客，我們的服務要「作給欣賞我們價值的用戶」。
如果創業是這種思維的話，做出來的產品沒有人用是很正常的。
因爲程序員的價值觀與正常人的人生其實是不太一樣的。真實的世界是「很髒的」。
我後來會找到創業的方向，賺錢的方向，也是因爲我重新找到了人生。
我後來爲什麼去做比特幣交易所？因爲我業餘時間，看到別人在玩虛擬貨幣很有趣，也賺到錢。看到別人買了幣賺了錢，所以我也跟著買幣，後來玩很兇，每天都要看行情。最後開始寫搬磚軟件，並且投ICO。所以最後我寫了一個投ICO Service。
後來買了一大堆幣，想要把虛擬貨幣換成法幣，有這樣的需求，又不信任別人的服務。所以最後就寫了 OTCBTC，後來就因此賺到了錢。這就是我新的人生，意外但又不意外。
這一切都不是規劃出來的。也不是看人做什麼所以自己去做什麼。我創業做這些服務，是想要自己在當下解決那個自己覺得很重要的問題。
如果你創業的策略是，看別人做什麼賺了大錢，然後想辦法複製對方。絕大多數的情況下，這個策略是沒有用的。程序員雖然具備自動化的技術，但創業是靠生意裏面的許多細節。只靠代碼去創業，是不可能成功的。
創業能夠賺得的錢的題目，是社會上壓力很大的未被解決的問題。
- 而「風口」就是指就是壓力很大的領域
- 壓力很大是指「需求存在」但「社會基礎建設跟不上」。
這個議題引領出，下個我想要分享的領域：天使投資。
創業取得第一筆啓動資金的方式有很多種。
其中有一種類型是投資。
一般典型的投資，不僅要求創業者說明獲利方式，也會對企業做盡職調查。有些投資人，甚至希望參與公司運營。
所以有些創業者，比較想取得所謂「天使投資人」的資金，不希望公司經營太過被幹涉。
一般人對於「天使投資」的粗淺認知是這樣的：
- 看到 idea 以及人對了，就爽快投資，也不會做太複雜的調查
- 不干涉公司運營
「天使投資」本質上應該正名爲「早期項目投資」。
冠以「天使」之名，讓很多創業者以爲「天使投資」是一種「善心資助」年輕人創業的感覺。也因爲這個錯誤的感覺，所以一些碰壁的創業者，會將融資希望放在「天使投資人」身上，希望這類型的投資者能夠「資助」他的夢想。
我後來上了 YC 創業公司投資者學校後，才發現「天使投資」這個詞誤會可大了。
所謂「天使投資」並不是善心投資。而只是投資策略的一種，本質上就是「早期項目投資」。
早期項目投資的策略是這樣的：假設這位創投，手上有一千萬，一次投一百間，每間投資十萬，這當中有一百間公司，有一間公司這筆投資賺了一億，也就是中了一千倍。那麼這一千萬的報酬率，最後就是賺 10 倍。
雖然有 99 間公司失敗了，但這是無所謂的。因爲新創公司是非常容易失敗的，有人統計過，五年之內，只有 1% 的創業公司能夠存活下來。
所以早期投資人要增加勝率的方式，就是一次性投資很多間公司，以增加投資成功的機率。
因爲在這個階段，公司實在太容易死了，如果增加太多 micro manage，成功機率未必也會顯著的上升。
所以你可以把早期投資，這個領域的投資策略想像成「俄羅斯輪盤」。而這當中要提高勝率的方式，很簡單。就是把每格都買滿。這樣勝率就會變得超級高了！
所以爲什麼天使投資偏愛喜歡投風口項目？因爲風口是一個明顯的上升趨勢阿！
天使投資人的投資策略就是直接在風口上狂投100間，只要一間中1000倍。整體投資就有10倍回收。
A,B,C,D 輪，只是倍數大小的不同。如果你想夠承擔更小的風險，就投越後面的輪。當然，後面公司生存下來的機率越大，但是投資報酬率也相對比較低。
不過很多創業者真的誤解"天使投資"的投資策略，以爲天使投資是「慈善事業」。
做了一個不屬於風口的產品，也沒有多少人想用，埋怨沒有人欣賞這個產品，所以希望找到天使投資繼續支持發展這樣的產品。天使投資人 Gary Tang 形容過這樣的產品，他認爲這種產品說難聽一點不是產品，而是「藝術品」。
「藝術品」沒有不好，但藝術品是作給自己欣賞的東西。做產品是要給人用的，如果你的東西沒有人用，問題可能出自於你把這個作品當作是藝術品的心態。
天使投資的「天使」不是「天使」。天使投資只是一種投資的策略。VC 的世界也是人吃人的。很多創業者誤會了這一點。
如果創業者，能夠從投資者的邏輯角度去重看自己的作品，會看到很不一樣的世界。YC 有一門課，叫做 YC 創業公司投資者學校。非常推薦大家去看。從投資者的邏輯倒推回去看，你反而會知道要做什麼，纔會有人投資，才容易水平擴展。
以前在這個網路創業世界，因爲基礎建設不太足夠，沒有那麼多人競爭。程序員會寫代碼會寫出產品，可能就是成功的一半。但問題是現在程序開發那麼普及了，做網站或 App 成本也變得很低。整個資本市場也變的比較成熟。如果大家都在拿資本玩得時候，你沒有拿到資本用錢完，那麼成功概率可能就會小一些。
這就是爲什麼我會勸朋友，創業儘量選風口題目。
我當年做 Logdown 時，就是陷入了這樣的經典迷思。
最近也有人找我做天使投資。是一個還不錯的題目，但我稍微看了一下，我就覺得這個題目，要做臺灣本地市場是可以，但是最好是做歐美市場，歐美市場大，也沒人做這個題目。但是對方要堅持在臺灣站穩，然後纔去挑戰世界賽。
我內心就 pass 這個 idea 了。因爲世界發展速度這麼快，這個 idea，雖然有一點技術門檻，但也沒有十足的護城河，在臺灣可能一有traction就被國外其他人抄走了。再來這個產品完全是可以在歐美市場做水平擴展。
天使投資的題目應該是說賭「不是零就是一千」，如果創業者目標只有三。這是天使投資，我沒有興趣花那麼大的風險，然後去賭投資報酬率只有三。如果只有三，資本要出場，非常困難。
所以我完全搞不懂這是怎麼樣的融資策略，最後也沒有投這個項目。
我覺得創業者，如果創業想募資，得先搞清楚募資界的生態鏈，不然很容易表錯情，很容易一直碰壁或陷在奇怪的迴圈裏。
2013 時我寫過一個 Logdown 服務，在2013年的時候很轟動。產品品質很高，但是付費用戶沒有想像中的多，也是無法擴展增長。爲什麼呢？
Logdown 一個月收取 5 美金月租，很多開發者嫌貴。它們的確有寫技術博客的需求，但是大家不願意付錢，寧用自己架 server。所以我寫了一個大家公認很好的服務，也解決了寫作上的問題，但沒有人願意付費。
再來，大家多久一次寫博客？勤勞一點的一個月四次。懶惰的人，兩三個月一次。所以它們當然會覺得 5USD 很貴。特別是程序員這個羣體，想寫軟件賺大衆的錢，但卻最不甘願付軟件的費用給其他開發者。
所以這個產品不但不是剛需，頻次也低，目標族羣甚至不大。這就是爲什麼很多博客 service，始終難以維持開銷的原因。
我在開發這個產品時，已經小有名氣了。所以我做什麼都有流量。但是有流量並不代表是風口。很可能只是一個假信號。
一個好產品，但是沒有分銷能力，也沒有現金流。通常看起來就是隻有程序員會做出這樣類型的產品 XD
程序員常常認爲做出一個好產品，這就是一切了，好產品就會自動增長。
Blitzscaling 閃電式擴張，特別指出了這樣的通病。這本書的觀點認爲要創業成功，不止要做一個能夠 product market fit的產品，更是要考慮到這個產品怎麼樣做 distribution。且打的市場有多大？第三個還要看持續運營的能力，毛利頻次這些要夠高。
我犯的這個錯，正是程序員會犯的經典錯誤。眼睛只叮著產品。
在這一章裏面，我一直批判程序員。但其實我並不在批判這個羣體，而是批判過去的自己。過去自己把這一切都想得太理所當然了。我在網上發表過很多創業的文章，與最佳實踐。有些人在讀這些文章時，覺得我寫的某些文章口氣比較狂，好像在酸別人。但真不是。
那些都是我踩過的坑，我寫的每一個經驗，我自己都踩過，所以纔會寫上去，勸別人不要踩。
我真的每一個都踩過。很多人覺得我創業以來，真是太幸運了。每一步都作對。我說不是這樣，舉個例子來說好了，假設一個遊戲，你玩了一百遍，那是不是在某些關卡，你閉著眼睛都會打？大家都會死的地方，我已經不可能死了。
創業也是一樣，我只是在某些關卡玩過太多遍了。前一陣子我玩 Two Points Hospital，這個遊戲我玩了 30 遍。玩到最後醫院怎麼蓋怎麼賺錢。我不是醫院經營大神，我只是玩了 30 遍。
所以真不是嘲笑或不屑，而是我前曾經死在這個關卡。我只是好心說，在這個關卡，用這樣的方式玩，死亡機率接近 100%。很可惜，我收到的程序員給我回應都是 "你懂什麼，你可能不懂寫 code 纔會這樣說吧"。
所以我只好 "算了，你想怎麼樣就怎麼樣"。
要不要寫這個題目，我一直很掙扎，很怕寫了這個題目，得罪很多人。
歐美的團隊很強調招人必須看重價值觀，認爲價值觀遠勝過一切，寧願招人慢也不要招到價值觀不一致的人。
以前我還在網路公司時，技術團隊在招人，通常看中的是這個人的技術棧。僱用工程師，會覺得有能力進來能夠幫忙寫代碼就好。或者是看到強者想換工作，第一時間趕快攔截進來。
但是不管價值觀，有一個很嚴重的問題。完全不管價值觀前提下，招進來的程序員，在與團隊磨合上會有很多問題。要麼協做時他一直幹隊友，然後你一直幹他。
要不然就是打緊密的攻城戰時，指揮官說往北方殺過去，但是他卻跑到南邊龜起來，還說是幫大隊防禦後方。
另外一個狀況，是團隊裏面有人的工種是狙擊手，但是他卻喜歡一個人拿狙擊槍跑到前面，當衝鋒槍在玩，把怪引過來。
我以前在創業時，真的遇到過一大堆這種人，頭痛的要死。後來我對這件事情非常火大，在中國創業時，我新的團隊成員，背景都是全棧營同學。全棧營同學，價值觀都是一致的。而且這次創業招人，我們刻意招人放慢角度。
這次這個隊伍戰力輸出就極強，大家都知道怎麼樣補位，互相幫忙。甚至小組組長不在時，他的組員也能夠輸出同樣的品質。
但我在後來回臺灣開分公司的時候，又犯了一個錯誤。這個辦公室裏面絕大多數都是客服。但我認爲招客服不需要那麼嚴謹，價值觀也沒關係。結果到最後，這樣的策略製造了非常多的麻煩，客服團隊發生了一堆互相扯後腿的問題。
我才意識到價值觀，是完全是不能妥協的。
「價值觀」的意思是：你爲什麼想要在這間公司，在這間公司裏面你做人處事的基本原則，你平時自己做人處事的原則。你平時遇到緊急的狀況，你會做什麼樣的決斷。
當一個團隊裏面，同事價值觀不相容的時候就會產生衝突與矛盾。小則做事不協調，大則整天內鬥，甚至爲了傷害同事不惜搞爛公司。所以這件事情是完全不能妥協的。
價值觀這件事真的是最重要的。人都是會成長的，也許同事現在做事情比較慢，但價值觀與我們一樣，但他們會成長。坦白說像我的同事，當年的全棧營的同學，現在有人做產品的功力都超級牛逼的，UI/UX做的超級好，風控超級仔細的，文案寫得比我好，tmd每個都比我強。
你很難想像這羣人，兩年前沒有一個人會寫代碼，更何況做產品！
我們中國辦公室基本上是沒內鬥的。經歷過幾次很不一樣的團隊，我才發現價值觀一致，在開發產品時，速度纔會夠快。
難怪硅谷的CS138B創業課，有一課講公司文化，講者反覆強調價值觀是完全無法妥協的。
在後續的章節。我會提到 User Story 與敏捷開發這個概念。
在傳統產品開發流程，許多團隊是使用瀑布式開發。瀑布式開發的意思就是先詳盡的寫好規格，再進行開發。但是這樣的開發流程很耗時間，也容易做出與現實需求差異很遠的產品。
所以程序員界對這件事情，進行了改革。倡導我們應該使用敏捷開發，捨棄完整的規格，並用輕便的用戶故事 User Story 替代。大幅提升開發效率。
但是使用 User Story 就出現了另外一個問題，就是User Story通常是程序員自己決定的，程序員有時候就會自high，然後就寫了一大堆User Story，但是卻不是銷售部需要的，而是程序員覺得自己需要的，還很開心的執行下去。
結果到最後，原先銷售部門或者是客服部門需要的東西，被認爲「不重要」而沒被實做。
另外使用者故事 User Story，是有評級的，叫MoSCoW method。有 Must Have,Should Have, Could Have, Won't have。要怎麼樣安排進開發流程決定優先級呢？
有另外一套敏捷框架 Scrum 是這麼決定的，用點數撲克牌，團隊成員用點數撲克牌大家比較工時權重分數計算決定。
這不是很荒謬嗎？一個功能應不應該排入優先級，應該是市場需求決定吧。怎麼會是程序員用撲克牌比較工時呢？
寫到這裏，我是真的挺害怕得罪敏捷派教徒的。但是這個方法真的是不實際阿！
我以前還剛接觸到敏捷時，覺得 SCRUM 這個框架也挺牛逼的，但實在覺得這個方式怪怪的。後來實際創業，才發現這種開發方法，跟溫室真空開發，實在沒兩樣。
再來，Growth Hack 的興起，讓一些程序員認爲在網站 / App 裏面埋點，就能做增長。埋點用數據輔助行銷決策，的確是這套方法論的基礎。
但是不是不聽使用者 feedback，光用測量以及改 UI 介面，就能讓營業額上升。最終是有沒有打對市場，打對痛點。
但是程序員會非常執着的，堅持不去直接終端人羣，忽略客服部回傳的意見。堅持數據實驗救國。我個人覺得這是一個很不負責任的作法。
我們公司比較奇葩，我們幣所每個程序員都懂業務都懂炒幣，其實真的這個樣子才能寫出最市場，上面最貼近使用者心態的這些功能。做功能應該是按照user的feedback，然後數據只是幫你找轉化率在某一程度莫名其妙直接drop掉。
但是沒有traction不應該這樣解。traction不應該是靠data analysis 去找。
很多程序員覺得 Growth Hack 治百病，他想藉由埋點學 Growth Hack 技術，順便幫公司解業績上的問題。這真是異想天開，增長的重點不在於技術埋點，根本上應該放在distribution策略，這也是下一段我會談的主題。
這是我這次做產品的一個經典錯誤。BlitzScaling 提出了一點，Paul Graham 曾經寫過一個經典的 essay，叫 Do things don't scale。這讓很多人對創業做產品有錯誤印象。
Do things don't scale 的步驟是這樣的：
- Step 1: Do things that don't scale.
- Step 2: Achieve scale.
- Step 3: Do things that scale.
但 BlitzScaling 指出，現在的戰爭應該是得這樣打的
- Step 1: Do things that don't scale.
- Step 2: Reach the next stage of blitzscaling.
- Step 3: Figure out how to do one set of things that scale, while somehow also finding a way to do a completely different set of things that don't scale.
- Step 4: Reach the next stage of blitzscaling.
- Step 5: Repeat over and over until you reach complete market dominance.
因爲 Do Thins Don't scale 這個理論太經典。導致硅谷一大堆創業公司，把精力花在打磨產品之上，認爲把產品打磨的足夠好，就能到達擴展階段。
我在閱讀 Blitzscaling 的時候就意識到，現在戰爭的速度與血腥速度，時代已經不一樣了。
現在有資本的團隊，是一邊 do things don't scale，一邊另外開一個團隊在水平擴張。想辦法搶佔渠道。我在做 OTCBTC 的時候，本來佔著前期優勢，打下大半江山。但是我們的僱人速度實在不夠快，mobile 版本推出過慢。競爭對手火幣搶先開發出手機端並迅速迭代。本來我們靠著 Web 端的有機病毒式增長已經取得的市場，又再度被趕超。
硅谷最新的 Growth Hack，現在已經不談 AARRR，而在講如何搭建 Product 上的 Viral Loop。如何利用 Viral Loop 快速佔滿渠道。
這對我來說真是很大的教訓。
程序員超級討厭一件事，就是先寫一套代碼勉強上線。然後把它扔了，再寫一套新的服務取代掉它。然後再把它扔了，再重複寫一套代碼取代掉它。它們一開始就想把終局產品寫到位。
但這是創業最常發生的狀況。你沒辦法一次寫到位。甚至 pre-architecture 還會害死自己。
我們在做 OTCBTC 的時候，其實一直內部在革自己的命，很多系統都是一再重寫 reinvent 的。我曾經以前很羨慕別人的服務有強大完整的風控系統。以爲別人是找了風控大師，開發出來的。
自己在開發風控系統的時候，才發現這是血淚堆出來系統規則。一條一條暴力補上去。再一次性的重構成一個架構穩固的風控系統。
我們也不是沒有走過彎路，當我們剛開發 OTCBTC 時，上線開發花了 35 天，當中我們就花了 7 天打磨申訴系統，因爲我們認爲這是最可能出做的問題。結果真實上線後，發現當初規劃的狀況，跟真實發生的狀況， 100% 完完全全不一樣。結果那套代碼，得直接作廢。
有程序員朋友問過我怎麼規劃 1.1 版本的產品。我回答如果產品有「1.1」版，還需要規劃，那這個產品基本上沒有量。因爲能夠做的起來的產品版號是 1.0，2.0，4.0 這樣大躍進的跳。
每個禮拜開發的版號不用規劃，真實的客戶 feedback 會佔滿接下來你開發的目標，活的 startup 真實的生活就是這樣的。每天有做不完的事，滅不完的火。不是哪個 startup 管理不好，所以很多火。
而是所有 startup 本身都是著火的公司。創業團隊的心力重點，在於滅掉眼前會讓公司當場死亡的大火。如果一個成員抱怨他在的創業公司一天到晚都在失火，沒有制度。真的不是這間公司不好，而是他不應該待在這個生態裏面。他應該待在制度成熟穩定不需要變化的大公司裏，而不是出現在創業公司裏。所謂的火箭，是真的都是火。而不是冷氣溫度事宜的飛機頭等艙。
我2012年創業，在創業之前，我花了四年的時間，把技術練得頂尖。後面又我花了六年的時間，逐漸把我學過的engineering知識都忘掉。所以今天才可以站在這裏。
我這六年來走過了無數冤枉路，真的每一條都付上大量學費。這當中每一條都是，我在當工程師的時候覺得理所當然的決策，最佳實踐。然而它們在創業這條路上都是錯的。
不把這些忘掉，就沒辦法在新的路上成長。
這是爲什麼這一章我會花了這麼大的篇幅，不談方法論而寫了一萬多字回憶錄的原因。
我希望這一章可以讓大家知道，不止方法論重要，忘掉過去自己的一切，更重要。