编辑导语：前两篇文章作者带我们完成了产品的研发过程，实践：带你一步一步完成ToB产品设计、实践：怎么做好研发阶段的产品工作，本文就已经是一次产品迭代流程的尾声了，作者详细介绍了ToB产品研发完成后还需要做哪些工作。

到了这个阶段，产品的一次迭代流程基本上就接近尾声了。

这个阶段是产品经理比较忙的阶段，主要工作内容聚焦在验收测试、市场支持、销售支持方面。

一般情况下文档量会比较多，接下来咱们就捋一捋这个阶段产品的主要工作内容，以及完成这些工作内容的一些技巧和要注意的示项。

当然，这个阶段还是以我个人的工作经验为核心描述，仅供参考。

一、产品验收

产品验收是研发团队和产品团队的工作交接过程，产品验收标志着产品正式完成研发的相关工作，转为后续迭代升级维护阶段，也标志着产品部门有了新的武器到市场上冲锋陷阵了（是死是活就看产品自己的能力了）。

1. 交付物完整性验收

产品研发上线后，产品经理首先要对研发提交过来的交付物是否完整进行整体性的检查。

通常我们会在验收启动前跟研发对一个交付物清单，对研发提交的整体成果物达成一致。

对于ToB类型的产品，通常的交付物包括：

1. 产品本体：要明确产品版本号，模块文件/源代码文件清单（如果有必要的话），安装程序等。
2. 文档手册：包括产品安装手册、测试报告（包含功能测试、压力测试等）。

拿到产品交付过来的产品后，产品这边需要根据成果物清单逐个进行对照检查，如果对照过程中出现了任何的问题，直接给产品这边的Leader发邮件（注意！一定要发邮件），要求他们重新检查后，重新发送。

这个阶段一定要注意：因为交付物是一个整体的概念，尽量不要研发一点一点发给你，你来替换某个或者某几个文件，毕竟你对整体产品包不够了解，容易替换出来问题；在完整性验收的阶段，一定是研发给你一个整体产品包过来做验收。

2. 产品安装验收

确认了产品比较完整了，产品这边需要协调现场部署人员对产品安装过程进行验收，来确认产品安装过程的可执行度。

这个过程通常会包含两个方面的功能：

• 一个方面是需要现场部署人员熟悉部署流程；
• 一方面也是验证产品整体安装部署的可执行能力。

过程就比较简单，由现场部署工程师按照产品安装手册里面的要求准备测试环境、安装基础的软硬件平台，部署软件产品。

这个过程中如果出现了任何问题，就需要提交产品级别的BUG，由产品研发相关人员做修正；一般情况是安装程序BUG或者文档BUG，都需要录入到BUG管理系统进行追踪维护。

3. 产品功能验收

产品安装验收通过后，产品部门团队就有了一套用来验收的环境了。

产品部门就要根据需求对产品的功能进行整体性的试用和体验。

这个过程中通常会产出以下的内容：

1）产品使用手册：

产品使用手册是产品的重要组成部分，产品团队需要按照产品需求、产品原型来一边做功能方面的验收，一边切图制作产品使用手册。

注意，产品使用手册通常是给用户应急用的，用户一般情况不会看产品使用手册，只有出现问题的时候才会使用。

那么产品使用手册除了常规的操作说明外，一定要加上Q&A的部分，把验收过程中产品遇到的问题及解决方案都放在里面。

2）产品BUG：

验收过程中，可能会出现产品级别的BUG，通常我会把产品级别的BUG设置为以下几种：

• 功能BUG：就是功能实现上跟预期不符，属于严重BUG，需要修复后再发布；
• 体验BUG：就是功能上满足需求，就是使用过程中会有一点不舒服或者反人类习惯，这类的BUG一般情况下会加入到需求池观察，如果客户提的多，就迭代改进（谁让我们做的是ToB的产品呢？就是有这样的优势）。

3）快速使用手册：

还记得再做产品设计的时候不是做过业务流程图嘛？

为了能够快速的帮助用户使用产品，我们通常会制作快速使用手册。

这个快速使用手册属于指南性质的文档，主要是以业务流程来串联产品各模块的功能的。

产品使用手册是按照模块视角来讲解各个功能如何使用，那么快速使用手册就是用业务流程来串联各个功能模块的，用户可以通过快速使用手册来高效的完成业务流程切换。

产品功能验收完成后，我们就做了整体产品包的验收及完善，产品包的内容就包括了以下内容了：

1. 产品本体；
2. 产品手册（使用手册、快速使用手册、安装手册等）。

这个产品包就具备了上市的基本条件了，接下来产品就需要对市场人员、销售人员进行后续的支持工作了。

二、市场支持

还记得市场分析阶段的工作嘛？

我们在市场分析阶段确定了产品的细分领域、重点客户群。

在产品研发结束后，我们就需要从产品的角度对市场人员进行支持。

1. 试用

一般公司在这个阶段已经圈定了一批客户做产品试用或产品新功能的使用，产品经理在这个阶段就需要对用户群体进行划分。

我们通常划分的原则是：

老用户 -> 试用新产品：

老用户一般是公司的稳定客户，关系比较深，不容易丢失。

新产品由于功能比较新，可能存在一系列稳定性的问题，我们通常会通过市场部门来联络老用户，免费让其试用新产品或者新功能。

这个时候一定要注意做好产品的切换和备份，一旦出现影响到客户业务进程的问题，要能够快速切换回老系统。

新用户 -> 推荐老产品：

新用户一般是公司刚签约的客户，关系需要进一步维护，我们会给客户推荐运行比较稳定的老产品，逐步让客户变成老用户。

潜在用户 -> 试用新产品：

潜在用户是指尚未承担的客户，我们会给客户推荐新的产品，尽管产品本身稳定性上会有一点小问题，但是新产品往往会有一些新特性；这些特性既有可能打动潜在用户，形成购买，尽管会有一些风险。

客户群体划分完成后，我们会协助市场人员组织用户试用。

这时候需要编写试用的方案，里面包括安装部署流程、应急预案、问题反馈流程等等内容。

切记，试用的目的是在风险可控的情况下搜集用户反馈，所以反馈渠道一定要通常，最好能建立7*24小时的响应机制。

我们公司一般会派一个工程师做驻场，出现问题第一时间反馈、修复。

2. 宣讲

在市场人员熟悉产品特性前，产品经理是最了解产品的人，因此我们在产品上线前的产品宣讲主要是由产品经理来执行的，包括编写宣讲PPT、跟客户沟通、现场演示等工作。

市场人员主要负责组织跟客户的沟通会议。

后续市场人员逐步熟悉产品后，基本上就是市场人员来做这个工作了，产品就不再参与了。

我们的市场人员后续是要参与产品功能测试的，宣讲PPT也是要市场人员来编写，这样的话市场人员讲自己写的PPT、自己做演示的时候就非常顺畅了。

三、销售支持

通过一系列市场行为，当产生一些成单意向的时候，就该我们的销售团队出马了。

那么销售过程中需要做哪些支持呢？ToB的产品最大的坑来了。

几乎每一个ToB的客户（至少是我解除的客户）都会有一些定制化的需求，那么销售在跟客户的时候就需要去客户现场搜集需求；而很多客户在聊需求的时候都需要现场给出解决方案，那么产品经理就需要跟着销售去现场跟客户聊定制需求的解决方案。

解决方案的难以会直接影响到最后的成单价格，所以这个过程我们会非常谨慎，我的套路一般是这样的（希望别有客户看到这篇文章）：

1. 引导使用现有功能

由于客户对产品不够了解，提出来的需求可能现有功能已经可以满足了，但是满足的不够彻底；那么就需要产品经理通过引经据典凭借三寸不烂之舌告诉客户：现在这个功能虽然麻烦一点，但是很强大啊，能完成你的要求的，要不您在试试？

2. 尽量减少改造范围

如果引导失败了，那就给客户出个改造非常小的方案，告诉客户这么小小改一下，虽然不能完全满足你的要求，但是功能上几乎就一样了，您看多好？

3. 拖延时间

如果上面的策略也不行，人家很强势，就要按照他的要求改，就得用拖字诀，告诉客户：您这个方案确实比较好，但是影响范围我现在还不好判断，需要回去整体评估一下再给您出个方案，您看怎么样？

4. 让客户选择

拖延时间完成后，回公司整理客户需求解决方案，一次搞三个：

• 一个就是你提到的尽量减少改造范围的方案；
• 一个是相对比较合理的方案；
• 还有一个就是完全按照客户需求的实现方案（比如这个方案你们不想做）。

然后这三个方案做个对比，想做的改造成本就写的合理一点，不想做的改造成本就写的虚高一点，然后甩给客户做选择。

按照我的经验，不管现场沟通会上客户咋说，最终选择的方案大概率是你想做的那个，别问我咋知道的，反正客户就是这么选的。

一般市场支持、销售支持，工作都是比较琐碎繁杂且时间比较随机，所以产品需要做好时间管理，讲一段时间内的重点工作安排好，这样才能做到能够完成阶段性的重点工作的同时，不会由于忽略某些暂时不太重要的工作。

我一般是按照四象限的方法来对工作重点做规划的，通常是一个月左右的时间做一次更新。

本文由 @Jimmy.jing 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议