产品经理和业务方是一种怎样的关系?

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

“擦!又来一个需求?不是上个月刚提了XX需求,让往西吗?怎么今天又让往东了?”

是不是老感觉被业务代表牵着鼻子走?产品经理的工作难道就是去实现业务方提的需求?很多产品汪都会遇到这个问题,不知道如何拿捏和业务方的关系,太听话会被牵着走,太叛逆又会被责怪不了解业务需求。

chanpjingliyuyewu

关于产品和业务方的关系如何拿捏这个话题,让我们分两个部分来解答:

一、 业务方和产品经理的职责范围

业务方:

  1.  当然最重要的还是提需求啦~ 但是仅仅只是需求,不是指使你设计什么功能,按钮怎么摆放,不然就会沦为伪需求。
  2. 提供业务场景,阐述现有业务流程,对产品提出的新的业务流程进行确认。这一点,在我看来是一个合格的业务方需要做的最重要的事情。不要瞎BB,有效利用起产品提供的服务,保证业务流程的畅通,这才是业务方的主业。获取需求的神书《掌握需求过程》里说,“业务范围大于产品范围”说的就是这个意思,在一个完整的业务流程中,产品不可能完全cover所以业务场景,所以业务方和产品在立场和认识上肯定存在差异,但是双方需要站在对方立场考虑。
  3. 产品上线前验证。当然,这个动作,也是可以由产品来完成的。如果这个产品是为了满足一个新的业务流程里的新需求,这个验证的动作可以由业务代表来完成。

产品经理:

  1. 梳理业务需求。思考业务方提出的需求背后的含义,也许他说想要建一座桥,但其实他只是想和河对岸的人说一句话,那这样解决方案就不止建桥这一种了嘛。
  2. 需求优先级排序。需求很多,很零散,怎么组织他们,找到彼此之间的关系,排序,确保你所做的事情是当下最紧急且最重要的事。
  3. 产品规划,确定产品边界。在前面提到,业务边界大于产品边界,因此,产品经理在设计产品的时候,需要考虑有限的开发时间,能搭起多少块砖?需要如何演进优化,建成一栋楼?
  4. 产品设计,这里包括了很多,包括界面交互设计,抽象业务实体设计,数据库表设计(新系统),功能扩展的考虑,信息架构设计(包括导航,页面层级,搜索),太多了,妈蛋,才发现产品经理需要做这么多事。
  5. 产品推广。类似于公关的角色,这时候颜值高可能会发挥点小作用,哈哈。
  6. 应付上下游系统的产品。一方面,你出去找接口的时候,就是出去化缘嘛,想办法应付下嘛,高度拔高,让人家不得不把家里的馒头拿给你。另一方面,其他人找你拿接口或者改字段的时候,你就随机应变吧,太不靠谱的事,从系统定位,项目边界这些角度忽悠吧。

P.S. 产品经理和业务方不是对立面,两者的工作职责不同,却有交集,不能任何一方处于绝对强势的地位,否则设计出来的产品就会过于偏激,要么就是过于简单的满足目前业务需求,要么就是脱离业务变成了空中楼阁,设计的再好也没有业务价值。

二、 业务边界和产品边界

前面说的业务需求和产品设计不一定长一个样,业务方不应该牵着产品的鼻子,让他做一个四不像出来。举个例子,前端时间遇到的,涉及到公司业务,这里的一些细节就不方便细说了哈。

是这样的,业务方提出要在系统上加一个模板,因为政府新出的政策,要求供应商按照新的模板提供材料。但是这个材料供应商之前已经提供过了的!难道还要他们再提交一遍?显然这并不是一个产品的total solution。

首先,政府政策经常变,难道每次变,我都要改一次吗?能不能做一个后台配置功能,一旦有新的政策,只需要人在后台添加就好了。

其次,供应商需要配合做这么无效率的事情吗?第一次提交的材料完全不能用了吗?能不能利用供应商第一次提交的那些字段,根据后台设置的规则,自动抽取需要的字段,这样就可以满足新政策的需求了。

再次,后台的规则,谁来负责配置?一般来说,产品是不负责数据的维护的,那能否提供一个入口,给相关的业务方权限来维护,底层数据服务可以放在我们系统。

以上,是我们的产品思路,对比一下,和业务需求差别还挺大吧。这也是一个产品的价值。

 

本文由 @旧无痕 授权发布于人人都是产品经理 ,未经许可,禁止转载。

您的赞赏,是对我创作的最大鼓励。

评论( 0

登录后参与评论
加载中