专业的短链接生成工具
链接域名
短网址有效期
复盘：三步做好产品规划
更新时间：2025-5-8 05:58:11 作者：爱短链
产品规划是一件说难不难，说简单不简单的事情，作者复习了一次CRM系统的产品规划分享了对关键节点的把握，做好产品规划要注意什么。
目前，一家互联网财税公司负责核心业务产品，主要有三条产品线：财务线、税务线和CRM线。
最近，各产品线负责人完成了三条产品线的产品规划。
有些产品线不断迭代，有些产品线停滞了一段时间。
更换产品线负责人重新启动。
总的来说，已经整理好了7788。
在这个过程中，我深深地感受到产品规划能力对产品经理的重要性。
许多基本能力扎实的产品经理在进行产品规划时也会陷入盲目堆积需求、直接设计细节、优先安排混乱等问题。
在这里，我想和大家分享一些经验。
做产品规划，简单也很简单，掌握关键节点，整理需求的优先级。
也很难说，系统的现状、市场需求、研发资源、需求类型划分、时间表优先级都是需要考虑的因素。
如何在千丝万缕的线索中画出一个清晰的背景，我的理解，最关键的一点是做好深入的业务理解和业务到系统的抽象。
做好这一步，产品规划和需求安排最终只是自然的。
以外呼型为本文CRM系统为例（CRM同时业务比较简单)，进行产品规划复盘。
第一步:了解业务的本质: 不要先看任何系统，清空所有系统的图像。
首先，让我们先想想，CRM业务的核心是什么？ CRM核心很简单，就是销售用来挖掘跟进销售线索，最终实现客户交易转型的过程。
这就是CRM围绕这个过程，用户(主要是营销人员)的行为和场景是什么？ 在销售线索阶段，用户的主要行为是挖掘和验证线索，最典型的行为是打电话； 在潜在客户阶段，用户的主要行为是跟踪从销售线索转化而来的客户，包括不限于电话沟通、上门拜访等； 在客户交易阶段，客户基本确认了购买意向，用户需要完成合同签订、收款等行为。
从上面的场景描述中，我们发现用户行为包括使用通信工具(电话、短信、微信、QQ等)，记录用户跟进动作(打电话、上门拜访等。
)，达成必要的交易程序(签订合同、收付款等。
到目前为止，我们可以总结一下，CRM其本质是：通过使用沟通工具、记录跟进行动和必要的交易程序，将销售线索推向交易客户。
第二步：从业务到系统的抽象 这一步不要看任何系统，清空所有系统的图像。
通过对上述业务的梳理，我们可以开始思考我们需要什么样的系统来完成上述业务。
首先，该系统需要帮助我们完成流程的流通。
在流程节点信息和节点到节点之间，流程的流通无非是两件事。
什么是流程节点信息？ 节点是客户所处的不同阶段，即销售线索、潜在客户和交易客户三个客户阶段。
流程节点信息是每个客户阶段的客户列表页面和客户细节页面/客户卡。
从流程节点到节点之间的流通应该做些什么？ 需要制定流通的前提条件（如需要添加哪些信息、上传哪些文档、生成哪些记录等），以及流通后的限制（只有哪个节点到哪个节点，流通是否可逆等）。
第二，流程不会自我流通，而是通过一些核心功能模块驱动流程流通。
与上图相比，我们工具模块(电话功能、短信功能、QQ等)、跟进动作记录(跟进动态、电话记录、短信记录、现场登录等。
)、交易程序(合同模块、收费管理模块、产品/服务管理等。
第三，作为一个系统，还需要一些通用功能来支持用户的基本操作和管理。
我们可以拉出常用的系统功能，看看我们的系统是否会使用它，如用户管理、权限管理、信息管理、基础设置、帮助中心、数据统计……我们似乎发现了一个不同的通用模块-数据统计。
数据统计是许多系统的通用管理功能。
CRM数据统计不仅是对业务数据结果的分析，也是对用户工作的规划统计和推广，即计划模块。
因此，我们应该把计划管理放在促进流程流通的核心功能上。
我们对上述功能抽象的结果进行了如下： 到目前为止，我们已经完成了从业务到系统功能的抽象。
我们可以看到的是，我们的功能拆卸完全基于我们对业务抽象的思考。
同时，也有一些功能是我们在功能拆卸过程中衍生出来的，如数据公海和销售线索的收集和回收。
这里有一个小插曲。
我们如何衍生销售线索的导入功能？ 我们将销售线索、潜在客户和交易客户编号为1、2、3。
众所周知，程序员的一个梗是同一个数字，正常人是1、2、3，而程序员是0、1、2、3。
回到我们的设计，我们也会想，客户是如何进入销售线索（编号1）的阶段的？我们很容易认为，销售线索从0到1的过程实际上是销售线索导入的过程，从而衍生出销售线索导入的功能。
其实，实际CRM系统设计中还有很多细节。
如数据回收机制、订单流通、财务对接、移动设备功能等……能说三天三夜。
但正如我们之前所说，本文只讨论产品规划的方法，而不是CRM设计。
这里再次声明需要强调的一点是：功能拆卸并不代表系统菜单的划分，更不用说页面的设计水平了，因此我们还需要根据功能之间的相互依赖来拆卸和重组页面模块。
我们不会重复从功能拆解到页面功能模块的收敛、合并、拆分和嵌入。
第三步:从功能清单到产品规划 这一步，我们需要开始看系统，毕竟这是最后一步。
在这一步中，我们首先需要得到一个功能列表。
如果现在没有系统，上述功能拆卸可能是功能列表。
如果我们在现有系统上进行迭代，我们需要使用上述功能列表，比较现有的系统功能，分析我们缺乏的功能和需要优化的功能。
最后，得到一个功能列表，或者我们通常称之为需求池。
下面，我们将规划需求池。
对于需求规划，我们依赖于三个指标：需求类型、和需求紧急性三个指标。
三个指标相互独立，单个指标内部有优先级。
紧急情况通常是版本规划的基础；需求重要性作为同一紧急情况下（或同一版本）的需求优先级；同一紧急情况下的需求类型作为需求优先级的基础。
具体来说，所有高应急需求构成最新版本需求，应急需求作为下一版本需求，低应急需求作为未来版本需求；在同一版本需求中，根据需求的重要性从高到低排序；在同样重要的需求中，通常优先考虑在线Bug，其他需求类型次之。
需求类型通常可以分为以下几类：在线Bug、新功能、功能优化、技术需求。
通常考虑以下因素：企业战略、市场反馈、系统完整性、系统健壮性等。
需求紧急划分通常考虑以下因素：是否位于主流程/关键路径、是否有外部依赖、是否有时间窗口、用户操作频率、覆盖用户范围等。
当然，每个系统的需求类型、需求重要性和需求紧迫性需要根据每个公司的业务和产品来定义，没有相同的标准或固定的公式。
通过以上步骤，我们基本完成了初步的产品规划。
当然，产品规划的最终定稿应与开发和测试团队沟通，综合考虑团队研发资源，最终与业务部门确认定稿。
我们不会在这里重复这个过程。
结语 在产品工作中，我一直认为产品设计绝不是一项基于个人感受或主观判断的工作。
产品设计、产品规划、产品沟通、项目跟踪踪和日常工作的各个方面，都需要方法论来支持工作，有时甚至像数学公式一样，也需要严格的论证和推导。
每个人的方法论可能是不同的，甚至是非常不同的，同一个人的方法论也不是一成不变的。
但只有在方法论的支持下，才能促进产品设计工作的高效、高质量的完成，进而促进业务的实施和战略目标的实现。
声明 本文提到的CRM系统及相关业务，以及我有关CRM系统与业务关系不大，所有功能和图表都是临时编写的。
本文只是借CRM从一个业务概念出发，如何逐步推导系统CRM为了完成产品规划和需求安排，系统基本模型。
读者需要关注产品规划和需求安排的思维过程和推导方法，而不是CRM系统功能。
特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。
本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。
如有侵权行为，请联系网站管理员删除，。
目前，一家互联网财税公司负责核心业务产品，主要有三条产品线：财务线、税务线和CRM线。
最近，各产品线负责人完成了三条产品线的产品规划。
有些产品线不断迭代，有些产品线停滞了一段时间。
更换产品线负责人重新启动。
总的来说，已经整理好了7788。
在这个过程中，我深深地感受到产品规划能力对产品经理的重要性。
许多基本能力扎实的产品经理在进行产品规划时也会陷入盲目堆积需求、直接设计细节、优先安排混乱等问题。
在这里，我想和大家分享一些经验。
做产品规划，简单也很简单，掌握关键节点，整理需求的优先级。
也很难说，系统的现状、市场需求、研发资源、需求类型划分、时间表优先级都是需要考虑的因素。
如何在千丝万缕的线索中画出一个清晰的背景，我的理解，最关键的一点是做好深入的业务理解和业务到系统的抽象。
做好这一步，产品规划和需求安排最终只是自然的。
以外呼型为本文CRM系统为例（CRM同时业务比较简单)，进行产品规划复盘。
第一步:了解业务的本质: 不要先看任何系统，清空所有系统的图像。
首先，让我们先想想，CRM业务的核心是什么？ CRM核心很简单，就是销售用来挖掘跟进销售线索，最终实现客户交易转型的过程。
这就是CRM围绕这个过程，用户(主要是营销人员)的行为和场景是什么？ 在销售线索阶段，用户的主要行为是挖掘和验证线索，最典型的行为是打电话； 在潜在客户阶段，用户的主要行为是跟踪从销售线索转化而来的客户，包括不限于电话沟通、上门拜访等； 在客户交易阶段，客户基本确认了购买意向，用户需要完成合同签订、收款等行为。
从上面的场景描述中，我们发现用户行为包括使用通信工具(电话、短信、微信、QQ等)，记录用户跟进动作(打电话、上门拜访等。
)，达成必要的交易程序(签订合同、收付款等。
到目前为止，我们可以总结一下，CRM其本质是：通过使用沟通工具、记录跟进行动和必要的交易程序，将销售线索推向交易客户。
第二步：从业务到系统的抽象 这一步不要看任何系统，清空所有系统的图像。
通过对上述业务的梳理，我们可以开始思考我们需要什么样的系统来完成上述业务。
首先，该系统需要帮助我们完成流程的流通。
在流程节点信息和节点到节点之间，流程的流通无非是两件事。
什么是流程节点信息？ 节点是客户所处的不同阶段，即销售线索、潜在客户和交易客户三个客户阶段。
流程节点信息是每个客户阶段的客户列表页面和客户细节页面/客户卡。
从流程节点到节点之间的流通应该做些什么？ 需要制定流通的前提条件（如需要添加哪些信息、上传哪些文档、生成哪些记录等），以及流通后的限制（只有哪个节点到哪个节点，流通是否可逆等）。
第二，流程不会自我流通，而是通过一些核心功能模块驱动流程流通。
与上图相比，我们工具模块(电话功能、短信功能、QQ等)、跟进动作记录(跟进动态、电话记录、短信记录、现场登录等。
)、交易程序(合同模块、收费管理模块、产品/服务管理等。
第三，作为一个系统，还需要一些通用功能来支持用户的基本操作和管理。
我们可以拉出常用的系统功能，看看我们的系统是否会使用它，如用户管理、权限管理、信息管理、基础设置、帮助中心、数据统计……我们似乎发现了一个不同的通用模块-数据统计。
数据统计是许多系统的通用管理功能。
CRM数据统计不仅是对业务数据结果的分析，也是对用户工作的规划统计和推广，即计划模块。
因此，我们应该把计划管理放在促进流程流通的核心功能上。
我们对上述功能抽象的结果进行了如下： 到目前为止，我们已经完成了从业务到系统功能的抽象。
我们可以看到的是，我们的功能拆卸完全基于我们对业务抽象的思考。
同时，也有一些功能是我们在功能拆卸过程中衍生出来的，如数据公海和销售线索的收集和回收。
这里有一个小插曲。
我们如何衍生销售线索的导入功能？ 我们将销售线索、潜在客户和交易客户编号为1、2、3。
众所周知，程序员的一个梗是同一个数字，正常人是1、2、3，而程序员是0、1、2、3。
回到我们的设计，我们也会想，客户是如何进入销售线索（编号1）的阶段的？我们很容易认为，销售线索从0到1的过程实际上是销售线索导入的过程，从而衍生出销售线索导入的功能。
其实，实际CRM系统设计中还有很多细节。
如数据回收机制、订单流通、财务对接、移动设备功能等……能说三天三夜。
但正如我们之前所说，本文只讨论产品规划的方法，而不是CRM设计。
这里再次声明需要强调的一点是：功能拆卸并不代表系统菜单的划分，更不用说页面的设计水平了，因此我们还需要根据功能之间的相互依赖来拆卸和重组页面模块。
我们不会重复从功能拆解到页面功能模块的收敛、合并、拆分和嵌入。
第三步:从功能清单到产品规划 这一步，我们需要开始看系统，毕竟这是最后一步。
在这一步中，我们首先需要得到一个功能列表。
如果现在没有系统，上述功能拆卸可能是功能列表。
如果我们在现有系统上进行迭代，我们需要使用上述功能列表，比较现有的系统功能，分析我们缺乏的功能和需要优化的功能。
最后，得到一个功能列表，或者我们通常称之为需求池。
下面，我们将规划需求池。
对于需求规划，我们依赖于三个指标：需求类型、和需求紧急性三个指标。
三个指标相互独立，单个指标内部有优先级。
紧急情况通常是版本规划的基础；需求重要性作为同一紧急情况下（或同一版本）的需求优先级；同一紧急情况下的需求类型作为需求优先级的基础。
具体来说，所有高应急需求构成最新版本需求，应急需求作为下一版本需求，低应急需求作为未来版本需求；在同一版本需求中，根据需求的重要性从高到低排序；在同样重要的需求中，通常优先考虑在线Bug，其他需求类型次之。
需求类型通常可以分为以下几类：在线Bug、新功能、功能优化、技术需求。
通常考虑以下因素：企业战略、市场反馈、系统完整性、系统健壮性等。
需求紧急划分通常考虑以下因素：是否位于主流程/关键路径、是否有外部依赖、是否有时间窗口、用户操作频率、覆盖用户范围等。
当然，每个系统的需求类型、需求重要性和需求紧迫性需要根据每个公司的业务和产品来定义，没有相同的标准或固定的公式。
通过以上步骤，我们基本完成了初步的产品规划。
当然，产品规划的最终定稿应与开发和测试团队沟通，综合考虑团队研发资源，最终与业务部门确认定稿。
我们不会在这里重复这个过程。
结语 在产品工作中，我一直认为产品设计绝不是一项基于个人感受或主观判断的工作。
产品设计、产品规划、产品沟通、项目跟踪踪和日常工作的各个方面，都需要方法论来支持工作，有时甚至像数学公式一样，也需要严格的论证和推导。
每个人的方法论可能是不同的，甚至是非常不同的，同一个人的方法论也不是一成不变的。
但只有在方法论的支持下，才能促进产品设计工作的高效、高质量的完成，进而促进业务的实施和战略目标的实现。
声明 本文提到的CRM系统及相关业务，以及我有关CRM系统与业务关系不大，所有功能和图表都是临时编写的。
本文只是借CRM从一个业务概念出发，如何逐步推导系统CRM为了完成产品规划和需求安排，系统基本模型。
读者需要关注产品规划和需求安排的思维过程和推导方法，而不是CRM系统功能。
特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。
本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。
如有侵权行为，请联系网站管理员删除，。
