在产品推进过程中，遇见太多太多的大规划，但这些，在具体产品迭代过程中，用于限定需求范围可行，规划与实际计划不符却不可取。成熟的产品迭代团队，每一期迭代一般会有相对固定的周期。尊重时间周期和需求范围，做好当期需要实现的内容，不过于蔓延需求，机动时间合理，方可称不负韶光。

做B端产品的痛与苦

如果你跟一个负责B端产品的朋友喝下午茶的时候，他不小心走神了，请你大方的原谅他吧。

哪怕他人在你面前，他的脑子里与跟你唠嗑同时并行的事情，可能不下10项：

嗯，对面这人在问我奶茶好不好喝，咦，怎么又说到了熔断，熔断是啥？

后天这个产品版本上线，还有5个重要bug得改，不然不能上线。

下个版本里得做20个需求，数据权限下沉得涉及多个部门，该怎么推进呢？

某服务的供应商不是说今天上线这个功能嘛，都这个点了还不通知我们准备，今天还能上线吗？

完了，A项目和B项目会议时间冲突了，怎么办？

C项目好像也要上线了，当时的需求是什么来着？

有个研发资源好像要被释放了，好几个产品线和项目在争抢，怎么才能让他来我们团队呢。

……

焦虑啊~

有人感叹，我有丰富的理论知识和实践经验，在做下一个项目的时候，怎么还是不敢保证成功呢？

是呀，项目如流水，哪怕看上去很相似，下一个也不是这一个。知识和经验可做参考，却没法照本宣科。

没头绪啊~

不过有丰富的知识和经验，整个团队又身心投入地为产品和项目的推进付出的话，成功概率总会高些。

读过国内国外的产品项目书籍并做过对比的朋友应该能够感觉到，国内讲产品或项目的时候，会偏向于抽象理论、拔高高度，比如著名的产品人梁宁老师会讲“宏观视野、中观套路、微观体感”， *** 之父马化腾会讲“Don’t Make Me Think”；而国外讲产品或项目的时候，会把一句话，写成一本书。

“Don’t Make Me Think”这句话，在国外的书里会写的时候，光目录可能就有下边这么多：

产品体验的更高境界是，用户不需要思考就能知道下一步怎么做；

为了实现这一点，作为某某某角色，要在之一步第二步第n步做到这个那个另一个；

实现了这些，基本能将产品体验做到多少分；

某一步没实现，会将产品体验降低多少分；

针对什么样的产品，可以应用哪些步骤来执行；

吧啦吧啦吧啦……

一个说的那么多，一个说的那么少，到底怎么实践啊~

解决B端产品推进的痛点

上边赘述的篇幅有点多，实在是亲身感受，痛之又痛，没忍住就唠叨多了。

汇总下做B端产品的痛点：

B端产品业务复杂、定制化高，同阶段并行的产品和项目可能有很多个，资源有限的情况下，资源该怎么分配，产品该如何迭代？

项目管理过程中，进度、质量该怎么把控，已实现功能该怎么复用在其他项目中？

产品和项目上的知识和经验，怎么才能更好地体现在产品中？

在B端产品推进的过程中，大大小小的问题多到数不胜数，要行之有效的解决问题，还是需要知识和经验的积累和传递。

在推进产品进展的过程中，是有规则可遵循的，可总结为：识别相关方、主动学习、尊重流程、明确优先级。

在产品经理基本素养过关的情况下，将上述4点把控到位，产品推进中可能遇到的可预知或不可预知的问题，在解决的过程中，方向和边界基本可以保证不会偏离。

（1）识别相关方

个人认为这是最重要的一点，识别错相关方，所有努力都白费。

（2）主动学习

产品经理往往承担产品推进和项目管理等多方面的工作，主动学习各方面的知识是必要的。

了解与你沟通的人希望在你这里获得什么帮助并表述清楚，是很重要的一种能力。

一些做B端产品的公司，会拿业务领域的经验作为门槛设置 *** 要求，想要进入B端发展的产品经理们，也常常因为业务知识及经验的不足望而却步。但实际上，业务知识及经验诚然重要，更重要的却是快速并合理使用业务知识及经验的能力。

（3）尊重流程

尊重流程，包括尊重流程中的人、组织以及流程本身的知识项，共同遵守规则，才能有效的保质保量完成任务。

每个公司，都有自己的项目管理或产品管理流程，这些流程，是公司团队间长时间磨合一点点积累下来的财富。