为什么「我们」没做好这款产品？

不少人都有过从0到1做创新项目的经验，而在这个过程中，我们不可免地会面临失败的风险。那么作为项目的运行者或管理者，你是否有想过自己为何要做创新项目，以及项目失败的原因？本文作者便结合自身经验发表了他的看法，一起来看看，或许会对你有所帮助。

之前阅读过我文章的读者朋友们，应该知道；我在不同的公司有过多次从0到1做创新项目的经验（其实就是在中厂做内部项目孵化，没进过大厂）。

按目前经历来说，已经接手过三四个项目了，涉及电商、游戏、社交、工具等领域；但都毫无意外；或多或少均是发展的不怎么样。

至今，我仍在一家公司做创新项目，也仍有不尽如人意的地方。借此梳理总结的机会，跟大家聊一聊我为什么想做新项目-以及项目为啥失败-我在项目中的思考。

一、为什么想做新项目？

我16年初到上海，入行是在一家游戏公司，当时行业正赶上P2P金融爆发期，各种理财、借贷类小产品，满屏飞。由于大部分游戏公司呢，都是买量型公司，由此，我前前..东家也想尝试能否将游戏用户进行二次转化，导流到其他产品中，所以内部就做了这么一个新项目。

最开始，我在项目中是做新媒体运营工作，就是发发文章（虽然我不会，但我便宜），慢慢接触下来，新项目的大领导是该公司的数据总监，人很不错，也有实力。

后续，得知他已经这家公司呆了好多年，从公司初始差不多就在，那么，经过公司发展上市，自己也获得了不错的职位和股权收益。

当时我就觉得，把这个项目做好了，可能也有机会。

两年后，我离开了这家公司，面试进到另一家游戏公司，也是在搭团队准备做新产品，直属上级是技术总监，人很好，也比较放权，基本产品及运营由我们团队自己说的算。

在后续的工作沟通中，得知他在公司工作好多年，从公司初始差不多就在，经过公司发展上市，自己也收获了不错的职位和股权收益。

就这样，我仍觉得好好做项目，可能还有机会。

所以，受他们或多或少潜移默化的影响，我一直都是寄望加入一个有发展的新项目，一起成长进步，如果成功，或许也能享受到他们那样升职加薪的机遇。

直到现在的项目中，我的“领导们”也没有空降加入团队的，都是在公司工作很多年以上的老干部。

以至于，至今我都会更愿意倾向于选择上市公司或中大厂做内部创新项目，一方面资源“相较于会多”，其次项目成员能力会“整体较好”，再者，薪资待遇福利等也不错，可以踏踏实实做事情。

然而，恰恰事与愿违，让我没想到的是，每次项目都失败了（哈哈哈哈..呜呜呜）。

或许属于他们80后的那个掘金发展年代，已很难在90后中在复现了（当然，我可不懂大趋势或行业观察，仅是感慨一下）。

二、项目为什么都会死？

在目前的项目中，遇到了波折，不仅让我开始回想，新项目死亡概率为什么这么“高”（我觉得标准值是项目能够自负盈亏，越过生死线即算为成功了，无需标准到盈利、融资上市等）？

新项目真的要顺应天时地利人和吗？我经历的项目都遇到了哪些波折会有决定性影响？…….

我简单回顾了一下我经历的项目，如下：

第一个项目是金融类产品，其实资源跟团队都不错，主要还是受制于行业，更多受制于是“金融”这个属性。

不过话说回来，是问题都会有解决方案，归根结底还是产品定位或方向问题，如果当时能够顺应变化转型之类的，说不定还能有些些可能（现在回过头马后炮来总结，避免不了臆想一下，哈哈）。

第二个项目是工具型产品，虽然该赛道产品竞争处于红海饱和状态，但当时我们项目组还是切出了一个属于自己产品的定位特色以及用户圈层，新增留存数据表现都不错。

工具类产品是强需求，只要服务能满足特定用户使用，在未投流的情况下，通过活动以及自媒体传播，也能不断地自增长用户，我在过往的文章中有复盘这一经历，感兴趣的朋友可以回顾瞧瞧《撬动产品增长线（2）：完成冷启动后，3个月运营增长从2W到10W+》。

但后来因为内部管理层决策问题，项目不得不砍掉了，至今都觉得很可惜。

3）第三家也是游戏公司，但项目组更偏于根据公司需求，去尝试做一些有市场热度方向的更进；两年多的过程中，团队做了三个产品，由于不能快速看见收益或数据不及预期，就会很快换新产品，团队压很大；也导致团队沉淀不下来东西，更像是外包；负面情绪最终导致团队散了。

快速的做一款产品，并快速的拿到市场验证；对团队的质量要求以及项目组领导的产品把控力会要求很强；怎么解读呢，我举个例子：

比如很早期的答题APP（参与答题瓜分现金、例如冲顶大会、百万英雄、芝士超人等，不知道大家是否还有印象呢，17-18年左右事件）、再有后来的网赚类游戏（例如成语答题、养猪养恐龙等等，20-21年事件）….

当一个赛道出现并且火爆的时候，代表已经有很多公司都注意到了，我参与过的赛道是网赚类游戏，基本快手、字节、阿里非游戏一线大厂以及游戏厂商都有入局在做，更何况还有腰部、短尾公司参赛，速度很快竞争激烈。

所以，当公司有明确的数据验证指标，并要求快速做出来拿到市场验证时，如何能保证一个版本或者迭代两三个版本就能看见效果并预估结果，会直接影响老板拍板评判继续投入还是止损。

为什么会这么决定，怎么不逐步迭代发展呢，因为产品属性不同；游戏具体时效性及买量成本因素。

当一个赛道刚出现，第一个入局的玩家，在市场买量；成本是非常低的，能买到质量好的用户；然后各公司陆续加入，一方面会抬高买量价格，导致产品商业体系跟不上；比如市场买量一天涨一次价格，但产品不能一天更新一个版本增加盈利；

其次，大厂入局竞争力很强，像上述示例的产品赛道，基本几个星期就能出产品上线，如果团队是半年搞一个新产品出来的话，就别谈竞争了；最后是用户，产品机制留不住人，会导致流失，流失就要不断买量，但市场的用户不同的竞品也在买，就导致流量质量洗来洗去，最后洗不出来了，用户来了也不能贡献收益。

当然，这里面展开讲，涉及的部分会比较多；如果大家有兴趣，可以另起一篇讨论；总结就是，如果竞争过于激烈的赛道，需要项目负责人着手入局时，就要思考产品如何兼顾功能、活动、商业化盈利？比如不能没有，没有就形成不了闭环，但不能过多，过多会存在研发时间、数据验证、是否调优，等于给团队在埋坑。

又如如何确保产品灵活性调配？等等；不然跟跑不了几个回合，项目死掉时，请勿埋怨公司不愿意持续投入、研发不给力、运营不会做活动…..

三、我的感受和思考

是的，项目发展尽管不尽如人意，但是工作是长期的，需要不断总结才能避免在同一个历史阶段再次踩坑。受制于篇幅，我大概列举如下，文章太长阅读吃力，我不好长篇大论，读者朋友们感兴趣，可以连载输出。

1）加入一个新项目团队，尽量选择产品是属于强需求的会比较好。强需求代表会有用户愿意用，用户愿意用会赶着团队往前走；那么，产品往下做功能或者运营时；团队方向及沟通都会比较顺畅和拉齐，能明确建立团队目标。

我经历过的工具型产品，真的让我体会到了做产品及运营的快感，用户是需要的，然后一切都是那么的顺畅推进。

否则就是，团队各有各的观点，各有各要想提的建议，各有各想做的功能待验证，各种各样的会议必须带上你，各有各的进度需要你卑微催…..

像我经历的另些项目，不是强需求的话，可能存在市场需求或者是老板想要做的需求，那么就需要快速做出产品，用实际数据证伪；这个过程中，数据投不投放，一但不好；就比较折腾人以及团队；或许坏源头就从没什么人用开始的。

2）不要多做和做多，即不要多做功能也不要多做活动。以前看文章有分享张小龙的产品观点之类的；阅读理解满分了，是的，做产品不能贪多，需要什么做什么。

但当自己深陷一个产品项目中时，已经不知不觉贪婪了起来，权利是一件很可怕的事情，比如管理层、产品、运营；当你有权决定上线一个功能、活动时，要抱有谨慎、担心的态度；是产品真的需要还是我想要？自己真的能做好吗？如何验证数据指标？会有人持续维护关注吗？….

还是做完上线没人管了或者上线后数据不好在拿掉，轻易地得到就会导致不负责任。

我之前包含现在的项目团队，就面临过这样的风险，以前我有权利时，我来决策产品做什么功能、出什么活动；我抱着良好期待，希望呈现的产品功能、活动玩法丰富；当产品突然死掉时，我文件夹中保留了下两个迭代想要做的功能，回顾总结时，已不知所以然。

怎么去把握这个度，我就不在这里展开来讲了，我打算另起讲新产品如何规划需求、排期需求以及活动怎么搭配产品节奏、功能。

3）新项目初始没有盈利指标，也要兼顾多种商业化考虑。我们有时候加入一个新项目，初始先从0到1研发产品，可能过程需要几个月不等，这时没有商业盈利需求和压力。亦或者上线初期，目标是先搞到流量，等有用户使用一段时候后，看看数据，再往下规划。

我也有类似经验，领导给的话让人产生了先做产品，逐步迭代不着急。貌似心里有底，但忽略了新产品存在很大风险性，当突然有变动时，一切都很快。

每个人所处公司及项目不同，我不知道这种历史经验是否能用，我个人经验是规划产品时，商业化不管是广告、会员、还是商城等，一方面是尽可能知道产品后续是打算如何变现，是否存在多种可能性，不管没没有，都多做几种预设打算？

一方面是边做边带入思考，随着功能、用户、市场的数据变化，后面如果上线预定的商业模式，能否支撑团队走下去？时刻保持警惕性及嗅觉，哪怕自己模拟模拟，推算推算指标，心里也到保有底。

最简单的，团队一月开一万工资，现在月活3W，会员假设卖19元，转化率17%才够保本，怎么提高、怎么转化，转化率提升不容易，有没有其他可能性等等。

别等到管理层吹号子，决定要上的时候，你带着团队一起冲，反正大家一起生要么一起死。

有时候项目是在过程中死的，有时候项目是因为折腾来去，还是没有好的盈利模式死的；也或者当你收到盈利指标时，也顶着压力了，按照以往预定的商业去做，上线肯定需要长时间调优，但公司却不愿意给那么长时间，委屈死的。

4）在一个新项目中，尽可能多地影响话语权。在任何公司的任何项目中，要么老板亲自下场教团队怎么做产品，要不老板指任管理层带项目，教团队怎么做产品。

这时，都会存在两种情况，决策层（都是你领导，不管是否直属）到底懂不懂；不懂但是愿意放权，让团队决策产品迭代；或者懂且会带着团队成长学习的；庆幸你在这样的项目组中，请保持激情。

我主要讲讲不懂但影响决策走向的；真的，一塌糊涂；吐槽都得三天，就不传播负面情绪了。

首先，术业有专攻，任何同事所处的岗位都是团队不可或缺的一部分，这不可否认。但如果你所在的团队存在开会时，就具体产品迭代、功能、活动允许项目组成员都参会，且可以发表建议时，请相应负责的你，保持警惕性。

如果你负责的内容或你拿出来的方案，被大家任意讨论提出建议；首先要学会拒绝，不要被顺带立马答应，否则，散会你会后悔的；不确定的先回复：好的，建议我收到，我下去思考整下下，稍后单独找你沟通回复。

其次，不要被影响，保持你的出发点和思路，去矫正他们的思路想法，尽可能的让他们的跟你的思路对齐，因为最终你负责结果，过程你来跟进；大家吧嗒吧嗒讲完散会，最后方案还是你来执行，如果有差别，你是痛苦的。

最后，说服一个人是很难的，因为大家经验、立场包括认知思路都不一样，如果演化成争吵，虽然都说是为了用户为了体验，但实际已经变成了较量输赢。只能变化方式，比如：好，如果按照这个方式调整，我们推演一下，假设123….

最终，尽可能不要让别人影响你负责的部分，如果是好的则是；自己的一亩三分地牢牢掌握话语权，有能力的话，其他不合理的地方，也尽可能去争取影响团队成员。

为什么呢，如果受影响改动，违背自己的预设的方案，一方面你会越来越消极，话语权越来越低，会导致你的工作受到破坏。其次，产品将会被折腾的无处安放，啥也不是都有可能。

5）团队能力参差不齐，尽可能将风险降到最低。这句话是我从产品设计功能时感悟的，不知其他业务岗位是否有无感触经历；当产品设计一个功能时，过程是分工协作最终呈现出来的，比如从UI到研发；或者还有其他岗位角色介入，可能会导致一个需求最终上线会有些变形，比如实现上、视觉上、内容上、活动配备等。

会存在不满意或者仍有改进空间，受不同限制等因素影响，可能会要一段时间逐步完善；那么，如果意识到个别或整体团队参差不齐时，尽可能后面再做方案时，做小不做大，比如一个功能模块，尽可能不一次性覆盖面太广，比如一个活动尽可能简化复杂度等。因为等着改进的部分可能以后就没得改进了；其次，上线后自己看着也不舒服是最尴尬的。

还有很多总结想要说，但就到这里。