我在迅雷做失败的4个产品项目

迅雷于2002年底由邹胜龙先生及程浩先生始创于美国硅谷，2003年1月底，两位创办者回国发展并正式成立深圳市三代科技开发有限公司（简称“三代科技”），由于发展的需要，“三代科技”于2005年5月正式更名为“深圳市迅雷网络技术有限公司”，暨迅雷在大中华区的研发中心和运营中心。

因为在迅雷年资稍微有点久的缘故，作为主要成员参与了不少失败的项目，大部分项目失败了以后，大家就收拾下心情找换个项目继续干活，极少回顾当初的不足之处，我觉得，这些一手的失败经验比起成功者分享的无敌必胜手，更有启发意义。

加上这些项目都已经消亡，我应该能以一个比较平和的心态看待失败，那就试着写写其中的教训吧！

1、下载速度的数据分析

这是我刚毕业的第一个任务：通过用户端的海量数据找到迅雷下载速度哪里有问题，想解决之道。

下载速度是跟本地网络强相关的指标，我们在浪费了老板“一堆”工资以后，得到的最有价值结果，就是：新版发布后要在统一网络环境下进行新旧版本的速度比较，才能得到真实的改进报告。

听起来真的是废话吧，可在当时我们并不知道！

当时我维护的数据报表中有一项是mp3的下载速度，我老板的老板的老板李金波在开发时分了四个区间统计速度，分别是：2m以下、2-5m、5-10m和10m以上。

因为实在无聊刷存在感，有一天我邮件给李老板，在邮件中列举了详细的资料和统计数据，还加上了箱图和茎叶图，说明mp3主要集中在3m-8m，所以我们的下载速度统计划分应该用3m以下、3m-8m、8m以上这三个速度来区别，这样就能比较真实地反应出用户下载时的感受。

邮件发出以后，金波就找我吃了个午饭，只说了一句：这个指标主要看的是历史趋势，这样的改变统计口径真的很重要吗？然后就什么都不再说了。

这种没有明确目标、对公司也没啥产出的项目过了一段时间就自然因为成员离职解散，我也因为机缘巧合做了迅雷会员工作。

因为这段经历的缘故，我知道了团队中其实一堆人在毫无贡献地假装工作，还出一些看似专业的报告来刷存在感（因为我当初就是这么玩的）。

后来我自己团队有同学毕业去新公司时，我会克制住招聘新人的想法，看看现在的人能不能消化好额外的工作，结果往往是人少了几个，事情还能继续运转。

2、离线金豆

这是我在做迅雷会员早期的一项工作，刚开始做离线下载的时候，因为我们对成本估计没有底，加上一些技术瓶颈，我们给付费用户的离线空间非常少(好像vip1级是3GB，单任务最大1.6GB)，高速通道流量是每月累计加速文件大小不超过10GB。

虽然我们后台统计99%的全体用户都够用，但对下载发烧友是绝对不够的，而且这些发烧友恰好又是我们付费的主力军。

所以我们就想了个当时看起来很巧妙的方案，我们做了个用户换算，1GB空间/天=1G高速通道流量=1金豆=1000银豆。

用户可以把每个月不用的流量和空间存起来，万一某天想下载超级大文件的时候，就能派得上用场，更进一步，我们还想把自己用不完的金豆送给朋友，或者相互交易，产生更多价值。

比如我的存储空间是3GB，当我想下载一个30GB文艺片合集的时候就无能为力，但有了这个金豆转换体系，我可以把3GB一个月的空间转化成90个金豆，然后用其中的30个金豆兑换30GB空间一天。

因为提前透支了未来的金豆，剩下的29天里我就只能有不到1GB的空间了。

你看出来问题了么？这个换算太复杂了，一般人根本搞不懂，用户往往在空间不够的时候透支了，然后根本不仔细考虑之后空间会少的问题。

突然能够下很多东西很开心，然后过几天发现怎么会回事，自己空间不见了怎么办？什么时候恢复？我的空间是不是一直少下去？不小心误操作怎么办？一天的时间从什么时候开始算？我自己算的和你们算的对不上？

哎哟，一系列问题，刚上线的一周我每天都在兼职答疑，高峰时期每天1000个用户加我们的对外qq询问，或者骂脏话。

本来是想帮用户解决空间不足时下载更大文件的问题，结果惹了一身骚，后来由于qq旋风离线下载的竞争和我们边际成本的下降，给用户的空间越来越大(1000TB，是TB没打错)，已经用不完了，金豆这个功能也就没有存在的必要了。

有一次，临时过来支援离线产品的同学在设计时拿掉了金豆的显示和操作入口，其实我知道这个东西已经没有价值，但是心魔还是没死，就去问他为什么没有。

他一句话就点化了我：金豆不重要，在这么小的界面上没必要占地方。

我们想解决用户空间不足和成本控制的问题，但我们想偷懒省事，不去从技术上降低存储成本、不去发展用户降低边际成本这些“笨方法”，反而追求一种看起来巧妙的技巧。

不是从可持续、主动升级改善我们，不是从升级改良(提升空间)的角度去解决问题，真的是愚蠢至极啊！

而且当这么多用户(每天上千个)投诉的时候还是心魔不死，不断打修正补丁，用战术上的勤奋掩盖我们战略的错误，死不认错，误人误己啊！

3、文件邮

有一段时间会员的新功能一直出不来，于是大老板在看到美国一家叫“you send it”的公司拿到一轮大融资以后，就说我们也做一个吧。

you send it解决的是公司间往来大附件邮件的问题，通过给outlook安装一个插件，你发送大附件的时候就自动转成you send it的一个下载链接，有点类似qq的文件中转站，只是更偏商务应用。

大家都知道，老板的项目嘛，大家肯定积极响应快速出产品，于是我们也就模仿了you send it的一部分基础功能，发布了一个叫“文件邮”的产品。

用户上传附件，同时输入对方的邮箱地址，就可以把超级大的文件发送给对方了，如果这个文件在迅雷服务器有缓存，那么可以实现瞬间秒传，大大节省了上传时间。

听起来还有点意思吧！可实际上，有意思个屁！

我当初最大的毛病，就是把它当成一个文字小清新的产品，由着自己的性子打造，居然没有去考虑一个重要的问题：中国人有几个人能记住对方的邮箱？

我要朋友的邮箱，只能去qq个人消息里面查，或者复制他的qq号，那既然我都在qq里面了，干脆用qq文件中转站不就行了么，又快又好，哪还用得着文件邮这破东西啊！

于是，在我们死不认错地发布了几个版本、使用人数都是我们自己，测试以后，终于搁浅了（如果当时能仔细分析一下用户离开的理由，也许就不会这么累的去坚持了，具体的分析方法可查看马海祥博客《产品经理应重点分析用户离开的背后原因》的相关介绍）。

再后来，在一个同事的带领下把发邮件共享改成了做外链共享的快传(中小站和论坛很需要)以后，用户量有了爆炸性发展，快传后面因为公司战略放弃出现萎缩，又是另外一说了。

我以前经常说当你自己拿不准的时候要大胆抄袭别人的经验，拿来主义为我所用，这样会比较容易推进事情。

在文件邮复制you send it的时候，用了抄袭快速推进事情，但是忽略了一件事情：抄别人，要抄人家做的好的、比当前产品厉害的地方，这样才有抄的必要。

可是you send it的模式在中国并没有qq文件中转站来得方便，那抄它怎么可能有好结果啊！

4、迅雷壁纸

在互联网上已经有无数人说过产品要从用户的需求出发，要解决用户的问题，要给用户创造价值。

而迅雷壁纸的推出则是以上三点都没有沾边的“三无产品”。

这个项目是我主导的，出发点很是可笑，当时迅雷客户端团队在做下载时已经陷入“做来做去都一样”的困境，所以我就想了一个有用户量的客户端产品让团队抽空做一下，万一成了还有惊喜呢！

事后看起来，这个“给团队找点事干”的出发点，就注定了失败。

因为是抽空做的项目，也就没有正式的团队编制，利用我在迅雷的一点点面子拉了几个好说话的同学帮忙做，项目的发布周期、推广计划、开发质量通通没办法保证，后来因为这种没有任何保障的缘故，壁纸的产品举哥还多次找我谈心求助。

那时举哥才刚毕业一年，跟他聊天的过程中发现他是具有顶级PM潜质的人才，在开发设计非常有限的情况下做出的点真的让我佩服。

可惜一直没有能给他配上足够的资源，后来举哥有了更好的发展，也算是一种解脱吧！

壁纸就在这样没有足够弹药的情况下拖着，项目周期过长，又没有固定班底保障，大家士气低落。

在互联网里，项目开发时间越长，士气就越是低落，成功的可能性越小，没有人愿意被困在一个看不到尽头的任务中，把人困壁纸这种毫无成就的项目中，等于是拿钝刀子杀人。

终于有一天我下了决心，知难而退，不要逞英雄，把壁纸干掉。

如果你已经在不值得的事情上浪费了很多时间，那就赶快走开，错过的时间永远找不回来，更糟糕的事莫过于继续浪费时间。

这个道理我清楚，但当我真正面对的时候，确实做了好长一番的心理建设。

壁纸的失败就是一个典型的为了解决一个老问题，引入一堆新问题的案例，之后再做新项目时，我都会问一下自己，这会是又一个“壁纸项目”吗？

以上这四件都是我作为“主要元凶”犯下的罪行，因为我的朋友有不少迅雷的同学，我尽量客观描述下当时的感受，如果有冒犯之处真的请多多包涵，主要责任是在我身上的。

马海祥博客点评：

做产品运营，既要理解用户的需求，又要理解产品的结构，站在这样一个立场上，能够为策划组带来非常大的帮助，提升产品设计上的可靠性。

以我带队的项目为例子，策划组的每一个设计，都要事先提给运营组去做效果预测，凡是运营组提出的产品建议，质量都非常之高，而每当策划组对用户需求把握不准，或是出现意见分歧的时候，都请求运营组来进行用户访谈，把这个结果当作是客观的裁决依据，很显然，这时运营人员与用户之间的亲密关系就成了极大的优势。