“擦！又来一个需求？不是上个月刚提了XX需求，让往西吗？怎么今天又让往东了？”
是不是老感觉被业务代表牵着鼻子走？产品经理的工作难道就是去实现业务方提的需求？很多产品汪都会遇到这个问题，不知道如何拿捏和业务方的关系，太听话会被牵着走，太叛逆又会被责怪不了解业务需求。
关于产品和业务方的关系如何拿捏这个话题，让我们分两个部分来解答：
一、 业务方和产品经理的职责范围
业务方：
1. 当然最重要的还是提需求啦~ 但是仅仅只是需求，不是指使你设计什么功能，按钮怎么摆放，不然就会沦为伪需求。
2. 提供业务场景，阐述现有业务流程，对产品提出的新的业务流程进行确认。这一点，在我看来是一个合格的业务方需要做的最重要的事情。不要瞎BB，有效利用起产品提供的服务，保证业务流程的畅通，这才是业务方的主业。获取需求的神书《掌握需求过程》里说，“业务范围大于产品范围”说的就是这个意思，在一个完整的业务流程中，产品不可能完全cover所以业务场景，所以业务方和产品在立场和认识上肯定存在差异，但是双方需要站在对方立场考虑。
3. 产品上线前验证。当然，这个动作，也是可以由产品来完成的。如果这个产品是为了满足一个新的业务流程里的新需求，这个验证的动作可以由业务代表来完成。
产品经理：
1. 梳理业务需求。思考业务方提出的需求背后的含义，也许他说想要建一座桥，但其实他只是想和河对岸的人说一句话，那这样解决方案就不止建桥这一种了嘛。
2. 需求优先级排序。需求很多，很零散，怎么组织他们，找到彼此之间的关系，排序，确保你所做的事情是当下最紧急且最重要的事。
3. 产品规划，确定产品边界。在前面提到，业务边界大于产品边界，因此，产品经理在设计产品的时候，需要考虑有限的开发时间，能搭起多少块砖？需要如何演进优化，建成一栋楼？
4. 产品设计，这里包括了很多，包括界面交互设计，抽象业务实体设计，数据库表设计(新系统)，功能扩展的考虑，信息架构设计(包括导航，页面层级，搜索)，太多了，妈蛋，才发现产品经理需要做这么多事。
5. 产品推广。类似于公关的角色，这时候颜值高可能会发挥点小作用，哈哈。
6. 应付上下游系统的产品。一方面，你出去找接口的时候，就是出去化缘嘛，想办法应付下嘛，高度拔高，让人家不得不把家里的馒头拿给你。另一方面，其他人找你拿接口或者改字段的时候，你就随机应变吧，太不靠谱的事，从系统定位，项目边界这些角度忽悠吧。
P.S. 产品经理和业务方不是对立面，两者的工作职责不同，却有交集，不能任何一方处于绝对强势的地位，否则设计出来的产品就会过于偏激，要么就是过于简单的满足目前业务需求，要么就是脱离业务变成了空中楼阁，设计的再好也没有业务价值。
二、 业务边界和产品边界
前面说的业务需求和产品设计不一定长一个样，业务方不应该牵着产品的鼻子，让他做一个四不像出来。举个例子，前端时间遇到的，涉及到公司业务，这里的一些细节就不方便细说了哈。
是这样的，业务方提出要在系统上加一个模板，因为政府新出的政策，要求供应商按照新的模板提供材料。但是这个材料供应商之前已经提供过了的！难道还要他们再提交一遍？显然这并不是一个产品的total solution。
首先，政府政策经常变，难道每次变，我都要改一次吗？能不能做一个后台配置功能，一旦有新的政策，只需要人在后台添加就好了。
其次，供应商需要配合做这么无效率的事情吗？第一次提交的材料完全不能用了吗？能不能利用供应商第一次提交的那些字段，根据后台设置的规则，自动抽取需要的字段，这样就可以满足新政策的需求了。
再次，后台的规则，谁来负责配置？一般来说，产品是不负责数据的维护的，那能否提供一个入口，给相关的业务方权限来维护，底层数据服务可以放在我们系统。
以上，是我们的产品思路，对比一下，和业务需求差别还挺大吧。这也是一个产品的价值。
