从0到1搭建B端产品，我的总结与体会

人人都是产品经理 · 公众号 · 产品 · 2017-04-14 21:04

正文

其次需要熟悉为什么要有这个产品，打造这个产品的初衷是什么？为了解决当时的什么问题？有和没有这个产品对实际业务有什么影响？提高人效是否可以量化（如：没这个产品办一件事需要1小时，有了这个产品后，办相同的事只需要 1 分钟）？整个产品的未来规划是什么？

尤其是 B 端产品，要紧跟公司的战略发展，必须熟悉了解公司当前的战略发展是什么，最重要的战略合作伙伴有哪些，这个产品在公司战略发展中起到什么样的地位。

相信对这个产品有了以上的了解后，在日后的产品需求优先级的判断，及产品设计中会更游刃有余。

通过对以上内容对产品的历史及未来有了一定的了解后，接下来就要进入整个产品的初始阶段：收集需求。既然是一款紧随公司战略发展的 B 端产品，那么高优需求一定是来自业务部门以及相关战略合作公司。

首先收集最高优紧急的需求，也就是与当前公司战略发展最密切相关的，根据关键需求梳理 MVP 主流程，同时产出流程图。然后确认该流程图中所涉及的角色有哪些，每个角色应该有哪些最基本的功能，才能使整个流程不阻塞，走的通。

有些 B 端产品不仅涉及到公司内部的多个部门，还涉及到公司战略发展的合作伙伴，这时你就会发现每个部门或合作公司，都会对这个产品都会提一些自己的需求。

这时最重要的两个问题出现了:

1. 需求提交流程规范化

当有很多部门或合作公司同时对你所负责的产品提需求时，作为 PM ，我们是需求的收集方，同时也是需求的过滤方，更是善于梳理流程的专业户。

可以让每个部门选出一个负责收集该产品需求的负责人，每个部门人员的需求统一提交至需求负责人处；同时，每个部门的需求负责人，再选出一个总的需求负责人，由总的需求负责人收集所有部门负责人的需求，同时过滤掉一些提交重复的需求，最后以正式的形式（邮件）交至 PM 手中。

接到需求后，PM 线下和各部门需求提交人积极沟通，了解需求背后的逻辑，需求产生的原因，自己再过滤一些伪需求。

2. 需求优先级判断要明确

当非常多的需求到 PM 手中后，不可能所有需求都在一个版本做完，就算 PM 产品设计能做得完，但是也得问问天天加班加点的程序员哥哥愿不愿意啊～

所以，要制定重要的需求优先级排序，明确下一个版本要达成什么目标，需要什么功能，在不影响大版本发版的情况下，可以对哪些小的功能进行优化。