傲品派
www.orbrand.com

产品过早夭折?原因可能是它!


万物皆有其承载上限,即便是无底洞,也不是真正的无底,他的深度无法超过地球的直径,这些上限,很清晰的在我们工作生活中,也许并不是那么的引入瞩目。

什么是负担过载

  • Android可允许调用的方法上限为65536
  • 千年虫事件(指计算机处理的日期上限,也叫计算机2000年问题,指由于年份使用的是两位十进制数来表达,无法处理跨世纪日期处理,进而引发各种各样的功能紊乱,系统故障)
  • 1970起始年事件(与千年虫类似,指一些程序日期在1970之前,会导致系统紊乱。PS:现在你知道为什么许多产品,生日都会在1970年以上了吧)

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

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

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

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

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

同时开放过多的功能,也会造成用户的负担过载。

负担过载导致死亡的原因

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

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

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

有宽度 ,没深度

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

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

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

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

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

盲目开发,资源分散

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

也就是说,我们的功能是大同小异的,于应用创新而言,我们的开发成本已然降到了最低。1.0阶段,其实大部分的功能,2年左右的研发都能够完成,其实初创团队并不需要寻找技术大牛,许多的技术大牛,做着普通的事情,唯一不普通的只是事情的数量

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

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

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

匆忙运营,开花不结果

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

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

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

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

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

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

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

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

在这样的环境下,同时并行两个以上的运营点,会直接影响运营的过程,这也是为什么许多从事运营行业2-3年的朋友,对运营的了解尚显简陋的原因。

负担过载的情况下,我们无法专注的做好一件事情,自然无法窥视到一件事情所经历的各个阶段,也自然无法将结果调整到最好。

我们总是在来回切,就像切一些自己不喜欢的歌曲,很多时候,事情刚刚开始,就已经结束了,毕竟还有那么多的运营点没有被运营。

当我们的源头,产品经理出现负担过载时,我们的运营基本上就可以预判后期的工作节奏以及成果了。

当然,多数情况下,会是只开花,不结果

人多也是一种负担

我们有时候会近乎偏执的相信自己是正确的,比如,负担过载的上述 3 个结果,我们都可以归结到人数上,那我们招人就可以了,增加人手就可以了。

这是对的,但也正因为他是正确的,所以我们离死亡更进一步

1000人以上的企业,与10人的企业,他的复杂度不一样,他的风险不一样这个我们是一目了然的,但大部分的时间,我们并没有意识到 2 个人和 3 个人也是不一样的。

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

并不是把人放在一起就是一个团队,不考虑招人成本情况下,我们来看看已经招到人以后产生的致死因素。

新成员融入风险

新成员融入团队是伴随着双向风险的,其中,对团队而言,新成员的思想会对我们产生冲击,我们会消耗更多的时间在于新成员的沟通上。

当已经出现负担过载的情况时,再招人不但不能立即帮我们分担,降低负担,反而会为我们增加更多的负担,让这种负担过载的情况变得更为严峻。

原本,我们加班能完成的事情,引入新成员以后,不仅仅仍然要加班,而且现在加班也做不完了。

团队向心力的冲击

当我们一个人自己做一件事情时,毫无疑问,我们是一心一意的,当我们两人一起做事时,我们尚且能做到彼此尊重,互相理解。

而这层脆弱的向心力,随着人数的增加,会逐渐崩坏,我们很难通过人与人的沟通来产生企业文化,更多的需要由规范,原则,无数次的事件来形成企业文化。

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

这是有原因的:

  • 有经验的人才,往往由于自己所经历过的环境,形成了自己判断事情的标准,我们的技能虽然比较专业,但同样的,我们的可塑性是比较薄弱的。
  • 我们很难找到与自己想法完全相同的人, 尽管这样的人确实存在,但我们所能接触到的人,相对于所有人来讲,实在是太少了。
  • 最后的结果是什么呢?我们找了更多的人,但他们并不是来帮我们解决问题的,这很残酷,但也很现实。

    我相信,不论对于招聘者,还是对于应聘者,我们都希望能很好的协作,我也相信,我们都想要帮对方解决问题,都不是来找茬的。

    但我们却忽略了,人数,也是负担过载的一种结果。

    我们迎来了更多的争执,我们在讨论上花的时间越来越多,我们的需求也越来越多,负担过载不但没有被降低,反而越来越多,在结果到来之前,我们便早早预测到了结果,但却无能为力,除非我们能够学会控制自己,减少负担。

    建议

    我们既然已经提到了负担过载是死亡原因之一,我想给大家一些建议,但文章中不准备展开描述了。有机会的话我会单独再写一篇详细阐述如何避免负担过载。

    最有效的办法,减少需求量

    产品经理是负担过载的源头,如果我们能控制需求量,这将会对规避负担过载有重大价值。在我的习惯里,一个大版本是由固定的节奏的,比如 他会包含 1 个运营点,1 个功能模块,诸多的细节调整。

    砍需求,比新增需求更专业

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

    你能做的,真的没有那么多

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

    其实我们能做的事情,并不多,许多时候,即便是把功能做出来了,并且做的和别人一模一样了,也不见得我们真的能应用这个功能。支付宝,花了许多时间,许多成本才明白他真的做不了社交。

    我们真的不那么强大, 能做的事情,真的很少。

    勿以世界为敌,做我们能做的事情,把他做好。

    赞(0)
    欢迎分享:傲品派 » 产品过早夭折?原因可能是它!
    分享到: 更多 (0)

    相关推荐

    • 暂无文章

    评论 抢沙发

    • 昵称 (必填)
    • 邮箱 (必填)
    • 网址