编辑导读：现在很多B端产品招聘要求有从0到1的建设经历，但是当我们有机会主导一款全新的产品时，应该如何从容地完成从0到1的过程呢？本文作者正好从0到1主导设计过一款CRM销售过程管理产品，希望通过项目复盘给到大家一些帮助。

一、项目背景

公司介绍：一家互联网房产平台公司，主要的客户群体是房产中介。

销售模式：地推模式，需要每天到各个中介门店拜访沟通。

业务背景：随着房产市场降温和竞对公司发展，公司业绩急速下滑。 为了提升销售业绩，所以公司老板要求一方面加大产品创新投入，另一方面强抓销售过程管理。

业务现状：目前对于整个销售过程管理没有线上化，全部依赖于销售每日线下反馈的拜访日报，所以存在大量虚报拜访的情况。

二、项目过程回顾

这种从0到1的项目，大多工期很紧。幸好笔者之前整理了一套产品过程管理的模板，快速梳理了产品的工作任务及粗略的时间计划。这个模板能适用各类从0到1 或者重构项目，建议大家收藏。

下面的内容就是项目过程的具体回顾。​

三、项目启动

1. 战略层调研

• 调研目的：明确产品建设目标。业务系统是为了支持业务目标的达成，所以第一步要梳理清楚顶层管理者的战略目标，进而明确产品的目标。
• 调研内容：战略目标、核心客户、业务模式、盈利模式、核心策略、产品期望等。
• 调研对象：顶层管理者（包含不限于：老板、业务线负责人等）。
• 调研方式：面对面访谈。

本项目的战略层调研结果：

• 调研对象：集团总经理、销售副总
• 战略目标：销售额同比去年增长30%，突破XX亿
• 核心客户：房地产中介经纪人
• 业务模式：定位还是房产信息平台，中介经纪人入驻平台后可发布房源信息，C端通过平台获取房源信息，然后通过平台产品连接，再切换到线下沟通交易
• 盈利模式：向经纪人收取平台入驻费用，同时提供相关的付费广告服务
• 核心策略：维持我爱我家、链家这些大型房产中介公司，但今年要进一步覆盖中小型社区门店。为此要加大对销售过程的管理，加强销售覆盖量和提升销售转化

产品期望：

• 将整个拜访过程线上化，能实时监控到销售的拜访情况。彻底规避虚假拜访的情况，保证拜访动作的有效执行。
• 能通过数据分析，能销售提供智能的拜访建议。

2. 产品现状梳理

• 目的：明确产品的边界和对上下游的依赖。因为业务系统的上下游众多，所以即使是从0到1设计一款业务系统，前期也需要把相关的产品现状梳理清楚。
• 内容：相关产品的功能架构、实体关系等等
• 方法：找到对应的产品和开发，梳理相应的产品功能架构图和ER实体关系图。

本项目的产品现状梳理结果：

相关系统：只有3套系统，一套是简易的客户信息系统，一套是供应链管理系统，最后就是C端房产前台。 其中客户信息管理了 公司-门店-经纪人这3层的信息；供应链系统管理了产品、订单、收款、履约等信息。C端就是大家熟悉的房产平台，展示经纪人的房源信息。具体的内容就不再展开了，大家了解这个环节主要做什么就行。

3. 竞品学习

• 目的：借鉴竞品好的设计，加快产品建设的效率。同时通过对竞对的研究，规避一些因考虑不全导致的设计漏洞。 ​
• 方法：就是竞对研究的常用方法，不赘述。

注意：

• 尽可能选择业务模式相近的产品作为竞品。
• 不要停留于产品功能的研究，更要深入了解背后的设计思路和业务策略。

4. 项目规划方案

• 目的：对整体项目有大致的规划，用于指导后面具体的项目工作。
• 内容：背景、目标、方案概述、项目团队、里程碑节点、沟通机制等等。

这部分不做展开，基本大家把上面几部分的内容梳理清楚就可以了。

5. 项目启动会

• 目的：上下同欲，拉着项目成员一起把目标确定下来，任务分配下去，正式开工。
• 内容：项目规划方案里的内容，加上领导们致辞。
• 参会人：领导+全体项目成员

这一步非常重要，千万不能省略。因为笔者见过太多没开启动会就开始干，大家目标都没有对齐，过程中各种撕逼，最终项目以失败收场。

四、需求调研

调研结果将直接决定后面的产品架构设计，笔者刚做产品那会儿曾经因前期调研不到位，花费大量资源开发出来的产品被用户吐槽、甚至是被用户弃用。 所以千万不要因为项目工期紧张，而潦草应付这个环节。整个过程一定要详细调研，力求获得真实全面有效的信息。

1. 业务调研

目的：了解实际的业务场景和需求。

对象：业务环节上的所有角色，例如本项目需要调研一线销售、销售主管、销售经理、销售运营支持、客户（中介经纪人）等。

内容：包含但不限于以下几点：

1. 组织架构及岗位权责
2. 工作流程及规范
3. 绩效考核规范
4. 核心数据指标
5. 当前的业务执行痛点和需求

方法：面对面访谈、亲自参与体验工作流程。

强烈建议B端产品经理能亲自体验核心用户的日常工作流程，因为大部分用户难以清楚表达自己的需求，很多时候用户说出来的其实是他们认为有效的产品方案，但却不一定是最佳方案。只有产品将自己放到用户的角色中去体验，才能设计出真正有效且好用的产品。

2. 业务调研总结汇报

• 目的：进一步确认业务场景和需求
• 内容：前期调研结果的汇总分析
• 方法：组织各个角色的核心代表一起进行调研结果，尤其是对核心场景和流程再次进行确认

五、概要设计

接下来我们正式开始产品的设计工作，首先把主体框架设计出来，确认主体设计没问题后，再做进一步细节设计。

千万不要一上来就画原型、抠UI，这样不仅会严重影响项目进度，甚至会因为陷入细节而忽视全局，导致项目最终失败。

笔者曾经跟过一个对UI要求极高的产品leader，当时也是做一个重要系统的重构。前期就是跟老板简单沟通了之后，就开始要求画高保真原型图，然后一遍一遍扣细节。结果最后通宵达旦的加了2个月班，虽然出来的产品页面样式精美且交互流畅，但是用户实际应用过程中整个环节跑不通，使用起来极其不方便。最后整个项目团队被老板拉到一个超大的会议室足足骂了一个小时，半年度绩效工资也基本都没了。

通过上面这个case，笔者深刻意识到作为产品需要有极大的责任感及使命感。因为产品是带领开发测试设计等团队成员拿结果的人，如果我们工作不到位，极有可能让整个项目成员的努力付之东流。希望看到这里的同学，能自省共勉。

下面讲讲在概要设计环节，我们具体要做什么。

1. 系统用例图设计

• 目的：清晰的定义出系统边界，即服务哪些用户及并提供哪些功能。
• 方法：具体用例图的设计方法，大家可以网上搜索下UML了解。

下面放一张本项目的拜访计划模块用例图，大家参考下。​

2. 功能架构图设计

• 目的：进一步明确产品的功能范围，为下一步产品演进蓝图做准备。
• 方法：分角色将线下的业务动作，分场景梳理拆分就可以了。

下面是本项目的销售过程管理功能架构图，大家可以参考。

3. 产品演进蓝图

• 目的：梳理产品功能优先级，以明确后续产品设计和开发的节奏。
• 方法：分析业务发展阶段，投入产出比和前后依赖关系，然后优先当前业务需求且ROI高且必须前置开发的功能。
• 本项目的优先级，我们经过跟业务侧的沟通明确如下。

第一阶段目标：实现Do和check的管理线上化

第二阶段目标：实现Plan管理线上化

第三阶段目标：实现Goal管理线上化

第四阶段目标：实现销售赋能智能化

最后明确了整体的产品演进蓝图，如下：

六、详细方案设计

1. 实体建模

• 目的：这一步相当于打地基，把系统内各个实体的关系明确下来。例如 门店、拜访计划、拜访记录等各个实体的对应关系。这一步如果设计不到位，后面会非常痛苦。
• 方法：从实际业务场景和未来业务发展的角度来梳理，要同时兼顾当前开发成本和未来扩展性。这里强烈推荐 大家看这篇文章http://www.woshipm.com/pmd/4079449.html

本项目的E-R关系图，笔者找不到了，所以就不展示了。大家重点关注此环节的设计方法。

2. 信息架构图

目的：进行产品的页面划分及信息梳理，为下一步原型图设计打基础。

方法：

1. 按业务场景和产品功能进行页面的梳理，明确整体有多少个页面，彼此之间如何交互流转，如何组合分类。
2. 分页面梳理每个页面的展示信息和操作信息。

其实业务系统单个页面的梳理相对简单基本都是基于实体的列表页和详情页，然后配合增删改查的操作。难点在于页面组合分类，例如PC端的菜单应该如何设计，才能能保证用户快速找到对应页面。这部分相对复杂，笔者也没有找到有关这部分的好文章。所以立个flag，后期笔者好好梳理下再给大家分享。

下面是本项目的部分信息架构的截图，大家可以参考。

因为调整原型图的成本比这一步大很多，所以建议大家在信息架构图梳理完成后先做一轮内部的产品评审。保证页面间的流转是顺畅的，同时产品上的信息和操作能满足业务需求，再进入原型设计的环节。

3. 原型图

原型图应该是大家最熟悉的一个环节，其实如果前面的信息架构图梳理的好，这一步基本就是拼图。这个环节就不做太多说明了，主要分享几个原型图设计的注意点。

1. 提前准备好通用模块，例如弹窗等等能提高原型图设计效率
2. 设计过程中考虑各种异常情况，例如没有数据时的呈现样式、数据返回超时的样式等等
3. 注意按版本保存原型图，不要在原有页面上直接调整。因为很有可能改了好几稿，发现之前的那稿更合适。

4. 交互设计图

这个环节虽然主要是交互与UI设计师负责，但产品在设计前需要跟他们讲清楚业务场景，便于他们更好的理解业务和产品。

同时在设计中，产品要承担起交互设计图的审核工作。虽然是业务系统但也要注意用户体验，不然会被内部员工狂吐槽。

5. 角色及权限体系

• 目的：业务系统的数据多为公司内部敏感数据和操作，所以权限体系设计可以有效控制风险。
• 方法：权限方面我一般会拆分出菜单权限、数据权限、操作权限这3类。至于具体如何设计角色及权限体系，大家可以多看看RBAC相关的资料。

6. 产品方案PRD

• 目的：通过文档让开发理解整个业务和产品逻辑，保证开发成果能满足需求。
• 方法：大家都比较了解，不细说。重点在于PRD的内容及顺序，建议按前面的梳理步骤，先介绍整体的业务背景和产品架构，然后再分模块详细说明产品逻辑。
• 注意：文档一定要尽可能详细，免得开发出问题时界定不清楚责任。

7. 产品方案评审

• 目的：对PRD的内容做进一步说明。
• 注意：针对评审过程中的问题及事后的调整一定要详细记录在PRD的修订记录里。

后面的开发测试及上线验收环节，都是常规的项目管理工作，这里就不细讲了。

最后希望本文对大家有帮助~~欢迎大家在下方评论区留言交流~

本文由作者@水问 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash ，基于 CC0 协议