陷入瓶颈的B端产品应该怎么做?

最近又再次陷入了瓶颈期,这段时间所思考的问题是B端产品应该做什么才会有意义?自身或者产品又应该往什么方向发展?想借此重新确立自己的价值标杆让自己更加坚定。

这段时间的思考,自己也略微明晰了产生瓶颈的原因以及前行的方向,在此也与各位分享我的思考过程。

01 B端产品为什么会陷入瓶颈期?

陷入瓶颈期的客观原因有3点,分别是业务形态和管理模式相对稳定B端版图的相对饱和以及B端产品的边际效应开始递减。

这3个原因,让我产生了所做之事没有意义以及可能无事可做的焦虑感。

1)业务形态和管理模式相对稳定

B端产品是体现业务管理思想的数字化工具

对小标题的解读引用了周翔老师的一句话,他将B端产品讲的非常透彻。

B端产品不仅是面向企业级的市场产品,也不仅是某个简单的后台操作系统,它体现了企业对某类业务的管理思想。

而实现管理的方式则是将抽象的业务数字化将复杂的业务逻辑转变为可度量的数据。

数字化的目的是希望将生产经营环节及业务流程的物理信息链接,让数字价值产生商业价值。

161717ab2067ed3c8ff42fa0e4849084-picture

如果说认可了B端产品由业务而生,当业务趋于平稳且相应领域都有解决产品时,那无论是业务视角还是基础支持,B端产品都很难有所作为。

这种情景下,B端产品经理的突破一定程度上依赖于业务和管理的突破。

前者理解为企业踏入了新的业务领域,你需要重新将业务进行数字化管理,通过新项目的视角踏出信息茧房。举个例子辅助理解,比如说:电商平台拓展分销业务。

后者则理解为管理模式的变化或者突破,管理模式的变化可能源于组织架构的调整亦或者业务侧重点的变化,而突破则是指管理模式上的优化或者说全新、更优的选择。

业务形态与管理模式的变化,会造成B端产品的变化。假设这2者都趋于稳定,我们方向则可能需要转向自身或者挖掘产品深度。

2)B端产品的边际效应开始递减

第2个比较重要的原因,则与B端产品的边际效应有关。当B端产品完善至一定程度,已经不再有深度可挖,其边际效应会开始递减。

这个阶段一般发生在平台期。

cca92463b7f5f5f62d3ba83f35f63451-picture

随着需求的自然扩散,会逐步的从一个功能衍变为一个系统,再从系统逐渐成为平台。

例如查看成交数据这一需求,背后对应的是数据的上报落库、清洗、产出以及呈现。最开始这类需求,多会使用报表邮件形式by case 实现。当需求逐渐多样化,随着查询维度、数据类型的增加,逐渐会发展成为报表系统。

系统大多解决某一类问题,偏向于局部。而平台则偏向于整体解决方案,它是一系列系统的集合,能够更完整的闭环解决更多问题。

当发展至平台阶段时产品已经趋近成熟,往深度再次拓展,更多是旁支流程的工作,效益不一定高。

而如果想从这个产品跨越至另一个产品,却又可能涉及边界的问题。需要解决的问题已经被解决了,而解决的不好或者未解决的问题不一定由你解决。

这样一来,成熟的B端产品更多只是维稳了。

02 面向瓶颈的解题思路有哪些?

基于第1小节的推论,假设说B端产品经理的瓶颈是必然事件,或者大概率事件。

那当面向上文所说2种场景时,能够有哪些解题思路呢?更有意义、有价值的又是什么?

最容易想到的解题思路是往效率更高的方向走,用一个逼格比较高的词大概是熵减。

684b7f0c0b7d3ab356a53cbfaf7569d8-picture

上图是过往经验的一些总结,但在这里需要着重说明的是,效率高不代表有价值,有价值不代表有重要性,不要盲目的为了做而做。

线下业务朝线上转变可以理解为业务的标准化及数字化,这也是互联网产品的核心方向之一。我们可以思考产品辐射范围内,有哪部分的工作仍然是线下处理的,然后将其转移至线上。

6c8834b91412a9f03fc4b07ebdff0672-picture

自动化、并行化、智能化,这3个思路可以拆分单独运行,也可以组合一起实施。

将人工操作的串行步骤,优化为自动的并行步骤。将需要人工决策的行为,交由模型实现智能推荐以及自动调优。

但上述的思路适用于平台化程度较低的B端产品,在产品的大后期往这些方向走则显得十分鸡肋。

而内部转向外部,则是平台化的终极目标:商业化,但往该方向发力的企业少之又少。

所以我最终给的答案是:深入**运营与KPI紧密相联,帮助业务增长。**

03 为什么要深入运营?

深入运营的原因是B端产品产出的价值接近上限,需要考虑持续创造价值。

这个结论容易产生反对意见,因为B端产品是业务的抽象,为什么不算深入运营?而业务使用产品帮助业务增长,难道不算持续产出价值?

面向这2个提问答案是肯定的,深入了运营也产出了价值。不深入无法抽象可用的产品,无价值不可能立项。只是前者过于片面,后者过于单薄。

这和B端产品的特性以及收益规模有关。

1)B端产品的特性

B端产品,其使用对象是企业或者组织,用于解决某一特定领域的问题。而参见第2节的解题思路,更多的是通过产品帮助人完成一部分的工作,所以B端产品工具属性会非常重。

而工具则意味着只是提供能力,提供画布的人为什么能认为一幅画的产出和你有关系呢?

我们做的不过是将业务的管理模式抽象为一个产品,在提供能力后却很少干涉运营。而即使参与了运营,我们也很难拥有对业务完整的视角。

基于某个需求在做某件事,那我们所提升的效果更多的是点,你不知道这个指标在整个业务的比重,推导的逻辑。所谓的效果都只是皮与毛。

2)收益规模

收益规模,则与产品阶段有关。

6686fbad8e3be919329ef4c8532a2798-picture

建设期的目标是将业务数字化,是从无到有的过程。成长期则是产品建设完毕,业务开始运作,我们开始衡量效益。

再往后则是平台化后的拓展期,它能够迅速的链接上下游,能够外输服务乃至商业化。

如果没有商业化,或者商业化没有起色,那所谓效率亦或者局部的效果换算的经济收益,可能不如业务1%的增长。

这里并不是说效率和效果不好,而是它受互联网更易规模化的特性以及与产品的受众共同制约了上限。

基于这2点的推导,要持续创造价值,深入运营也就势在必行了。

04 应该怎么深入运营?

这一点是正在尝试的环节,权当参考罢。

从业务中来,回业务中去。这件事情,说起来简单但做起来很难。如果说没有手握重要的资源,业务是不会让你深入参与或者干涉的。

目前思路是:掌握长尾业务,其目的是希望对核心业务拥有话语权。

不选择从核心业务着手,更多的原因是不能。没有成绩,没有基础想占下一席之地会消耗很多的人际关系。在这样的条件下,不如换条赛道,在敌人不在的地方打败敌人。

而发现长尾业务的方式,首先要建立自身的度量方式,这个部分的答案可以参见《用户运营体系的推导思考》

我们需要知道目前的运营状况是怎样的,需要了解哪部分群体已经被运营干预且有成效,才能瞄准未被运营或成效低的群体。

基于此查漏补缺,再制定策略并获取成效,然后再以业绩及方法输出至核心业务。

这是目前B端产品基于深入运营的答案了,但还是感觉困难重重,希望在实践中出真知吧。

写在最后

要打败焦虑,我的方法是明晰焦虑的缘由,并尝试应对。

但不应对也并无不可,业务总是从无序到有序,从初生到成熟。如果说总会面临这个时刻,不妨保持耐心,把时间更多的交给自己。

我最近也看了很多的书,感觉也很充实,最有意义的事情身体健康、平日快乐。

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部