如何在业务主导的公司做好产品经理?

本文是作者对业务主导、产品经理话语权、成长方向的一些看法,如果你也有这方面困惑,不妨看看~

一、决策权

最近关于业务公司产品经理的争论很凶,我也聊聊我的看法。

鄙人不才,刚巧就是在业务主导的公司里做产品经理,而是偏业务线的产品经理,还做超过了3年。所以对于这个问题应该是有发言权的。

在业务公司做产品时,最大的质疑就是,你都没有决策权,你还算产品经理吗?

这个事我是这样看的:首先来说,没有决策权是复杂条件造成的,并不能完全把这个锅甩给业务主导。举个例子来讲,自上而下的决策机制,也会导致产品经理失去决策权,一切都领导说了算嘛反正。

所以业务主导,只是减少产品经理决策权的一个主要因素而已。

那么真实的场景是什么样的,产品经理真的失去了决策权吗?首先把一个产品立体来看,底层是业务逻辑,只不过很多C端产品的业务本身就是产品团队或运营团队。所以他们会有很大的决策权,并且很多时候都直接合并为产品运营岗,就是为了决策权不分散。

二、业务逻辑

底层之上,是产品逻辑。产品逻辑和业务逻辑什么区别呢?举个例子来讲,对于一个智能招聘系统来说,HR团队是业务团队,他们背负了招聘率、差评率等等好多指标,也决定了招聘规则和流程。也就是说这套业务规则是业务团队掌控的,统称为业务逻辑。

而业务逻辑,会成为产品经理的一道命题作文题。也就是说,你的想法再多,再正确,不能超于命题之外,否则也是零分的。

那么产品逻辑是什么呢,在这个业务框架下,产品经理究竟能做什么呢?

首先第一点就是,要抓住业务这个命题,确定你的中心思想。也就是说,你的一切产品逻辑,都是为了业务指标的提升而设计的。

如果业务要提高招聘率,你就要把投递简历的渠道同步变得极其强大,把整体招聘系统的效能提高到极致。但这个时候,就衍生了两个问题:

1. 业务指标我不认可怎么办?我的产品指标是什么?

其实往往来说,业务指标和产品团队的指标就是不太符合的,并且产品经理往往对业务指标不太敏感,这就容易造成产品经理和业务的互相不信任。

从业务的视角来看:你这个产品经理可有可无啊,我底层逻辑已经给你了,你还跑出来做拦路虎,这不是影响业务吗?

而从产品经理的角度来看:你的底层逻辑虽然有,但是缺乏产品感,很多东西没有用户体验,商业和数据价值也不够,肯定需要完善啊!

这样一来一回如果没有对齐口径,就会加深两方的误会,那么解决方法是什么呢?

鉴于这是一个天然的冤家问题,我们就只能采取缓解化解的手段,而不是硬钢。老实说,在业务主导公司内部,任何试图抢占主导地位的团队,最后好像都很惨。

所以化解的角度来说,就是多找业务谈心,把他们的诉求当作自己的诉求,把他们的指标变成自己的指标。如果遇到方案上的摩擦,一定要不卑不亢。如果你选择卑微,那你得不到业务的尊重,他们会更加觉得你可有可无。如果你太亢进,对方又会觉得你越界,扮演了拦路虎。

不卑不亢这个境界,是我们具体情况具体分析才能达到的一种状态,所以在这里只能给一个方向,毕竟这个状态很多产品经理做了10年都没有达到。

2. 业务逻辑我想改变怎么办?

这一点其实可以算作一个命题,也就是科技转型。我一直认为,科技转型不是要转变为科技驱动,而是科技的数据思维、产品思维能够内化到业务团队当中去,变成业务决策的一大因子,这样才能起到科技驱动的作用,才算完成了转型。

业务仍是主导,科技也无需和它互相替代,只不过更加加深了底层的合作。

对应到这个问题来看,就是产品经理要尽早主动地参与到业务的决策当中去,贡献出自己的意见。这点实现起来其实特别难,举个例子讲:业务一般会提交很多需求给到产品经理评估、落地,这个时候其实产品经理的时间已经被占满了,如果再介入业务,工作量上讲其实是超量的。

为了解决这个问题,一般科技转型都会提出一个办法,叫做“拥抱业务”。拥抱业务指的是,科技人员向业务团队靠拢,但怎么靠拢呢?是直接取消产品经理,研发直接对接业务吗?不是的。

拥抱业务绝对不是减少流程和环节,而是把所有的职能业务化。比如:产品经理更多地参与到业务决策,而RD更多地参与一些产品经理需求分析的工作,这样环环相扣,大家就把业务的工作量逐层承接传导到了研发层面。而业务多出来的时间,可以用来了解研发团队。这样一个工作量的平移,就可以带来整体科技元素的比重,以及产品经理参与度的提升。

所以老实说,有几个命题一定是正确的:

  1. 只会产品、技术、设计但没有某个领域业务深耕经验的产品经理是无价值的;
  2. 在没有科技转型战略的业务型企业,产品经理想靠个人努力站主导地位是不现实的;
  3. 产品文化和工程师文化到最后都是回归业务,C端个别如搜索等领域技术本身就是业务。

三、产品逻辑

那么产品经理能做的是什么呢?

首先从日常工作流程来讲:

其实跟做C端一样,也是了解业务。只不过C端的业务就是流量运作,包括增长和留存还有转化。而B端就是了解这门生意是怎么运作的。而研究流量运作,最重要的就是看数据、做分析、想方案。而研究一门生意,要看的不仅仅是产品数据,要做的还有业务数据指标和业务场景访谈、用户调研。

鉴于此,我们工作的形式就有差别。做C端产品时,要多看数据多分析。做B端产品时,要多调研访谈。之前做C端时,我几乎每天80%的时间都在看数据,写文档。现在做B端,我几乎要花大半天时间调研问题再找人办事。所以千万不要认为只有写文档才是正事,开会和聊天可能更重要。

最重要的是需求运作模式就完全不一样了:

业务主导的研发团队来说,因为业务支持都是P0级别的第一时间响应要求,所以业务提出一个需求,只需要跟领导汇报,然后强压给研发团队即可。而产品产出的需求,需要内部上级汇报、总监汇报,再由总监和业务老大碰,碰完之后再跟业务自己提的需求PK。

支持需求和自发需求相比,一个是一级汇报,一个是四级汇报,时间周期和效率都没法比,所以产品经理觉得累,觉得自己想做点事情非常难。

但这样有没有好处呢?好处就是产品经理的沟通技巧要求非常之高,业务主导公司是一个很好的提高沟通技巧的环境。对于四个层级的汇报,你要准备不同角度的材料,再充分考虑好每层级汇报可能的后果,可能的需求变更和修改时间,最后来算算自己的需求什么时候可以上线。这样流程下来,一个好的方案一定是具有很高价值且经过多方打磨的方案。

总结

所以我提了一个问题,产品经理到底是决策者还是执行者?

我个人倾向于后者。我觉得决策其实没有我们想象的那么重要、那么必不可少,而执行的过程也没有我们想象的那么固定和不可操作。很多时候命题命好了,能不能挖到价值才是你的本事。

最后给大家一点建议:决策和执行都只是形式层面的人为区分,所以我觉得产品经理最重要的不是决策也不是执行,而是迅速搞清楚团队的所需,然后补充上去。这个补充的形式可能是产品规划、项目管理、微决策或是会议组织,但只要是能提升用户体验和商业价值的活,都值得一做。

那么产品经理的核心竞争力是什么呢?

我觉得就是迅速切入一个行业、一个团队的能力,这个能力需要很高维度的思考模型、很深层次的经验来支持。所以日常我们一定要关注每一个项目,不断问自己能不能做到更好。

实践永远是最重要的。产品之术之所以有这么高粘性的关注者,就是因为我不是为了写而写,脱离了实践的写作和命题,本身对于自我和他人都是没有帮助的。只有从实践中的总结,才有个人特色,才有经验价值,才能形成输入和输出的闭环。

所以遇到任何问题千万不要第一时间拿自己的现有知识去套,这样只会让你陷入想当然和不理解,但多实践、多感受、多摸清楚问题后,才能看到真实的世界,这个时候再总结思考才有意义。

以上是我对业务主导、产品经理话语权、成长方向的一些看法,如果你也有这方面困惑,不妨参考尝试一下,也可以随时和我交流。

与君共勉。谢谢!

#专栏作家#

花生酱先生,微信公众号:产品之术,人人都是产品经理专栏作家。金融业资深产品经理,对职涯规划与个人发展有丰富经验,产品涉猎广泛,ERP、金融领域较多。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 产品是一条线 呈上而下 很重要。

    回复
  2. 如果作为产品的业务知识比业务还理解深刻,他就听你的了。当然,这很难。

    回复
  3. 谁来主导并不重要,重要的是能把需求搞清楚,综合内部的开发资源、业务目标,提供最佳的产品解决方案。我相信谁主导并不重要,除非有人在捣糨糊

    回复
  4. 业务主导最终的目标是业绩更好。
    感觉产品经理更深度的思考应该是怎么利用自己的价值为最终目标服务,而不是纠结话语权和怎么适应业务主导体系。
    产品最大的价值是深度观察、思考和决策,如果连这些都放弃,为了去适应一个体系或者就是去做一个执行者,感觉…

    回复
  5. 所以,到底说出来了什么呢?
    产品应该有还不是应该有?

    回复