在这一章。我们先不谈创业方法。我想改谈一些创业路上我所走过的坑。
我认为，在创业前改变一些视角，提升创业成功的机率，远比学习方法论更重要。
一路以来，在创业路上走过不少坑，可以说把程序员创业会跳过的坑都跳遍了。
这些坑，与其说是坑。还不如说是创业市场上的反常识，创业市场是一个很反常理的领域，绝大多数你在公司当高管或资深程序员时，所学到的最佳实践，在创业时反而没有效，很多时候甚至还会害死你。
我希望分享这些创业路上的故事，能够为大家带来一些启发。
我在创业前，是一个顶尖的程序员。
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知识都忘掉。所以今天才可以站在这里。
我这六年来走过了无数冤枉路，真的每一条都付上大量学费。这当中每一条都是，我在当工程师的时候觉得理所当然的决策，最佳实践。然而它们在创业这条路上都是错的。
不把这些忘掉，就没办法在新的路上成长。
这是为什么这一章我会花了这么大的篇幅，不谈方法论而写了一万多字回忆录的原因。
我希望这一章可以让大家知道，不止方法论重要，忘掉过去自己的一切，更重要。