小的项目自己团队闭环，在给定的用户范围内试试水，大的项目一般需要面对更多的用户

预备动作1：确定需求

现在的2C产品很少有被做出来后，由产品经理自己负责去做推广。毕竟你有渠道嘛？有推广资金嘛？你能服务用户嘛？你能自己举办活动嘛？

小的项目自己团队闭环，在给定的用户范围内试试水，大的项目一般需要面对更多的用户，以及更大的影响面，就需要由外部力量一起来推动。你的想法最好有实际应用的业务方来支持。

2B业务的产品经理自主性会更强一些，可能会发起比如平台升级，架构优化的项目。

但依旧牵一发而动全身，这种项目的难点就在于如何说服高层，为什么要在这个时间点做这样一件事情，如果高层认可，下面支持，需求自然就确认了。

在有明确的业务方后，一定要深刻的理解业务方的需求，主要从以下几个方面入手：

1. 需求来源的依据是什么，是否已经有历史数据、测试案例；
2. 确认需求是短期（临时）的还是长期的，紧急的还是可规划的，这将直接影响大家做出来的方案是临时的还是持久的；
3. 如果有多个业务方，可以要求业务方按部门需求进行合并，比如市场、运营、客服等部门同时希望在双十一有一个联合售卖项目，如果能够有时间逐个沟通最好，但之后是需要选择出一个业务代表，减小沟通量；
4. 其次需要对其中的重复需求进行整合，进行抓大放小，排好优先级，小需求根据实际情况进行降级处理；如果业务方不同意，则需要给出相应的理由；
5. 最后一定要让业务方给出预期收益，同时也要配合业务方保证收益的合理性。

作为产品经理的专业性需要体现在尽最大程度的满足业务方的需求，同时又花相对较小的代价，以及能够兼顾未来的拓展和可复用性，最后是预估的收益是可计算可预期的，而不是拍脑袋。

否则在之后的环节，将极易受到挑战，举俩个例子：

1. 你这个需求有没有先验证过？能不能做个简单的页面看看有没有用户点击？如果没有，请先做个MVP，否则后续的环节就无法推进展开；
2. 这个项目的收益是否够大，足以说服其它的团队一起参与。或者有高层领导的明示，有很多项目是高层领导出于实验性质的，希望能完成一个从0到1的流程，那么收益就不可能太高，甚至本身是公司的未知领域，收益都无从估计，这种情况是一定要狐假虎威的来拿到高层授权的。

之前说的那个小兄弟，既没有验证会员在当前公司用户的意向，自然也无法给出一个令人满意的项目收益，即使高层觉得项目有价值，但还是无法评审，导致项目延期。所以这个环节请大家先跟业务方一起，细致讨论。

如果以上动作都做完了，就可以进入到下一个环节，组建核心团队。

二、预备动作2：成立核心团队

漫威电影中的超级英雄即使拥有有宛如神明的力量，在面对更强大的敌人时也会组成《复仇者联盟》，组成一个团队，做各自擅长的事情。

同样的，产品经理在面对这种跨端项目时也需要一个核心团队来支持自己，一般会有以下几个主要角色：

其中主产品经理是整个项目能够顺利完成的关键。在跟各产研团队沟通需求的时候，能够代替业务表达需求的必要性；跟业务沟通产品方案的时候，能够代表各部门的产品研发提出可行性。

否则每次开会都得叫上十几个人，低效的开会，频繁的讨论将是项目推进的巨大阻力（当然这不代表不能拉这么多人一起开会，防杠所以请读者自行领悟），这就要求主产品经理对整个项目有深刻的理解和把控能力。

前面的业务需求聊完了，自然就要开始跟具体的产研团队的小伙伴们干活啦。

三、开始推进项目

1. 拆解需求，沟通需求

除非公司很小，现在的大公司各个部门都有自己专注的领域和负责的业务，甚至比较过分的则是有些基础部门在公司的内部形成了一定的壁垒，他人与之合作时，更像是调取了一个第三方公司的服务。

如果这种服务真的足够完善还是挺方便的，但因为这些部门一般只服务公司内部，其完善性、与项目的匹配度、稳定性都有一定的折扣。所以我们需要将需求进行仔细的拆解，与各部门耐心的沟通，沟通的主要目标：

• 核心团队，熟悉整个业务流程的实现；
• 与实现各业务环节的团队进行沟通，补充和完善业务流程；
• 了解各团队近期的工作重点，确认各端关键负责人；
• 核心团队讨论从各团队收集来的方案，根据实现成本和可持续性等维度，讨论最终的产品方案；
• 确认业务数据在各端是否可以准确拿到。

外加笔者之前的一些讨论技巧：

1. 从业务方的需求出发，和各部门一起绘制业务流程图，画到他们的边界；
2. 根据业务流上的关键节点进行展开到各部门、组织；
3. 在与各部门的沟通中，了解各环节中的上下游，判断这种依赖是否会影响到本项目，如果影响则添加到项目中，不影响，则由各环节各自去闭环；
4. 在与各团队讨论需求时，多讨论几种方便、简单的、复杂的、临时的、长期的、低成本的、高成本的等；
5. 初次与不熟悉的部门讨论需求时，需要与该部门较资深的同学一起讨论，避免因为双方不了解造成的沟通歧义，之后可以选出该部门的关键对接人，来承接己方需求即可（可能是产品经理，也可能直接的研发负责人，根据团队特性来定）减少之后的沟通成本；
6. 以上的讨论至少需要带主研发一起，根据情况带上主测试和PMO，需要他们一起理解整体项目的架构，便于之后评估整个项目的实现成本；
7. 不要跟各团队在此阶段过多的讨论收益，只讨论实现成本和可行性方案，否则最终项目的实现方案难度超过了项目需求，讨论将变得没有意义。

举个例子：

这一块的需求沟通环节是整个项目的重中之重，所以笔者这里需要拿一个简单的案例来说明一下，以上线一门课程进行售卖的需求为例：

1）第一步，根据当前的认知绘制业务流程，依次有：

• 课程配置，做一门新课，需要在平台里配置一些课程信息，以及必要的学习环节等；