在客户对产品方案心动并感到满意之后，下一步要做的，便是推进项目落地，那么作为B端产品经理，你要如何做好这一步？也许，你可以借助POC，即“概念验证”来实现，让客户感受到产品可能的功能与实际效果。本文便讲述了如何做好项目POC的注意事项，一起来看。

前文给大家讲述了如何用方案打动客户，那么在客户对我们的产品方案动心后，需要做些什么促进项目落地呢？按照“大B”产品的思路，我们往往会开始进入POC阶段，让客户切实感受产品的功能及效果，本文将给大家阐述有关B端产品POC的知识。

部门遇到新的商机项目，经过几轮方案沟通后，客户对产品表现出极大兴趣，但是由于没有试用过，有些不信任，公司希望极力拿下这个项目，提高营收；

1）自身现状

产品能力：单一产品无法满足客户需求，最终方案由多个产品组合赋能。

2）客户现状

1. 期望：对我们的方案有倾向性，但是不自信。
2. 竞争：客户收到多个厂商的方案汇报，竞争对手较为活跃。

小结：当前的矛盾是如何增强客户信心，击败竞争对手。

针对以上矛盾，此时最常用的合规手段就是产品POC，那么什么是产品POC呢，POC（Proof of Concept），即概念验证。通常是公司做产品选型或开展外部实施项目前，进行的一种产品或供应商能力验证工作。由准备参与投标工作的供应商进行产品部署，交由招标公司进行试用，并对产品能力进行打分，以此确保供应商具备良好的产品或项目交付能力。所以POC参与的两个对象是：

1. 供应商：提供产品能力用于测试验证；
2. 客户：负责产品测试及打分。

1）产品的功能：后期需要交付的产品功能，根据客户提供的需求，罗列功能清单；或者由客户提供所需要的功能清单均可。

产品的功能包括两个部分：

1. GU能力：即提供具备可视化界面能力的产品系统，方便非研发人员使用。
2. API能力：提供API或者SDK，便于客户（需要具备研发能力和研发环境）进行研发测试。

2）产品的性能

即对产品所要求的性能指标，通常由公司提供给客户做参考，也有客户会提出业务要求；一般在准备性能指标时，建议提供具体性能指标所应用的环境及硬件设备等测试环境要求，便于对指标约束。

1）产品的相关文档：包括产品介绍文档、产品使用手册、产品白皮书、接口文档等，详细的文档方便客户查询，也会很好减轻对接工作。

2）企业资质材料：如安全认证、软著等材料，一般多用于正式投标阶段，POC如果准备，可以有备无患。

3）人员服务态度：在POC阶段是最容易忽视的一项事项，因为没有任何的明文要求，所以往往无意识，好的对客态度，往往能起到事半功倍的效果，可以给客户建设出两个心理状态。

• 重视项目：态度积极，客户会感觉自己被重视了，本次的项目我们是非常有诚意有信息的。
• 运维积极：对待问题不回避，响应及时，会让客户觉得我们及时后期项目交付后，也能积极响应运维问题，不会交付后，就开始甩手爱答不理。

小结：产品硬实力和企业软实力是相辅相成的，在跟友商的比拼中，如果产品硬实力过硬，那可以直接实施降维打击，获得头筹，如果双方产品硬实力相当，一定要凸显软实力态度，给客户良好的主观印象，也有利于后续的商务打分。

理清了上面POC概念和目的后，就是要考虑如何POC，以及如何把POC做好，赢得客户的信任，争取最大机率将项目拿下，做好POC，我们可以从以下方向出发。

1）人员安排

由商务或者具体对接人进行协调安排，组建对接群，将双方的人员组织到同一个沟通群，方便快速沟通和应答；具体的人员角色可以安排参考如下表格，其中供应商侧最好是各个角色都有对应同事参与，以便解答客户各类问题（实际过程中各类问题会频繁问到）。

如果有条件，建议安排一位记录员将客户问题记录汇总，一方面可以收集客户问题用于产品迭代提升，一方面可以避免在正式中标后，产品部署时避免踩相同的坑。其中双方总负责人既要负责具体产品验证工作，还要对接商务问题，如果项目较大，可以灵活安排多位分负责任人，分别管理不同产品模块的POC。

2）POC启动

人员安排好后，下一步准备启动POC，具体可以从以下3个方面开始着手，如下：

① 准备POC测试方案

由供应商根据客户提供的需求清单，准备一份详细的POC测试方案，测试方案内容要包括“测试目的”、“测试人员及职责”、“测试时间”和“产品功能”，其中产品功能模块要包括产品验证的功能、操作流程、预期结果、打分规则等，后续案例详解将详细描述。该环节的人员职责如下：

1. 核心人员包括：双方总负责人、供应商产品经理；负责输出整体方案，形式以word或excel为主。
2. 其他参与人员：技术工程师和测试工程师，负责对POC方案评估，确保可行性。

② 部署POC测试环境

测试方案准备完后，根据需要测试的产品功能准备硬件环境和软件包，其中硬件通常由客户按照供应商要求准备，有些政企客户由于日常使用设备较为老旧，也可以是由供应商准备，测试环节准备要点如下：

1. 硬件：确保硬件条件与日后实际交付的硬件条件尽量一致，尤其是AI类产品的GPU型号及参数一定是符合技术要求的，否则无法确保算法效果跟宣讲的一致。
2. 软件：由产品经理从公司申请软件包，以License授权的形式打包，在POC测试期间可用，超过时间期间，授权将失效，无法使用，确保公司的软件资源不会因为复制或者其他因素流失。

③ 进行POC启动会

测试环境部署完后，就可以交付客户进行产品验证了，但是在这之前，建议准备一个启动会，一方面宣告POC可以正式启动了，同时宣讲测试细节；另一方面也是拉齐双方人员正式认识，同时对领导的交代，项目工作已进入新的阶段，该环节需要注意的要点如下：

1. 角色明确：客户各个参与测试的人员明确。
2. 材料归档：每天的测试结果需要统一汇总，并有固定的地方归档。
3. 信息同步：除了日常群消息交流外，需要邮件作为正式沟通形式同步测试结果和重要需求。

POC进入测试环节即转变为由客户进行主导，换句话说此时的测试是半可控状态，一方面客户会按照测试方案进行验证，此时基本是按照预设的形式在推进，另一方面有些客户测试人员会随意测试（大概率是破坏性的），尤其是AI类产品，无法预判客户自己准备的数据集是如何，可能引发很多预期外的问题，需要产品经理和技术工程师时刻准备着。

一般POC的测试验证可以包括集中测试和主观测试两个阶段，具体如下：

1）集中测试

客户根据测试方案对产品功能和模板进行集中化测试，在2-3天内将测试方案中的所有功能和性能验证完，并打分，供应商可以安排驻场人员根据客户测试需要进行现场指导，在指导过程中，可以适当引导客户，以利好于测试结果，便于最终项目成单，注意要点如下：

① 功能测试：客户按照测试流程确保实测结果与预期结果一致，如果不一致，按照计分规则打分，供应商需要监督客户确保测试流程符合要求，以证实扣分是有效的。

② 性能测试：性能测试较为困难，包括产品性能、算法性能、产品稳定性、安全性等，一般有3个方式推进：

1. 如果是具备研发能力的客户，可以是由客户自发测试评估。
2. 如果客户是不具备研发能力的，可以找第三方测试厂商对产品性能测试验证并出具测试报告。
3. 如果客户不具备研发能力，还可以与供应商达成一致意见，由供应商出具测试报告，并附加测试公正性及可行性保证承诺。

2）主观测试

在集中测试后，客户可以扩大测试范围，包括测试人员，测试边界，测试时间，该环节主要由功能测试转向产品易用性、稳定性等测试，如果是AI类产品，还可以考虑扩大数据集，做更多边界测试，确保产品对实际业务环境的适应性。

所有的测试完成后，即意味着POC阶段就要结束了，下一步就是需要对该阶段做一个收尾工作了，可以包括如下：

1）归档总结

将所有测试的信息进行材料归档，并输出总的测试验证报告，材料中需要包括5要素，“人、时间、测试模块、测试用例、测试结论及分值”，最后发送测试验证报告，其必须是由客户以正式沟通形式（邮件）形式发出，并抄送相关领导，作为供应商产品经理，在客户发出测试验证报告前，需要再次确认内容准确性

2）商务跟进

由于很多公司各司其职，作为供应商产品经理经常会忽略最后的“商务跟进”，虽然不一定要亲自跟进，但是一定要推动销售或者售前跟进POC之后的商务情况，比如客户还有什么新的需求，后续是否要分期、招投标时间，本次POC通过的供应商有几家等

案例说明章节以供应商产品经理视角给出如何编写POC测试方案的产品功能模块的模板。

1. 首先确定测试模块所占分值，然后评估每个功能所占的分值，不超过该模块的总分值。
2. 给出产品功能的操作流程、预期结果，其中预期结果中给出每个功能点的分值，其中仅核心功能给到分值，其他常见基础功能不需要占分。

具体的模板样例可以如下：

作为对外的toB产品经理不管角色是客户还是供应商，都会不可避免的遇到项目POC，所以了解项目POC，并做好项目POC非常重要，如果角色是供应商，做好项目POC，就有很大机会推动项目落地，如果角色是客户，做好项目POC，就可以严控供应商质量，不会后期因为采购到不靠谱的供应商，耽误业务进度，被公司发难。

专栏作家

Eric_d，人人都是产品经理专栏作家。关注AI、大数据等领域，擅长需求分析、产品流程和架构设计等，日常喜欢徒步。

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

题图来自 Unsplash，基于CC0协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。