当我们所做的事情，超过了上限时，便会出现负担过载，进而引发一系列的问题，在这些问题当中就包含了“死亡”。这在产品里也是相通的，同时开放过多的功能，不仅会造成产品功能负担过载，也会造成用户的负担过载。

很多创业朋友在失败后，通常会去找团队，找资金，找市场的原因，但却很少提到产品功能 负担过载，这个最隐秘的死亡原因。

那么，为什么负担过载会导致产品死亡呢？接下来就为你说说他的几点思考：

首先一点是.产品功能只有宽度 ，没深度

我们会盲目的去做许多的功能，甚至我们自己都不清楚为什么要做某个功能。太多的需求，第一个影响的便是产品经理的思维，以至于没有时间去深思熟虑。比如：通过位置，应用方法，文案让这个功能更有效的深度，更符合人性。

第二点是.盲目开发，资源分散

现在许多创业团队其实都不是在做技术创新，也就是说，我们的功能是大同小异的，开发成本已然降到了最低。

那么产品经理功能开发需求，直接影响研发工作量，一旦产品经理产生了负担过载的现象，研发就会出现功能量过载的问题，再优秀的技术大牛，面对夸张的负担过载，也只有将大部分的精力分散到完全无关的功能当中。这恰恰是许多产品没有核心功能的原因，过多的研发资源投入到了极为普通的应用功能当中，无法打造更新的，更具备深度的，更个性化的功能。

第三点是.匆忙运营，开花不结果

我们已经知道了负担过载对产品经理，对研发的致死因素，负担过载的影响远远超过我们的预测，它对我们的运营来讲，也同样是一种看不见的致死病毒。

这里要强调，运营和产品是两条并行的线，彼此合作，彼此借力，而由产品部分引发的负担过载，会成倍数的增加运营的负担，以至于开花不结果。

我们在运营时，往往需要借助运营点 ，这就需要产品提供一些可被运营的媒介，然而，当出现多个运营点时，并且每一个点都是一个所谓的亮点 所谓的核心时，运营体系便会走向崩溃。因为他们的注意力需要非常的专注，才能有效的控制一次运营事件。也正因为如此，运营的多任务并行难度远超过产品。

当我们产品交付给运营的产物出现过载时，如果没有被运营主观上的减少运营点,那基本可以预测 未来的运营阶段必然是混乱的。在这样的环境下，同时并行两个以上的运营点，会直接影响运营的过程和结果。当我们的源头，产品经理出现负担过载时，我们的运营基本上就可以预判后期的工作节奏以及成果了。多数情况下，会是只开花，不结果。

第四点是.人多也是一种负担

我们有时候会近乎偏执的相信自己是正确的，比如，负担过载的上述三个结果，我们都可以归结到人数上，那我们招人就可以了，增加人手就可以了。这是对的，但也正因为他是正确的，所以我们离死亡更进一步。

当我们决定增加团队时，负担过载最大的致死因素就开始发生作用了，产品功能需求的负担过载顺理成章的变成了任务过载，现在，他演变成了人员过载。

首先并不是把人放在一起就是一个团队。

新成员融入团队是伴随着双向风险的，一方面新成员的思想会对我们产生冲击，同时我们会消耗更多的时间在于新成员的沟通上。当已经出现负担过载的情况时，再招人不但不能立即帮我们分担，降低负担，反而会为我们增加更多的负担，让这种负担过载的情况变得更为严峻。

其次团队向心力的冲击

当我们一个人自己做一件事情时，毫无疑问，我们是一心一意的，当我们两人一起做事时，我们尚且能做到彼此尊重，互相理解。随着人数的增加，这层脆弱的向心力，会逐渐崩坏，我们很难通过人与人的沟通来产生企业文化，更多的需要由规范，原则，无数次的事件来形成企业文化。

而当新成员进入一个团队时，必然会对团队向心力产生冲击，并且，这往往和我们引入的人才能力成正比，越优秀的人才，对我们的向心力冲击越大。

最后的结果是什么呢？我们找了更多的人，但他们并不是来帮我们解决问题的，这很残酷，但也很现实。忙碌中我们却忽略了，人数，也是负担过载的一种结果。

最后既然已经提到了负担过载是死亡原因之一，这里就给你几条小建议：第一条是.最有效也是最直接的办法，减少需求量

产品经理是负担过载的源头，当然很多公司老板也充当半个产品经理，如果我们能控制需求量源头，这将会对规避负担过载有重大价值。

第二条是.砍掉现有的需求

砍需求，恰恰是专业的一种表现方式，只有我们充分的认识需求，能够判断需求的价值，能够进行需求对比，和选择，我们才能砍需求，而不是指随意任性的砍需求。

第三条是.永远记住：你能做的，真的没有那么多，能做好的也就更少了。

如果小龙哥将微信的源代码送给你，你能再做一个微信出来吗？

其实我们能做的事情，并不多，许多时候，即便是把功能做出来了，并且做的和别人一模一样了，也不见得我们真的能应用这个功能

支付宝，花了很多时间，很多成本，很多教训才明白他真的做不了社交（传言支付宝经过三个月的讨论，决定放弃社交）。