Skip to content

Latest commit

 

History

History
520 lines (268 loc) · 45.6 KB

04.md

File metadata and controls

520 lines (268 loc) · 45.6 KB

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

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

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

但其实一路上来,我走了非常多的冤枉路。这一章,我想要把这个题目,命名为 程序员 创业遇到的冤枉路 -- 我所踩过的 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知识都忘掉。所以今天才可以站在这里。

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

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