文档介绍：大家好，现将我过往工作中的在产品层面的一些方法论和实证经验整理分
享给大家，方便产品同仁交流学****br/>本篇是同产品同学分享我自己在需求提取、需求翻译、需求管理、需求设
计、需求驱动、需求交付方面的一些实践经验，希望通过此篇文章帮助初中级也是最考验产品经理能力的，出色的产
品经理可以很好的做好时间窗口把握，帮公司和团队节省巨大的人力资源（不
是产品经理自己，而是整个下游团队的静态等待时间）。
规划一版：更多是提前思考下下个版本应该做哪些、相对大Roadmap我们
进度有哪些偏差、是否有最新的需求或市场变化需要考虑进来，带有较大的不确定性。
除此之外，出色的产品经理还要做到如下两件事：通过提前思考来逆向指
导 “设计一版 ” 的逻辑扩展性和方案策略的合理性，二一个是与业务体系进行论
证、明确哪个部门的优先级高，哪个需求优先级高，并向外部提前一个月同步
一个月后的预定攻击目标和预期交付成果，进而避免业务追着产品问，我的
XX 需求啥时候做？我的 XX 需求啥进度了？你们下一步打算做什么？
需求池有了、版本规划有了、产品设计也干了、研发也吭哧吭哧启动了，
这么多需求，我们的资源有限，时间有限，不可能全部做完，也不可能一步到
位。而我们的老板、我们的需求方（内部各业务方）是不清楚我们在干什么的？
这就需要产品经理需要做如下事情：
我撰写 PRD 有个****惯，也即每个功能模块、每个页面（敏捷需求或时间不
允许时省去），花时间撰写（思考梳理） “业务场景、目标用户、设计诉求、设
计策略、背景说明 ”等信息，基于上述背景，在整理需求会让自己的思路清晰、
考虑系统、方法得体，还有个好处是避免遗漏。
当然了、 C 端产品相对比较简单，这些步骤的价值没有B 断产品明显，示
例如下：
产品经理千万不能接到需求上来就画原型，钻入细节，而是先调研业务、
静下心来思考人，然后用手（或工具）画出业务链路图。画完业务链路图后再
自行推敲是否合理，正向的、逆向的、约束条件、分支条件等是否都考虑到
了，业务链路是否有遗漏、业务链路能否再简化，现有功能如何自然演进（如需）。
上述基础工作做完之后，再结合前述的功能矩阵图（如 excel、如脑图）二次推敲、调整。
二次推敲完之后，再与业务方、干系人讨论、看下是否有遗漏，如无遗漏
方可开展原型撰写。这里有个坑，业务方并非只是领导，还要邀请实际使用者
参与讨论，避免我们闭门造车或遗漏业务中的特殊规则等。
产品架构是产品经理站在公司的业务、资源和时间三个维度，统筹考虑当
前产品的业务架构、技术架构、研发平台（客户端还是小程序还是都干）、先
做哪些功能？再做哪些功能？各个功能模块之间的耦合解构关系、不同的研发
小组分别并行或串行做哪些功能，最后有序会师等。
一方面考验产品经理的过往大项目经验沉淀能力；一方面考验产品经理的
业务理解深度；一方面考验产品经理敢下功夫投入的系统思考的逻辑严谨性和
前瞻预见性；一方面考验产品经理的权衡决策能力；最后一个是考验产品经理
的落地执行能力。
心中装有产品架构、在已达成共识的业务链路和 Featurelist 指导下，完成
PRD （我****惯直接用原型，而非写 word）初稿。
初稿更多的是页面结构、信息布局、事件流转的呈现，并不涉及