大家好，现将我过往工作中的在产品层面的一些方法论和实证经验整理分享给大家，方便产品同仁交流学习。
本篇是同产品同学分享我自己在需求提取、需求翻译、需求管理、需求设计、需求驱动、需求交付方面的一些实践经验，希望通过此篇文章帮助初中级产品从业者优雅的驾驭需求，进而做到从容应对杂乱无章的无序需求，对上游需方兄弟做到强有力的专家支持，对下游研发兄弟做到专业有序的统筹调度。
下沉到业务中 业务敏感
再牛的产品经理也需要了解业务，不了解业务能力再强也容易闭门造车。只有当我们融入业务，了解业务，才能时刻保持业务敏感。
所谓业务敏感，可以用如下几个场景来表达：
场景1：当业务兄弟或业务领导与我们讨论某个业务“表象问题”时，我们能立刻同频、入镜，并能用业务语言与当事人进行流畅交流，同时我们还能就“表象问题”挖掘出深层的问题或业务或老板背后的潜在诉求，以及相应的解决策略。
场景2：我们要接受某个任务或解决某一具体问题时，我们心中有大盘，能够站在整个平台的角度思考问题、制定解决方案，避免掉坑里。
场景3：工作业余之外，作为产品的天生的好奇心能够将外部的、行业内的、行业外的看似无关的东西引入业务内，推动业务的良性创新、演变。
热爱你的产品 持续的业务思考
热爱成就伟大，如果不热爱我们的产品，单纯靠考核，靠绩效一定做不出伟大的产品。产品经理如果不喜欢自己的产品，如果不用自己的产品，如果不在工作之外也持续的思考自己的产品，很难有出彩的产出和产品创新。
当我们持续的关注、思考我们的产品时，用户反馈给我们的问题，我们基本上已经提前知道，或者已经有排期或者有考虑。我们能走在用户的前面，更大概率的提前发现问题，即使我们明知道短期内无法解决，但我们有对应的非开发策略予以补位，如我们的帮助手册，如我们的排期计划，如我们的业务边界…
4份Excel文档：Roadmap 功能矩阵 3个版本的Featurelist 需求池 Roadmap的设计策略及实战case
Roadmap是以实现公司战略目标为原则来确定我们产品建设的中长期指导计划，不同级别、不同阶段有不同的粒度尺度把握。
一份优雅的Roadmap需要具备如下几个要素：
以经营目标为指导；
明确的时间窗口；
明确的业务场景、及业务目标；
逻辑演进的自洽；
基于公司现况的可承受的研发资源投入；
决策层共识与认可。
功能矩阵的设计策略及实战case
功能矩阵是站在产品各一级功能视角或具体的业务场景视角去思考、设计我们产品的演进计划，某种意义上讲功能矩阵是另一个角度的Roadmap，但与Roadmap有明显的区别。
区别一：功能矩阵更偏“矩阵”、更弱“时间”；
区别二：功能矩阵相比Roadmap，我们更习惯用“优先级”、“状态”来表述，而Roadmap里的优先级基本一样，只是时间窗口的设置问题。
换句话说，功能矩阵是产品经理通过“自下而上”的内生动力,以暗线方式推动产品迭代演进。Roadmap是产品经理通过“自上而下”的外在框架指导，以明线方式推动产品迭代演进。Roadmap体现的是公司的战略意图，功能矩阵提现的是产品经理对产品的深度思考和排兵布阵。
需求池：采集、梳理、更新策略及实战case
产品经理打交道最多的就是需求，面对来自各方杂乱无章的需求，我们需要进行统一管理。基于分层组织架构，实践中我认为比较好的采用AB结构。
A类需求池原则上是产品总监或一级产品负责人维护，A类需求池需要向产品内部进行实时同步、随时查阅、协同编辑，共同维护，作为团队的“公有资源”使用。实务中，产品总监或一级产品负责人需要每周、每月、每季度与产品组同事内部集体Review——指导产品团队持续的完善需求、聚类整理需求、有序解决需求。如有必要还需与业务领导一起讨论技术开发是否有必要或者启动优先级及时间窗口设定。
B类需求池原则上是所有产品经理对自己负责模块的维护。大家会问，这两个是否重，是否存在需求不一致呢？
答案是“一定会”，但是，并非简单意义上的“重复”，我们姑且可以把B类需求池作为自己的账本，自己的账本应该和大账本保持同步，但是自己的账本的侧重点是更敏捷、更系统、更细腻——方便自己心中有本账。
无论是A类需求还是B类需求，都遵循“实时记录”、“及时整理”、“定期复盘”、“干系人共识”、“状态更新”。
无论是A类需求还是B类需求，在信息处理时，都应该有如下几个必备字段：“提出人”、“问题描述”、“问题归属”、“问题性质”、“优先级”、“版本规划”、“状态”、“责任人”。不同团队，不同个人习惯可以略有不同，示例如下：
三个版本的Featulist
基于上述Roadmap的“明线指导”和产品功能矩阵规划的“暗线指导”，结合上述需求池的原始线索，我们需要梳理出下个版本要解决的问题，并基于可投入的研发资源及时间窗口设置下个版本的Featurelist。
相对产品功能矩阵表，Featurelist的粒度要更细。具体哪些需求可进入Featurelist，可以同大家分享我的一些实务经验：
如果是运营类需求，Featurelist包含两个维度：运营面上的功能需求点 产品内部相关联动点；
如果是产品类需求，Featurelist包含两个维度：主功能点占比80% 用户体验优化点：占比20%。
为了将产品经理从需求应付中解放出来，发挥我们的产品owner原始价值，我的操盘经验一般是采用三段式，也即研发一版、设计一版、规划一版。
研发一版：当前研发团队正在进行的，产品的时间投入基本分布在如下几个场景：文档动态更新、研发动态支持、项目进度动态跟进、测试验收、上线培训等工作，这些场景的特点是：琐碎、紧急。
设计一版：是我们提前对已共识要干的下个小Roadmap进行拆分设计，也是研发前期产品拥有最宝贵的静态时间窗口期。
这个场景的特点是：产品内部方案论证、产品内部评审、需求方二次确认、必要的前置视觉启动等。设计一版也是最考验产品经理能力的，出色的产品经理可以很好的做好时间窗口把握，帮公司和团队节省巨大的人力资源。
规划一版：更多是提前思考下下个版本应该做哪些、相对大Roadmap我们进度有哪些偏差、是否有最新的需求或市场变化需要考虑进来，带有较大的不确定性。
除此之外，出色的产品经理还要做到如下两件事：通过提前思考来逆向指导“设计一版”的逻辑扩展性和方案策略的合理性，二一个是与业务体系进行论证、明确哪个部门的优先级高，哪个需求优先级高，并向外部提前一个月同步一个月后的预定攻击目标和预期交付成果，进而避免业务追着产品问，我的XX需求啥时候做？我的XX需求啥进度了？你们下一步打算做什么？
定期Review：回应需求方关切 明确行动共识 再次澄清需求
需求池有了、版本规划有了、产品设计也干了、研发也吭哧吭哧启动了，这么多需求，我们的资源有限，时间有限，不可能全部做完，也不可能一步到位。而我们的老板、我们的需求方是不清楚我们在干什么的？
这就需要产品经理需要做如下事情：
启动前与需求方再次明确共识：哪个优先级高、哪个优先级低、大的策略框架、预期可达到的效果是。
demo文档设计完后要与干系人确认，进一步澄清需求是否符合预期，避免研发进行中变更或者上线后推到重来。
每周小通报、每月大通报，向干系人通报Roadmap的整体进度、当前在途项目的进度以及干扰事项、前置协作等信息。
产品设计：目标诉求、干系人、业务场景、需求边界、业务链路、产品架构 目标诉求、干系人、业务场景
我撰写PRD有个习惯，也即每个功能模块、每个页面，花时间撰写“业务场景、目标用户、设计诉求、设计策略、背景说明”等信息，基于上述背景，在整理需求会让自己的思路清晰、考虑系统、方法得体，还有个好处是避免遗漏。
当然了、C端产品相对比较简单，这些步骤的价值没有B断产品明显，示例如下：
业务链路的设计策略及实战case
产品经理千万不能接到需求上来就画原型，钻入细节，而是先调研业务、静下心来思考人，然后用手画出业务链路图。画完业务链路图后再自行推敲是否合理，正向的、逆向的、约束条件、分支条件等是否都考虑到了，业务链路是否有遗漏、业务链路能否再简化，现有功能如何自然演进。
上述基础工作做完之后，再结合前述的功能矩阵图二次推敲、调整。
二次推敲完之后，再与业务方、干系人讨论、看下是否有遗漏，如无遗漏方可开展原型撰写。这里有个坑，业务方并非只是领导，还要邀请实际使用者参与讨论，避免我们闭门造车或遗漏业务中的特殊规则等。
产品架构设计策略及实战case
产品架构是产品经理站在公司的业务、资源和时间三个维度，统筹考虑当前产品的业务架构、技术架构、研发平台、先做哪些功能？再做哪些功能？各个功能模块之间的耦合解构关系、不同的研发小组分别并行或串行做哪些功能，最后有序会师等。
一方面考验产品经理的过往大项目经验沉淀能力；一方面考验产品经理的业务理解深度；一方面考验产品经理敢下功夫投入的系统思考的逻辑严谨性和前瞻预见性；一方面考验产品经理的权衡决策能力；最后一个是考验产品经理的落地执行能力。
征询讨论：领导征询、业务方征询、技术组长征询
心中装有产品架构、在已达成共识的业务链路和Featurelist指导下，完成PRD初稿。
初稿更多的是页面结构、信息布局、事件流转的呈现，并不涉及研发层面的详尽的逻辑注解。初稿自查无异议后，要与产品Leader内审，内审通过后再与需求方一起走查看下是否符合预期，是否有遗漏的场景未覆盖，产品策略是否合理等。
与业务方达成共识后，就部分高复杂业务或有一定技术难点的再与各组长进行逐一征询，提前获取各技术组长的专业指导建议和方案认可，为后面的正式需求宣讲扫清障碍。
立项圈人：画饼、排期、立项、圈人
需求宣讲完后，我们需要各研发组长在指定时间内基于Featurelist和PRD返回排期，如果资源有冲突，可以分组错茬开发。
产品经理要利用好需求宣讲这个舞台的前、中、后三个场。
前场是画饼，讲这件事的背景、紧迫性和价值，用故事、段子、使命等将大家从其它阵地带入到我们的阵地。
中场就是我们最拿手的需求宣讲，千万不要搞砸了，注意顺序“功能矩阵”>“业务链路”>“具体模块”>”全局潜规则”，最后来个虚心请教是否有遗漏，请在座的研发、测试专家们“扔砖”~
后场就是再次重申，决战开始，此刻起兄弟们都归我管了，立项后谁的需求都不能接了，谁敢私自接需求，咱们周会上刀枪相见~
风险化解：真诚干练、更新同步、每周Review 进度通报
人无完人，再大神级的RPD也会有瑕疵，此时我们要做的就是释疑、补充、完善。
从业秘诀如下：
千万要真诚、千万要真诚、千万要真诚
千万要干练、千万要干练、千万要干练
千万要及时更新文档、千万要及时更新文档、千万要及时更新文档。
及时组织或协助组织项目进度Review，每周一次，会上就干三件事：进度驱动、协调协同、风险披露。
验收交付：标准对照、需求池更新、数据初始化、运营客服培训 标准对照
时间充足：从大到小、事无巨细，分层推进；
时间紧张：关键业务点体验，其它交给业务方和测试兄弟把关。
需求池更新
基于研发测试进行中暴漏的问题，动态更新我们的需求池、及潜在版本的Feturelist。
数据初始化
永远记住，数据初始化是一个标准动作，永不可忘记。基于此倒排，我们的数据初始化策略和前置准备工作。
运营客服培训
领导一句话，产品一拍兄，研发一把泪，事终于成了。
但我们要对运营同学、客服同学进行系统的培训。
培训秘诀：概念导入；业务链路串讲；具体操作演示；操作手册。
以上是自己在产品中的一些实践总结，限于文采拙劣和时间有限，未能精细呈现，海涵。文中所述观点不当的，希望广大产品同仁不吝拍砖，共同提高。
不同的产品团队、不同的岗位角色，会导致我们的分工不同，以上很多场景可能不涉足或不主控，但万变不离其宗，方法相同，只要我们有产品盘感、业务敏感、逻辑严谨、灵通好学、干练带风、狠下功夫，放到哪我们都一样熠熠生辉。
产品之路很艰辛，也更能锻炼人！在此祝广大产品兄弟姐妹们不辱“产品”之title，做出好产品！
题图来自Unsplash，基于CC0协议