从0-1设计一款B端产品（实战）

在传统企业与互联网企业，产品经理所负责的职责范围不都相同，能够施展的领域也不一，虽各有差异，但各自有优缺点。作者结合自身经历，分享他是如何完成这款产品0-1设计的，希望对你有些启发。

赶上互联网裁员的大浪潮，我从上家公司毕业了，入职新公司后，新公司目标是自研一套信息化管理系统，给自己的众多分公司使用（各个分公司的业务大体相同，可以共用一套产品），总部可以对各分公司统一管理。我就是这个项目的产品经理，唯一的产品经理。没错，新公司属于传统行业，并非互联网行业，投入到IT建设的经费有限，所以只有我一个产品经理，开发是外包。

下面步入正题，结合我的实际经历，介绍下我是如何完成这款产品0-1设计的？

一、明确产品定位

对于企业自研产品，花钱的是企业老板，在开始动手前，要先明确老板的需求和想法，避免做出来的东西不是老板想要的。在开始之前，我先是组织召开了一次会议，明确新产品的定位，想要达到什么样的目的，以及后续产品可能发展的方向。

参会的人员包括老板、研发负责人、市场部负责人和运营部负责人，我们暂且将他们统称为产品评审团。会议最后大家也都达成了一致的结论，想要用新产品实现企业的数字化转型，方便总部统一管理。需要实现进销存的管理、基础业务的流程管理、相关的报表统计等等，还明确了哪些业务需要总部统一管理，剩下的可以由各分公司自由管理。

其中老板还提到一点，产品在自己的企业运行稳定后，后续会卖给其他同类型企业，由于企业所处行业较小，该行业的信息化系统还是处于市场空白阶段，所以新产品研发后具有一定的市场竞争力。基于这个原因，新产品可以考虑使用SaaS模式。

从运营战略上看，SaaS的服务模式有3种：

①纯SaaS模式：互联网公司提供软件，帮助客户用起来，推动续约。

②SaaS+模式：除提供软件服务外，基础行业的理解提供增值服务。

③+SaaS模式：先完成自己的数字化转型，再通过SaaS模式溢出自己的运营能力，帮助其他企业实现数字化转型。

很显然，我们的新产品很符合最后一种。

二、业务调研

明确了新产品的方向，下一步就是开始干了。首先就是需要到企业中去，做业务调研。这时需要选择一个标杆企业，并且这个标杆企业是老板认可的，可以将标杆企业的管理理念通过新产品延申到其他分公司，形成标准化管理。走到企业中去，我们需要了解以下内容：

1. 企业的组织架构和岗位

特别关注组织架构中的重点岗位和产品相关岗位，罗列出每个岗位的岗位职责，对于后面的调研打下基础，避免在调研时忽视了某个角色，同时帮助我们理解企业的业务。

2. 企业业务的整体情况（宏观）

首先要了解企业的商业模式和经营策略，这两者决定了企业的工作重心，是企业的管理者最关注的点，而新产品面向市场时，客户决策人正是企业的管理者。了解商业模式和经营策略，可以把我们的视角拉到和企业管理者一样的高度，也可能从中找到重要的观点作为产品原则来指导我们后续的产品设计，有利于让我们的产品更符合所属行业，以及后期可以销售给更多的客户；

其次了解企业的整体流程，画出整体流程图，需覆盖企业的所有业务类型，主要描述关键流程和步骤，不需要细化到具体功能。整体流程图可以帮助我们快速的了解企业的业务流程，同时为后面输出详细流程图打下基础，避免疏忽遗漏。

3. 企业业务的详细说明（微观）

详细流程图。基于整体流程图，对每个步骤梳理详细流程图，要尽量细致，同时避免遗漏。关注每个环节节点的多种可能性，每个节点是否可以进行逆流程操作，将所有情况考虑全面，必要时记录解释说明。梳理好后，要和业务人员核对一下，保证信息同步，流程图的格式均可，能保证清晰即可，保证调研结束再看流程图仍可以看懂。

业务规则重难点说明。将流程图无法体现的业务规则，描述记录下来，业务流程中的重难点，单独记录出来，产品设计时多关注这些点。如果新产品可以解决目前企业的难点痛点，那新产品对于企业的价值是非常大的，一些同质化的功能并不能彰显新产品的价值。

4. 报表和单据

无论是业务人员还是管理层，都会有报表需求。管理层往往每隔一段时间就会查看企业的经营情况数据，所以报表的需求在MVP版本是一定要做的，我们需要收集企业现有的报表。无论企业是否已经数字化，都会有在用的报表，如果没有数字化，管理者也会自制表格让一线业务人员填写，已经数字化，就收集下现有系统中的在用的报表，确认是否还有其他线下的统计表格在使用。

单据也是业务环节中不可缺少的，如果企业有打印单据的需求，还要收集企业正在使用的单据，谁用，在什么时候使用，参照收集的单据样式，都要加到产品设计中。比如去医院看病时，医生会给我们打印处方单，处方单上由系统自动打印出医生开的药品，拿着处方单去收费处缴费，收费单上显示每个药品的价格和总价……这些都是系统完成的。

收集报表和单据时，不光是要收集，还要理解里面每个字段的含义，产品设计时也要考虑业务流程可以提取出这些数据字段。

5. 现有系统

我们的企业一部分正在使用其他同类型产品，新产品上线后会替换掉当前使用的系统，这时要关注一下现有系统企业使用的情况。

接触过客户的产品经理一定知道，客户总喜欢说的一句话，“之前的xxx系统可以那样，你们这个系统怎么不行啊？”，客户对之前的系统是有使用习惯的，突然切换系统会不习惯，总会和之前的系统去对比，如果他想做的事情，新产品满足不了，他会觉得体验很差，新产品不如旧产品。

所以我们要访谈一下，每个角色每天都会使用现有系统的哪些功能，他认为哪些功能好，哪些功能不好，理由是什么，期望有什么新功能。认为好的功能新产品一定也要有，或者用其他形式满足，认为不好的功能新产品要改正，期望的新功能视情况具体分析MVP版本要不要做。

三、确定MVP

业务调研回来后，梳理好详细业务流程图和业务规则，此时我们已经对需求明确了，下一步就是要确定MVP版本的功能范围，MVP版本要满足最小化和可行性，即只做最核心的功能和客户能用起来。

首先要划分需求优先级，根据需求优先级的高低决定MVP做哪些功能。这里使用到RICE法则：Reach触达，有多少客户提出了这个问题；Impact影响力，客户对这个需求的迫切程度和重视程度；Confidence信心，产品经理对这个需求的判断；Effect努力，付出的成本。

把需求全部划分优先级后，组织会议讨论MVP版本的功能范围，邀请产品评审团参加。为了便于参会人员的理解，需要把需求整理，按模块划分，每个大需求有哪些需求点，不用特别详细的逻辑说明，把关键点列出来就好。通过我们已经对需求优先级的判断，再结合产品评审团的意见，最终明确MVP版本要做哪些功能。

四、输出详细方案

MVP版本功能确定后，开始设计原型，设计时参考业务调研时的详细流程图，争取每个关节节点的逆流程和多种可能性考虑全面。评审通过后，提交给开发，进入正常软件开发环节。值得注意的是，一旦开始开发后，尽量保证需求不再变更，如果是接收到了新的急迫需求，可以安排到1.1版本的迭代中，尽量不要打扰开发人员的节奏，如果是设计逻辑遗漏缺陷这种问题还是要处理的。

MVP版本上线后，我们是先在调研企业试运行一段时间，把期间反馈的小问题和bug解决掉，运行稳定后，在逐步推广至其他分公司。

在传统企业中是否利于产品经理的职业发展，我有几点感受和大家分享一下。

首先说不好的地方：

资源极少，甚至没有UI、测试，如果涉及C端页面，就请个外包的UI设计，按页面收费，PC端页面的效果完全由前端开发把控。

开发是外包的，异地协作，我们的外包开发喜欢晚上熬夜工作，上午睡觉，所以只有下午时间可以沟通，有时晚上在群里发消息还要回复；不照着原型做，有时候原型复杂了，就用一个简单的方式代替了，功能实现了但用户体验减分；测试出来的问题改不干净，有的问题改几次还是改不好。

没有测试，没有测试，没有测试。很苦恼，自己测根本测不全，很多bug测不出来，上线后都是客户发现bug，再改，用户和我的体验都很差。

充当客服。帮助企业产品上线、产品培训、日常回复产品使用问题，周末的问题也要回复。

不利于培养商业思维。传统企业的自研产品，就是企业内部使用，并不会靠产品获取利润，所以没有机会培养产品经理的商业思维。

再说好的地方：

对产品的话语权较大。不像在互联网公司，每个产品经理只负责一个产品模块，在传统企业中可以站在更高的视角对整个产品进行规划，可以培养产品管理能力。

可以接触用户。有足够多的机会去接触用户，收集意见，直接对接用户可以收获一手需求，谁懂用户，谁对产品就有话语权。