B端产品经理与业务方的相爱相恨

9 评论 6548 浏览 38 收藏 10 分钟

和对口的业务打交道时B端产品经理的日常核心工作,工作中双方难免会遇到一些争执与问题。如何看待这些问题?本文笔者分别从业务方、产品经理的角度,梳理了各自的槽点和辩驳,一起来看看吧。

不论是从事企业内部软件建设,还是对外售卖的SaaS软件设计,和对口的业务方打交道,是B端产品经理日常核心工作之一。前者的业务方一般是业务运营部门,后者的业务方一般是销售、BD、客户成功部门。

很多时候,B端产品经理和业务方如何顺畅高效的协作,一直是各个公司和团队普遍面临的挑战和困难。因为两者之间工作的边界往往存在重叠,权责也有模糊地带,这就导致有时候工作中会出现一些小争执,小摩擦,甚至产生冲突。

本文尝试分别从业务方、产品经理的角度,各自描述槽点和辩驳,希望大家都能够换位思考,理解彼此。

业务方如何看待产品经理和研发团队

槽点1

研发效率低——产研团队是事情最多的团队,提个需求要排期,做一点小功能也要排期,实在不理解为什么,改个小东西,如果稍微走点心,难道不是我早上说完中午就该上线么?效率这么低,肯定都在偷懒磨洋工。

辩驳:业务人员往往不理解软件工程的复杂性,严谨性,研发工作非常讲究节奏型和计划性,你们看起来的一个小功能点,如果非要加塞做,小到影响研发节奏,大到影响代码质量,我要是同意你了,研发爸爸拿刀砍我,你帮我挡刀么!

槽点2

产品经理不懂业务——产品经理不理解我在说什么,提个需求解释半天,最后做出来的东西完全不是我想要的,完全没有解决我的问题。

辩驳:产品经理需要有机会去接触学习业务,如果不给我们机会,让我们远离一线和终端用户,那么我们如何学习了解业务呢?

槽点3

做的东西不好用——设计的什么玩意儿,用起来非常别扭难用,一点都不人性化,完全没有陌陌和淘宝好用,这些人都得给开除了!

辩驳:你们要的那么急,给的时间这么有限,能做出来让先用起来,就已经不错了,还那么挑剔,要求美观好用,没门儿!(当然,我也需要多用心,设计前多搞搞原型,上线后自己去一线体验并实操,有时候我发现,我设计的东西确实很垃圾难用,哎,扎心)

槽点4

遇事不变通,比较轴——这帮搞技术的,都非常轴,一点不知道灵活变通,而且容易较真,很难相处。

辩驳:这事儿我认,如何用合适的手段和技巧,解决问题,推进事情,确实需要多用心实践。就像我总吐槽码农比较轴,实际上业务人员可能也认为我们轴。如果想和业务部门合作好,那就必须以业务人员的思维一样去考虑问题、去做事情。

产品经理如何看待业务方

槽点1

需求不明确——有时候根本搞不清楚你们一天到晚在想啥,经常拿着个idea就跑来让我们做,我三句话就能给你问回去,哎,真是浪费时间!

辩驳:我们是应该先想清楚,但某些时候你们确实也更专业,专业的你们帮助我们一起让事情靠谱,难道不是你们的责任么;如果我把需求想明确了,那么我还要产品经理干啥呢,配个需求分析师直接写软件设计文档不就成了么。

槽点2

思维发散,没有逻辑性——你们为啥毫无逻辑性呢!我们做的是软件项目,和代码打交道,如果没有逻辑,计算机怎么知道该做什么?我怎么知道该怎么设计?

辩驳:业务人员必须发散、天马行空、喜欢试错,否则KPI压力这么大,我怎么知道干什么肯定能成功,还不得各种发散各种尝试么!

槽点3

提需求总带着解决方案——拜托你们直说问题,别说方案,方案我这里给!

辩驳:习惯性的提出问题和方案,这不是人之常情么,我也控制不住啊,你是专业的产品经理,你存在的目的之一,不就是引导我说出深层次的问题,并给出更好的解决方案么,如果你给不出解决方案,那你也得有心胸能接纳我的解决方案啊!

槽点4

业务三天两头变——刚刚信誓旦旦的设计了业务方案,提交了需求,我们这还没上线呢,然后你告诉我业务变了?不做了?

辩驳:我们是互联网公司,三天两头变不是常态么?我们应该一起研究如何最小成本试错,而不是拒绝试验失败和变化。

槽点5

对产品参与业务有所抗拒——你们对我们好像有所抵触,不太愿意让我们走进业务,如果这样,我们怎么能理解业务,并帮你们呢?

辩驳:如果你们真心为了业务好,真心为了帮我们,而且又有这样的能力,那么,即便公司不给机会,我也会给你们创造机会深入一线,帮助我们一起做好业务的!

槽点6

领赏你来,背锅我去——哎,这个最伤心了,每次吭哧吭哧捯饬完,项目成功了,庆功会我总是只能看图片直播的那个人。

辩驳:这个确实是我的问题,我们是一个团队,我不辩驳,我改!

最后

上边列了这么多吐槽,不知道你是否有所感触呢?如何让大家配合的更好呢?这个话题比较复杂,从公司文化,到组织架构都有影响,我们简单的列出一些建议,有更好的想法,也欢迎大家留言补充。

  • 保持一致的目标(共同的KPI,或OKR);
  • 搭档而非上下游(组织结构的设计,信任的建立);
  • 开放协作的气氛(产品经理有机会深入业务,参与业务);
  • 跟踪每个需求和项目的效果(如使用情况,业务收益等,通过机制倒逼合理决策);
  • 产品经理要为结果负责(驱动并承担业务结果,而非功能交付)。

好了,关于产品经理和业务方的相爱相恨,就讲这么多,你有什么想法和观点,或者吐槽呢,请留言分享啊!

插播一条广告

大家好,我是《决胜B端》作者杨堃,曾在VIPKID任产品总监一职。在工作中,遇见有很多优秀的B端产品经理,但缺少体系化、针对B端产品的实操训练,在成长中走了许多弯路。

我努力将自己多年做B端产品的经验提炼总结出来,和起点学院联合打造了一门B端产品体系课——《To B产品实战训练营》希望能给需要的同学一些实质性的帮助。

帮助大家构建B端产品知识体系脉络,掌握B端产品建设,从业务诊断、需求分析,到抽象建模、设计落地的全过程的方法思路,最终直接应用于工作实践。

扫码即可报名,还可为大家争取到的专属优惠~

立即抢座,报名成功后即可领取详细课程资料!

作者:杨堃,《决胜B端》作者;公众号:PM杨堃(ID:pmYangKun),11年互联网研发、产品设计经验,曾就职于传统外资保险公司、百度,现就职于vipkid。

本文由 @杨堃 原创发布于人人都是产品经理。未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 挺好

    回复
  2. 即将转岗为B端产品经理

    来自云南 回复
  3. 不论是B端还是C端,做个懂业务的产品经理太难了,老师有什么了解业务的好方法吗?

    来自安徽 回复
  4. 保持一致的目标(共同的KPI,或OKR);
    搭档而非上下游(组织结构的设计,信任的建立);
    开放协作的气氛(产品经理有机会深入业务,参与业务);
    跟踪每个需求和项目的效果(如使用情况,业务收益等,通过机制倒逼合理决策);
    产品经理要为结果负责(驱动并承担业务结果,而非功能交付)

    说的很实在,保持目标一致很重要

    来自陕西 回复
  5. 产品经理要对技术爸爸负责

    来自福建 回复
  6. 文章先收藏着,等到后续接触到业务拿出来再看一遍

    来自江苏 回复
  7. 1、需求评审:跟业务方对接需求的时候,会有好几次的确认和评审,交互原型完成时会给客户演示确认,确认没问题会输出需求文档,再进行细节确认,需求都完成后再确认设计稿,至少有三次确认机会,确认时候不发表意见,或者说先按你说的做,没啥大问题,有小变动到时候再改。结果上线了,说这不是我要的,你没理解我的要求,推翻重做。早干嘛去了,每次评审会时怎么不反馈呢,自己想要什么不清楚总让先做,推翻重做说的轻巧,开发要骂人的。不用业务方承担开发成本的,都是耍流氓,如果他们给研发发工资就知道心疼了。
    2、催几号上线:跟你说完需求就开始问几号能上线,你跟我说完我要梳理之后开发才能评估时间呀,哪能那么快就出项目计划,需求分析和方案设计不要时间的呀。甚至倒排期:不管需求实现难度和功能点多少,直接给定一个日期,不管你们加班也好还是怎样也好,就是这个时间点要,这种一般是业务方领导给了他们压力。产品协商砍一些优先级稍低的需求,不让步,这是要往死里逼开发呀。
    3、优先级排序:时间紧迫时请业务方排优先级,都给排成1,这排了跟没排有啥区别,总是不愿意做取舍。
    4、功能设计时恨不得考虑未来各种场景,要求系统能灵活支持,本来时间就紧,顾好目前的业务支持,后面的场景遇到了再做不行么。
    5、所有业务方不直接使用的功能在他们看来优先级都很低可以一直往后放:比如因为产品发展而要考虑的组件剥离独立维护,系统性能优化等等。

    来自湖北 回复
  8. 分清角色定位与分工
    业务童鞋的本质工作:梳理业务逻辑,反馈业务痛点,表达业务期望。而不是 设计产品方案,比如在这个页面上加个字段
    产品童鞋的本质工作:深入了解背景,挖掘核心需求,设计产品方案。而不是 原型工程师,PRD编辑员。

    来自北京 回复
  9. 太扎心了,以前没有感受,自从在客户那工作了半年多,看了这个,简直段段都要惊呼:是我!尤其是业务方的槽点二。。。另外还有一个比较恶心的现象了,就是每次客户觉得上线后达不到他们想要的(鬼知道他们想要啥),就开始抓考勤,开晨会。。。唉,说多了都是泪555

    来自北京 回复