04.md

第四章 - 程序员 创业遇到的九九个坑

这一章不教学。我想来谈一些过去创业的故事。

网路上很多人都以为我人生太成功，走到现在不曾失败过。

但其实一路上来，我走了非常多的冤枉路。这一章，我想要把这个题目，命名为 程序员 创业遇到的冤枉路 -- 我所踩过的 99 个坑。

只具备程序员思维会在创业路上害惨你

我在创业前，是一个顶尖的程序员。2012 年到这本书写作（2018）的时候，过了 6 年。这六年，我觉得基本上是一个unlearn 的过程。什么叫 unlearn？就是所有我在程序员世界学的best practice，在这六年以来都崩解了。

我曾经信奉的最高信仰教条，在我创业的时候全部都崩解了。

这当中最矛盾冲突的是，我以前的角色是程序员大神。而当这些秩序陆续在我面前崩解，我意识到我以前信奉的都是错的之后，再跟我后来创业公司里面的 程序员 说这些事的时候，他们「不相信」。

比如我跟他们说，「创业项目不需要太注重code的质量，赶快他妈的先上线才是王道」。他们就会觉得我是不是不会写 code，才会讲这种反常识的话。

还有我可能会说创业刚开始就不需要注重扩展问题，code quality不重要。他们听到这些都很震惊。会纷纷怀疑我当年的功力是不是假的。

当然，我不是没能力。如果我没有能力的话，ico.info 与 OTCBTC 这两次风口闪电战，不可能打的这么成功。这两个产品都是瞬间上线，然后上线第一周就有非常大的在线压力与迭代压力。

所谓的「不需要注重扩展」，只是我的一个「选择」。

我觉得程序员创业最大的一个问题，就是他们本身会把之前上班的时候学到的best practice带到创业起步的观念里面。我认为这件事情是最恐怖的。

因为程序员，是一个特殊的工种，他本身出现的阶段，通常是公司已经「稳定」以后，才会被雇用进去。甚至它们的工作，就是被用来重构那些混乱的「生意逻辑」与「不堪用的代码」。

所以它们自然不知道「生意是怎么做起来的」，甚至还会认为「自己是救世主」，来拯救这一团混乱。

而会选择出去创业的程序员，通常背景会是「资深程序员」或者是「程序员大神」，到了这个级别，才会选择出来创业。

这个级别的人。甚至对于扩展这件事，甚至已经登峰造极了。

程序员这个工种。它们的工作职责是：

• 将重复的过程自动化
• 将系统优化再优化
• 让代码结构干净，可扩展

程序员的一切技能，都是朝这个方向不断的在打磨。

但这时候的公司阶段，通常处于有盈馀，公司并没有生死存亡的问题需要面对。所以程序员可以「好整以暇」的慢慢打磨产品。而做好这些扩展，重构，需要耗上大量时间。

但是创业从0到1的时候，时间资源是很贵的。如果你遇到一个风口，不在时间窗口上线，这场游戏就没有你的份了。而且创业的重点，在于你做出有没有价值的产品。至于产品内部的质量，那是以后有资源在追求的事。

对于大多数人（甚至是 100%）来说，有时候创业有点像是一场赌博，很可能你做的产品，只有你自己需要，但是别人可能没有需求。或者是你的产品，想要扩大给到很大的族群使用。但这件事情完全是碰运气。

如果一开始的初衷，就专注在于打造一个底层很棒很能扩展的牛逼产品。这有点像是一开始就 ALL IN 在一个很容易 GG 的选项。

而且，人有一个奇怪的倾向。就是倾向于相信自己一开始的决策是对的。所以你既然ALL IN了你的时间，花了两个月的时间写了 code。你就不太愿意相信当初的选择是错的，所以后续就会在错的选择决定上，一再迭代，拼命希望它是正确的。

所以我最常看到很多程序员创业失败，是因为他觉得自己做的产品这个很好，代码也写得很漂亮，当初也花了许多时间筹备，但反复迭代了六个月，最后还是起不来。

事实上反而是那些你觉得应该不太会写code的创业家，或是会写code，但是他觉得不需要写code的创业家，光是用Landing Page就赚到一大堆钱。

所以创业实际上是很反直觉的事。

因为因为你没有办法相信，自己练了多年的武功，在创业这个世界是没毛用的。

我第一次认知到这件事情时，打击很大。

因为我最初刚刚开始的时候，我想要创业，但我不会写代码。于是我就去写代码，练了多年以后，终于变成了高手。变成高手以后，终于出去创业了。但创业以后，却发现学了那么多年代码与架构，是一点毛用都没有的。所以我内心是很崩溃的。

创业开始接下来的六年，这当中，我基本上是一直试图在忘记我曾经学到的东西，那些东西会害死你。

第一误区：以为成功创业的代码，底层代码一定是得干净的。

Over Engineering，我觉得这个是会害程序员最惨的一个习惯。

如果你仔细观察，国外创业成功的Startup，YC 投资的那些 Startup。创办人都有一个特点，要么他不会写code，要么他只会写一点点code。

不过这个事实，害让程序员对它们感到嫉妒，感到很不公平。我是一个牛逼的程序员，我这么会写代码，理当应该创业比它们牛逼阿！

但事实真不是这样，真实世界是，你很难看到程序员代码高手，最后成为成功的创业家的。

这当中的差别，在于成功的创业家，内心根本没有「干净的代码架构」这个包袱。反而是看到强大的市场需求，卷起袖子马上就先干再说。

Github 的创办人，他们也承认它们创业一开始，他们里面之前没有Git的高手。是开始写了一阵子，才找Git高手进来。我认识Github里面的程序员，他说早期Github里面code也就是烂的要死。

大家觉得Github是程序员的神圣殿堂，程序员脑子里面的圣殿，但是早期里面的代码基本上也是惨不忍睹。

我创业前，待的硅谷创业公司，做外卖服务的。创办人一开始在创业的时候，也根本不会写代码，YC 投了它们，然后逼创办人去写代码。所以服务的 API 与后台，是创办人自己写的。

系统的代码是 Ruby on Rails。我当初刚进入公司，被雇用的职责主要是带领技术团队，扩展重构这个服务。但是我把代码拉下来，一看整个傻眼了。

为什么？

普通一个 Rails Controller，正常来说我们都会要求资浅程序员，在开发时，一个档案不得超过 200 行代码，否则我们身为架构师就会骂人的。但是这套代码，一个 Rails Controller，足足有一万多行。

所以我那个月的工作，就是把一支一万行的代码，分拆成 30 份，而且线上不能爆炸。我都要发疯了.....

一支一万行的代码，在一般正常程序员团对里，简直是不可想象的。所以当我们在重构时，一边重构就一边骂，为什么创办人都没规划就在乱写代码。根本都没想清楚，想到什么业务逻辑，就先加上去，代码像一沱屎一样。团队里面的每个程序员都在骂。

问题是我自己创业的时候，特别是那两个非常火爆的服务平台，那时候也是这样的状况，遇到什么就马上加什么。因为客户需求实在他妈太大了。几乎所有的东西，都只能先　workround。

所以很多程序员，会是这样想的。我创业一定要按部就班，一切规划完美，然后执行上线。而且之前我老板就是创业时乱加东西，后面很多要打掉重练。害得生意无法快速扩展。所以我自己创业，一定要吸收这样的教训。一开始就把代码写好。

我跟你说，这件事情是不可能存在的。如果这件事情存在并且成功。一定会有一个程序员，大写特写博客大肆炫耀，仔细记录自己如何完美规划，并且有效执行上线的。

但是一直以来世界上没有出现这件事。这就表示仔细规划，完美执行上线这件事情是不存在的。

第二误区：预先解决不存在的问题，如水平扩展

程序员界现在很流行一个 buzzword，微服务 micro service。就是把每个功能，都拆成一个封装完备的小服务，由小服务堆积来成为大服务。

举例来说，我们 OTCBTC　虽然有很多服务，但它本身不是 micro service，而是一个monolith 服务，就是把所有服务都放在同一个 Rails App 里面。很多程序员面试时候，听了就觉得很震惊。

这种状况为什么不是拆 service，这样才能 scaling 阿。当我们回答创业没时间拆（那时候创业都刚半年，但生意已经很大）。我看到程序员的眼底，就露出「不屑」的神情（大概觉得我们团队没实力吧...）。

其实，我也挺不高兴的。这时我内心的 OS 是「你他妈懂什么...」

这件事情真的不是我傲慢。我真的没见过，有人创业一开始做微服务，用微服务搭建起来，大获成功的。

但我反倒是看过有人一开始创业，就采用微服务架构搭建，反而害死自己的。

之前 2016 年知识付费风口时，当时我在新生大学讲课的时候，它们的底层服务就是用 micro service 搭建的。micros service 一开始每个模组都拆得很小。

虽然很小，有办法维护，看起又轻便。（因为这个服务一开始就要承载几千人上线）

但其实这真是一种错觉。几十个小服务，叠在一起还是一个大服务。而且每个小服务，互相呼叫，都是有通讯上的 over head 的。所以一旦流量灌进来的时候，很难知道真正瓶颈在哪里。

也就是原本想要用这种技术pre-scale，反而被这种架构整死。

但如果刚开始直接用一个大的成熟框架开发，内部没有 overhead，反而搭建迭代速度很快。并且因为框架够成熟，又开源。反而容易 google 知道那边有可能瓶颈最大，问题好解决。或者是直接把机器换到最大台，直接收工。

但是如果这套服务，是由无数自己写的micro service组成。要 debug，因为这些的micro service，只是按照当初的假想去拆的，根本不是因为服务遇到了现实的瓶颈去分拆的。

这样的架构，反而活生生搞死自己。在知识付费的风口上，他们的服务就迟迟没有办法达到基本的可用度。（数千人收听直拨，总部能一直掉线没办法使用吧，老师也不敢用）

没有办法解决直播会断，甚至无法登入的这个问题，就基本上没有人用。这就是很致命的问题。

因为创业重点真的不在于底层架构如何设计。预先 pre-scale 反而变得无法除错。反而是之前快速写的一大包代码，要提升效能，是用钱能够解决的事情。一旦有了流量，产品有了市场认可，就能赚得到钱拉得到投资。到时候想请几个架构师，重构都行。

这是我看到，最经典的微服务害死自己的例子。

很多程序员都非常热衷于这种 Over Engineering。我必须再次强调，我个人不是反程序员，我自己以前是程序员，而且技术还相当高。我只是想说，我曾经被这些观念也害得要死。

所以我现在听到这些 buzzword 后，心里常觉得不以为然。很多事情，真的是得踩过坑的人，才知道痛。而多数程序员，并不知道这些观念对创业来说，都是很毒的毒药。

第三误区：以为创业产品，得经过完整规划流程上线，才会取得大成功

第三个冤枉路，就是完整的流程。

很多业界的朋友出来创业，有一个执念。就是希望自己规划的产品，有一条平整的道路，它们深信经过仔细的规划，完美的执行，产品就会取得很大的成功。

而这种因果逻辑来自于，业界是一个厮杀很残酷的业界。

你一开始这场游戏，就会有人出来跟你竞争。一旦竞争就会拿对方来比较，而经过比较之后，就会发现自己的服务漏了这个也漏了那个，所以才输对方。

按照这个逻辑，归出来的原因就会变成「一定是当初规划没有完美。然后因为规划没有完美，所以消费者因为这样选择了别人。所以导致我们收入降低。别人有我们的这些功能，一定是我们当时没有想到」

所以后续当自己有能力打造自己可以一手掌控的产品的时候，就想要一切规划的更加完美。去弥补「以前所犯下的过错」。

这其实是很典型的「倒果为因」。

如果你的服务没有人要用。不是功能写的不完善，就单纯是没有人要用而已。

没有人要用的原因，有几个：

1. 你可能切不到痛点
2. 你隔壁的虽然bug很多，但是你的产品没有比他的好十倍。人家没有动机，要来转换来你这里玩。所以不是code没规划完善的问题。是其他的问题。

创业最贵的其实就是时间，花大把时间把完整的spec写出来，时间也用光了。

我觉得创业很像是出门旅游。出发前觉得前面道路是一直线，然后估计旅程大概是50天，就可以走到目的地。一开始你在路上走，规划旅程中途要买什么，住什么旅馆，然后订什么餐厅。一开始规划的好好的，甚至出发前也花了很多时间去做装备补给，以及规划路线图。

但真正上路完全不一样，你会发现什么事情都在出包，你好像永远走不到你的目的地，甚至中间就被人家抢劫，还被打的要死。然后过程中一直要维持当初做的计画，这会很痛苦。

我后来意识到，创业根本不是能规划的事情。创业，就是你要保证你的路上，别死掉就好了。最后到不到目的地，甚至都不是重点，重点是有没有 enjoy　这个过程，在这当中又学习到了什么。

很多人一开始Over Engineering，花太多准备的功夫，然后还没走到中间，钱就烧完了。或花了太久的时间，只在一个小镇打转。或是出发前，没有做一些对于意外的预先小保险，然后就死掉了。

创业实质上是要做很多 workaround 的。我创业时都用一些很dirty的workaround，去绕过眼前的难题。因为那是瞬时之间，我们能想到的最佳解。比如说我们很快就遇到万人在线的规模了，但是资料库没办法做到万人在线怎么办。我就想办法在流程上做了一些小障碍，比如说在抢投过程加一个 captcha。

这就不需要实际做到万人的压力同时在同一个页面，这样做法就变成分批几千人在线那就好了。这也是一个解法。

创业路上，满满都是这种高难度问题，但现有资源，只能不惜一切用奇怪的低科技或者是暴力解决。就像前面有石头挡路，正常神智的程序员会做的就是说看着石头，研讨用切割机，算力学原理，以损伤周遭最低程度之类的方式处理搬走这颗石头。想出最完美的解决方法。

你知道创业家会怎么做吗？

1. 不要走这条路，绕过去
2. 如果真要走这条路，用炸弹把石头炸掉，走过去
3. 或者是去弄一个弹簧床，跳过去

重点不是方法是否完美。我认为在创业路上，任何一个状况，只要花你超过三天的方法，就是蠢方法。

创业当中遇到的挑战，是没有办法规划解决的。你没办法规划一个月以后的事情，只能规划三天之内的事情。

在 OTCBTC 成长最惊险的生死关头，在于我们创业五天面临没有明显的大增长，而且强敌也上线了类似的服务。我是如何突围的。

我当时想出了一个千一活动突围。

这个千一活动细节是这样的。Localbitcoins 的手续费是千十，当时我们为了抢市，所以打出了一个手续费暂时千一活动。千一手续费这个设计目的在于，很多微信群的群主，手续费是千五。所以千一能够把所有竞争者扫平。而比千一有竞争力的手续只能是免费。但免费对于千一来说，并没有足够的比较杀伤能力。

但是会员试用了以后，比较有疑虑的部分是想知道「暂时千一」的活动会到什么时候。

所以当时我做了一个极度大胆的举措。我写公告推出了一个「永久千一」活动。我宣布站上会员，即日起只要成交超过 2000 块钱的订单，超过五笔。就送一个千一永久资格，限量 200 名。

当时我的同事很紧张的阻止我，他的担忧是：

1. 永久千一会不会太过份。会不会利润过低，害我们做不下去
2. 就算要做。也不能只写一个公告吧，让使用者申请的申请后台我们也没写阿？

我跟他说，我不做这件事情，明天就没人玩死掉了，你还问我他妈code在哪里。

我把这个公告贴出去的几个小时，这个活动在币圈就viral了。大家开始狂刷千一资格。每个币圈微信群都知道这个消息，大家都在狂下单。（本书后续章节会拆解千一活动更精妙之处）

瞬间我们就打开知名度了。而这个兑换的代码，在公告后的两天我才写出来，但是效果已经达到了。

重点在于，当时那个生死存亡之际，没人用你的服务，留不住目标用户的注意力，瞬间就被竞争对手势头盖掉了。没人玩这个服务，代码再好也白搭。重点真的不在于代码，而在于你怎么想出办法去解决眼前的难题。

有些程序员很不习惯，创业公司为什么做产品是没有spec的，然后充满了workaround以及政治不正确的作法。但是这才是做产品，真正残酷面对的事情。创业公司所有遇到的挑战都是都是动态生成的，动态生成的挑战，是没办法预先规划解法的。

我现在比较幸运，团队成员都比较没有这些包袱。这当中很大的原因是因为，很多人都是我当时Rails补习班的学生，后来来跟我一起做公司的，因为它们之前不是职业程序员，所以并没有那么多包袱需要忘掉。

第四误区：创业一开始没有钱，所以跑去接案，边接案边开发产品

我开始创业后，我自己最大的误区是以为创业就可以赚到很多钱。我一身好本领，老板当初给我的薪水低估我的身价。这也是一般程序员最直接的想法，凭什么老板赚走那么多的钱，我自己功劳那么大，但是我并没有得到很合理的身价。

甚至很多程序员，看到自己老板赚那么多钱，觉得心理不平衡。觉得老板又不会写代码，老板能够赚很多钱，还不是我帮他写的代码可以让他把产品卖出那么多份。创业真的也没那么难，反正在写代码时已经知道老板的 Knowhow，只要出去开一个 me too，去跟他做一样的事情，甚至做得更好，就可以赚比老板更多的钱。

这是其中一个比较天真的想法。

第二个比较雷的部分是。创业一开始，不论是谁，都需要资本启动。但是我自己并没有钱，身上有的只有技术。所以一开始就先帮别人写程式代工接案，赚第一桶金。边接案边做产品。这是创业我走过也相当冤枉的一条路。

所以之后我都会想劝想创业的程序员，别接案了。想创业去跟银行借一笔钱，直接去做你想要的产品，别绕一大圈路。

为了创业，一开始去创业。是一个完全错误的开始。怎么说呢？你没有钱也不知道怎么启动的原因，说难听一点在于你不知道「如何创造价值」（讽刺吧，想创业却不知到如何创造价值）。所以想到的方法只能卖自己的技术，帮人做外包。但是这件事最坑的在于，你不是在卖技术，而是在「卖时间」。

接案这件事的本质，就是你的时间只能卖一遍。

而且接案是一个挺痛苦的行业。就是接案的时候，就算你的产出是100分，业主也只会觉得这些产出是60分。做120分，业主觉得这刚好在他心目中也顶多是80分而已。但是，如果你做60分80分，他会觉得是20分。

而且接案有淡季，淡季有旺季。而那员工看你旺季很赚钱，但他不知道淡季不赚钱。但他觉得老板在billing hour 上赚那么多钱，怎么都没有分我。而且接案公司员工很多人，也不喜欢自己反复在做不同的新产品，他会觉得没有跟着产品共同成长累积。

所以这些刚训练好的员工，在刚训练好能够独当一面的时候就走了，流失率很大。

这个行业等于

1. 只是在卖时间
2. 帮人家在代训程序员，自己公司并没有累积资产

我后来认为，与其去接案得到这样的结局，真的还不如继续上班。

外面有一个理论：就是如果创业没有赚超过以前薪资的三倍，根本是赔钱的一件事情。

所以我建议适合创业的状态，是你知道自己确定能做出什么有价值的产品，再出来开始。

万一没有钱开始第一笔资金又没人投资你，那就去跟银行借钱。

接案这个方向是下下之选。因为接案所赚到的金钱，跟剩下来时间是不够用来开发产品的。这样紧迫的资源，会产出一个不怎么样的产品，同时产品开发的时间，也会拉的过长。等你做出来之后，风口也过了。

这是我认为这是最不值得的一条路，所以我完全不会建议程序员创业一开始去去接案。

第五误区：错判风口的重要性。以为风口上的猪只是纯粹上幸运。

创业怎么样挑IDEA？

我见到一些人，对于风口上兴起的企业，挺瞧不起的。风口上的猪，什么牛B？还不是幸运遇到风口而已。我以前也有这种偏激的想法。特别是那些幸运儿，在旁边看觉得他实力也不怎么样。凭什么他能够站上去。

但后来我真的站过几次风口之后，我才发现风口上能飞的真不是猪，都是神人。因为风口里面被干死的人，真是多到没办法想像。在风口里面，勉强站稳都很困难了。更何况是能稳稳飞上去的人。

我几次比较成功的创业，都0飞在风口上，我第一次在风口中央的时候进去。第二个在风口前，第三个我自己在风口还没打开的时候，嗅到那个压力很大，赶紧冲上去。

有的朋友很羡慕我，觉得我老是想到正确的 IDEA，一炮而红。老实说，真不是这样的...

我在这里举个真实发生的有趣故事。大概三四年前，我还在苦苦挣扎时，我遇到一个很有钱的创业家，请我帮他找程序员。我说我挺羡慕你这个生意挺 niche 挺独赚的。你怎么会想到做这个IDEA？这想法真是太聪明了，一般人都没有想过。

没想到，他竟然跟我抱怨：「你知道我根本不想做这个，我根本不喜欢这行业，做这个行业这不是我热爱的行业。虽然这很赚钱。我做这个行业，很纠结，也很累。你不要以为我现在很有钱，其实他妈超痛苦。我一天到晚想把这生意卖了去做我想要做的行业」。

我听了就觉得，这是干话。不跟我讲就算了，你还跟我说你不喜欢这service，做这个是无心插柳。但是，我后来跟一些成功的创业家朋友聊天，他们也一样都跟我讲干话。我就对这些人很生气，觉得它们很小气。

但是后来其他创业家来问我，为什么我一天到晚可以想到风口上的生意，这个生意还赚不少钱。人家就跟我请教秘诀，然后我就它们讲「肺腑之言」，它们却听起来像我当初听到干活一样。。。。。。。。哈哈哈哈哈哈哈哈

要真说起来，我人生的梦想是去作一个，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知识都忘掉。所以今天才可以站在这里。

我这六年来走过了无数冤枉路，真的每一条都付上大量学费。这当中每一条都是，我在当工程师的时候觉得理所当然的决策，最佳实践。然而它们在创业这条路上都是错的。

不把这些忘掉，就没办法在新的路上成长。这是为什么这一章我会花了这么大的篇幅，不谈方法论而写了一万多字回忆录的原因。