产品规划的目的，是提炼要实现的目标和要做的事，从中找出重点，并将其转换成产品功能。
产品规划的步骤在开发阶段之前，但这并不意味着开发人员在这个阶段就不用参与。事实上，产品探索、产品规划的阶段，都至少应有一名有较多经验的开发人员参与，保证方案可行并且预估方案风险。

需求梳理

最小可行产品

在经过需求挖掘后（或者和客户讨论过业务需求后），一般会有一个需求清单，清单上也标记了重点，很多时候，在获得这份清单之后，产品经理就开始着手“翻译需求”（需求–>功能）了，力图快而全地梳理出所有功能点并推进开发。
而实际上，无论是定制产品还是自主洞察的产品，最小可行产品（mvp）都是很有必要的。
定制产品：定制产品的开发节奏一般建议选择敏捷迭代，从定义一个基础可行的产品开始做，逐步地优化和添加客户想要的功能，相比于翻译后直接开工，按照“需求重要性”进行开发，后再调整，按照“功能重要性”定义和开发出一个mvp，验证产品可行性，再做拓展，要更合理。

功能结构梳理（戳点）

  1. 需求分析：基于需求挖掘阶段得到的所有成果，进行深入分析，明确需求的价值和需求满足的优先级
    1. 需求有时不会在之前谈及的范围内，甚至不是显性的功能需求，产品经理需要挖掘出不同场景和目标下，用户会产生的需求，包括事务达成上的和心理上的
    2. 想象自己是用户和客户，置身于业务场景，思考核心诉求和交互路径–>输出业务流程图
  2. 设计功能结构：基于需求分析结果，设计功能和系统结构，使得需求在系统中总有回应。设计时应知道每一个功能点为什么做、做什么、识别重点、难点、风险点–>输出功能结构图
    1. 为什么做：整个产品需要满足怎样的需求或者实现怎样的目标，尝试拆解目标
    2. 做什么：为目标设计功能框架，以及每个功能需要实现的内容，整体又能提供怎样的能力，哪些是基础，而哪些又是上层建筑，或者说，区分痛点、痒点和不痛不痒点，抓准核心业务
    3. 识别重点、难点、风险点：从功能设计和功能价值脱离开，判断整体工作中哪些内容是需要仔细梳理的，哪些部分可能需要多预留时间讨论和技术攻关的，哪些部分会因为依赖或者”可预见的因素“而变得不可用
    4. 一个很好的思路锚点：高内聚、低耦合
  3. 为用户设计功能细节：从 谁用、什么场景用、用来做什么 出发来考虑功能（够用也要好用）
    1. 谁用：用户是谁，他们所在的组织架构是怎样的，他们的年龄、硬件、认知有怎样的共同倾向和区别
    2. 什么场景用：用户需要用这个产品解决什么问题，他们使用的环境是怎样的，这个环境中有什么因素会影响这个过程
    3. 用来做什么：用户需要这个产品如何满足他们的需求
    4. 这一点其实应该划分为用户体验设计的部分，但团队中并不一定有这样的成员，而日后原型阶段再考虑用户体验又有些晚，所以放在这个部分
  4. 设计高可用的权限体系和权限控制方法 –>输出权限结构图/表
    1. 权限体系和权限管理模块，是功能架构中最为特殊的部分，它的常用人群、影响范畴和其他的系统功能大相径庭
    2. 权限包括功能权限和数据权限，它决定了用户在这个系统中所能获取的资源以及所能做出的行为。如果过于简单，会不够安全，如果过于复杂则会对项目、运营乃至用户带来很大的压力
    3. 需要在充分了解和理解用户和业务场景后进行设定，梳理权限结构，保证权限点之间不粘连、不冲突

非功能需求梳理

非功能需求包括安全性需求、性能需求等，它们不是功能，但是很可能会影响系统功能。因此，其中部分需求需要在功能设计的时候就一起考虑进去。
安全性需求例如存储加密/脱敏，传输加密/脱敏等
性能需求例如并发量、吞吐量等

版本规划和需求定级

  1. 功能点及功能结构确定后，就需要按照功能的重要性规划版本和开发优先级
    优先级分为P0、P1、P2，重要性依次降低：P0-核心功能、P1-特点功能、P2-额外功能
  2. 版本规划和优先级排序不总是依据功能重要性，资源是否充足、公司发展目标、业务方的需求等，都是影响优先级的因素

解决方案梳理

为保证需求的满足，仅仅设计有各种功能的产品在很多场景中不足够，还需配合相应的解决方案。
解决方案可以是面向用户的额外的插件、API服务、数据治理服务、表单服务等，也包括为了支撑系统运转而需要日常进行的工作方案。
梳理解决方案时需注意：

  1. 梳理系统侧的解决方案，应当充分与开发和数据以及其他参与建设的成员沟通讨论，确定问题点和风险点
    1. 例如，数据在更新数据时，有哪些语句和操作是不能执行的，哪些字段需要格外注意，处理完成之后是否需要再加一些固定步骤
  2. 解决方案应明确地、准确地记录记录在文档中，按照问题场景、涉及数据进行分类

底层结构设计（平面图）

  1. 底层设计应当包括了系统所有的技术细节，例如数据库选择、服务器配置等等。而落到产品侧的工作里，更多的是库表设计，如果有余力或有必要，还可以包括接口设计。
  2. 这个部分不一定能够自己独立完成，很多时候要和技术多讨论
  3. 设计时：
    1. 从基础的核心的功能开始设计，设计完成后，将设计好的底表放到相关的业务场景中，评判当前设计是否足够支撑，如果后续要调整，有多大空间可以调整
    2. 估计业务的体量，包括使用人数、核心场景、数据量等，基于这些决定表要怎么建，关联关系要如何处理，