产品死亡原因之「负担过载」

导读

讲成功的太多了，讲有用的也太多了，这次，我来讲讲没用的，同时也讲讲失败。

什么是负担过载

万物皆有其承载上限，即便是无底洞，也不是真正的无底，他的深度无法超过地球的直径。

这些上限，很清晰的在我们工作生活中，也许并不是那么的引入瞩目。

• android可允许调用的方法上限为65536

• 千年虫的设定，是指计算机处理的日期上限，(也叫计算机 2000 年问题，由于年份使用的是两位十进制数来表达，无法处理跨世纪日期处理，进而引发各种各样的功能紊乱，系统故障)

• 与千年虫问题相同的是， 1970 起始年，如果程序日期在 1970 之前，也会导致相同结果，(现在，你知道为什么许多产品，生日都会在 1970 年以上了吗)

当我们所做的事情，超过了固定的上限时，便会出现负担过载，进而引发一系列的问题，在这些问题当中就包含了“死亡”

这在我们的产品里是相同的。

当我看到一个1. 0 的产品异常简单时，总是会有一种莫名的认同感，1. 0 真的不需要太多。

实际上，不只是1.0，在我们每次进行版本迭代时，都不需要太多的功能。

不是因为我们偷懒，也不是因为开发成本。

同时开放过多的功能，也会照成用户的负担过载

负担过载导致死亡的原因

这是我写的第一篇 讲死亡的，负担过载 大概是最高频，但却最隐秘的死亡原因。

很多创业朋友在失败后，通常会去找团队，找资金，找市场的原因，但却很少提到 负担过载。

为什么负担过载会导致死亡呢?

• 有宽度 ，没深度 

  我们要堆功能很容易，但要做有深度的功能却很难， 负担过载的情况下，我们会盲目的去做许多的功能，可每一个功能的思考深度都是缺少的，甚至我们自己都不清楚为什么要做某个功能。

负担过载第一个影响的便是产品经理的思维，太多的需求，以至于我们没有时间去深思熟虑

功能都是相同的，但不同的用法却取决于我们如何应用相同的功能，宽度是指我们的功能量多，深度却是指我们的应用方法巧妙且有效。

1 天的时间，我们可以堆出数十个功能，也可以只输出一个功能，但通过位置，应用方法，文案让这个功能剧本更有效的深度，更符合人性

功能不会符合人性，符合人性的只有我们的应用方法

• 盲目开发，资源分散 

  现在许多创业团队其实都不是在做技术创新，真正的做技术创新，技术创业的团队非常的少，我们已经进入了应用创新时代。

也就是说，我们的功能是大同小异的，于应用创新而言，我们的开发成本已然降到了最低。

1. 0 阶段，其实大部分的功能， 2 年左右的研发都能够完成，其实初创团队并不需要寻找技术大牛，许多的技术大牛，做着普通的事情，唯一不普通的只是事情的数量

我提倡的是“从容不迫”的开发状态，显然，这并不那么容易实现，因为影响研发工作量的，恰恰是我们产品经理。

一旦产品经理产生了负担过载的现象，研发就会出现功能量过载的问题，再优秀的技术大牛，面对夸张的负担过载，也只有将大部分的精力分散到完全无关的功能当中。

盲目开发，恰恰是许多产品没有核心功能的原因，过多的研发资源投入到了极为普通的应用功能当中，无法打造更新的，更具备深度的，更个性化的功能

• 匆忙运营，开花不结果

许多创业团队，不是因为项目不好，而是被自己拖死的，我们已经知道了负担过载对产品经理，对研发的致死因素，可负担过载的影响远远超过我们的预测，它对我们的运营阶段来讲，也同样是一种看不见的致死病毒

过载负担的结果往往意味着产品的某个版本 同时上线了多个功能，典型的重灾区在我们的1. 0 阶段。

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

我们在运营时，往往需要借助运营点 ，这需要产品提供一些可被运营的媒介，然而，当出现多个运营点时，并且每一个点都是一个所谓的亮点 所谓的核心时，运营体系便会走向崩溃。

我时常和朋友提到，运营比产品更加刺激，在我们努力开发出一个版本时，运营可能已经做完了三到四个运营事件，尽管我是产品经理，但我非常的尊敬运营体系的朋友，他们的注意力需要非常的专注，才能有效的控制一次运营事件。

我们的市场并没有留下足够的时间，让运营像产品一样深思熟虑，也正因为如此，运营的多任务并行难度远超过产品，毕竟我们还有相对充足的时间去纠正，去修改，比如需求变更。

当我们交付给运营的产物出现过载时，如果没有被运营主观上的减少运营点，那基本可以预测 未来的运营阶段必然是混乱的。

我已经提到了在运营事件当中，运营朋友对这个事件的专注度要求非常高，一个独立且完整的运营事件，包括运营策略，前期准备，事件开展，过程控制，转化策略，数据分析，复盘 等多个环节，而这些都会集中在一个星期以内完成。

（编辑：ASP站长网）