Part One 遇到的问题
作为B端产品经理，在工作中发现需求收集环节出现的两大问题：
1.需求隔断问题：客户需求反馈链冗长，最多可达：客户-多级代理商-海外商务或技术-国内技术-产品经理，多次传递后极易出现需求描述不清晰、流程中断、客户无法收到有效反馈回复等问题，导致产品团队对需求的掌控感和敏感度下降，易引发客户不满和失望情绪；
2.需求池管理问题：目前自己团队的需求池管理方式为传统人工管理，需求筛选、录入、优先级标记、共享、更新等方面都存在问题，需求整理、分析、设计工作耗时耗力，效率较低。
Part Two 市场情况分析
目前市场上有很多团队协作工具例如Teambition以及项目管理工具例如Redmine，可以方便地进行需求录入、bug记录等操作，但是这其中缺少了重要的一环----需求获取。
对于B端的需求获取，它与C端需求获取是有很大区别的。从C端到B端，产品的用户的角色是有变化的，从普通的个人消费者转变成了企业级用户。B端产品的客户通常是指付费的一方，严格来讲付费者是企业主体，产品使用者和付费决策者往往是分离的，决定买不买产品的是老板，而具体使用产品的是员工。但是，在实际工作中可以发现，往往有效的需求，都是由各个代理商提出的，他们从付费决策者处获取需求，再反馈给我们，希望丰富产品功能提升竞争力从而带动销售。终端用户-使用者的需求，虽然整体质量低，但是总会有可取之处，如何更有效的筛选，留待后续细化思考。
同时，因为用户角色发生了变化，需求的来源以及用户对于需求的侧重点也不一样。C端产品经理和用户打成一片，需求直接来源于用户，产品经理从用户那里直接获得最真实的需求。而B端产品经理往往隔着老板和销售，这会降低产品经理对客户需求的敏感度。
需求还有一个来源是竞品，但是B端产品往往不对外免费开放，需要申请试用才能体验部分功能，这又给B端产品经理带来了挑战，竞品分析很难了解到竞争对手产品的精髓，往往需要通过拜访客户，才能知道竞品吸引客户的地方在哪里。
Part Three 方案设计
以下是一套方案设计，分为两个部分：需求反馈链的建立和需求池管理。其间如何有机连接，也给出两条路：根据开发成本考量，是建立为整体，还是分割后通过人工导入。
1.需求反馈链：
客户通过软件反馈入口，反馈需求或Bug，内容规定包括：产品、类别、来源区域、需求描述（使用场景等）、联系方式等信息完成需求提交。需求的内容划分更详细，能够得到更高质量的需求。
提交后交由技术人员或产品经理审核，审核不通过则驳回，同时系统发送邮件通知客户并告知驳回理由；审核通过则加入需求池并标记优先级，后续流程在关键环节都将发送邮件给客户及时反馈。需要进行设计。
需求反馈流程图
2.需求池管理部分：
2.1公开需求池：经过审核加入到公开需求池中的需求，将整理并公开，通过热度/发布时间进行排列，客户可以浏览其他人提出的需求，并为自己也有需要的需求增加热度。产品团队将优先挑选热度高和优先级高的需求加入到软件新版本的规划中。
2.2 产品团队协作管理：产品团队成员可以共同在线查阅需求池，并建立不同标签组例如：需求池、需求设计中、评审中、研发中、已完成；通过简单的拖拽即可完成不同状态切换。
现有方案可以直接使用Teambition 或者 Trello进行需求池管理，通过人工将获取到的需求添加到需求池中；或者自己搭建需求池管理系统，从而直接将获取到的需求导入到需求池管理。
需求池管理
Part Four 优势
1.需求收集高效直接：产品经理可以直接触达客户需求，无论是代理商还是终端用户，都可以通过软件反馈入口提交bug、需求，经过产品经理或者软件技术支持审核后加入到需求池，需求池中的需求将按热度排列呈现给客户，客户同样可以为心仪的需求提升热度；此外，每一个需求的每一个推进阶段都将由系统通过邮件有效反馈给客户。
2.需求池管理：经过筛选进入需求池后，内部产品团队可以直接在线协作，对需求池进行审阅、优先级标记、需求导出、负责人分配、完结、归档进入历史需求池等操作，提高需求处理效率，自动反馈进度，形成高效、规范的B端需求池管理系统，从而辅助软件战略规划与迭代升级工作。
3.良好的需求链生态：建立一套更直接的需求反馈流程----从代理商或终端客户直接反馈到软件产品团队，产品团队对需求做出及时响应，再反馈结果至客户，形成需求链的完整闭环。
