编辑导语：to B项目交付经验我们都看过了不少，然而“软硬一体”产品却并不是很常见。本文作者作为BAT某厂B端方向的一名商业产品经理，回顾了其刚完成的一项“软硬一体”产品的交付过程，通过把项目流程、遇到的坑和总结的经验写下来做一次复盘，同时也分享给有需要的小伙伴们。

“软硬一体”的产品与通常的软件、硬件、服务三大类产品形态不同，在产品商业化交付过程中存在特殊性。

本篇将介绍：“软硬一体”类音箱产品的交付过程，该产品类型对整个项目流程有哪些影响，以及产品经理在此类项目中的注意点。

一、交付的“软硬一体”产品是什么?

我们交付的是一款类似智能音箱的产品。

这款产品可以通过语音唤醒和识别、解析用户的语音命令，进而像网关一样控制用户家中的其他设备。

之所以称之为“软硬一体”的产品，在于产品包含了硬件设备本身，更包含了硬件芯片上的应用和配套的云端语音服务——用大白话来说，就是给客户交付的不仅是电子产品的元器件和外壳，还有跑在芯片和云端服务器上的代码。

二、“软硬一体”产品从0-1开发交付中产品经理负责什么？

我们交付的这款类智能音箱产品是大厂两个部门（负责硬件设计的基础技术部门+负责商业化的部门）合作落地的，所以从0-1过程中涉及硬件产品经理和商业产品经理两种PM角色，大家的负责的阶段和侧重点不同。

笔者作为商业产品经理，主要负责对接产品设计开发后半程的部分以及商业化的部分（下图虚线内部分）。

需要强调的是，TO B项目通常是发现商机且和客户有初步需求沟通后才开始产品设计、开发。

但笔者参与的“软硬一体”项目属于比较特殊的情况，是大厂基础技术部门设计开发完硬件部分后，商业化部门再针对设计好的硬件发现商机，并根据客户需求开始固件层面的应用定制（即上图中固件设计与开发）——固件层面的应用由商业化部门负责开发。

因为这部分应用是和客户需求以及业务逻辑强相关的，交给冲在前线的业务部门才更合适。

在这种项目背景下，硬件产品经理负责推动芯片设计再到电子设计等硬件设计研发流程。商业产品经理主要根据B端客户的需求定制应用，同时把控商业化流程和工厂测试、生产各个过程中的节点。

过程中若遇到硬件相关的问题，再找硬件产品经理沟通——例如客户对产品价格接受度有限，商业产品经理就会找硬件产品经理沟通硬件规格的简配，进而调整用料成本和出厂价格。

三、交付“软硬一体”产品的B端项目有哪些特点

“软硬一体”的产品对在交付中有一些需要注意的点，因为一般情况下产品形态可分为：软件、硬件、服务三种。

但当你向Ｂ端客户售卖的产品涉及到“软件”、“硬件”两种形态时，你的产品备案、项目评审、产品开发、交付验收都会复杂一些，下面分别说说对四个方面的影响。

• 产品备案（系统地向产品管理委员会定义产品，包括成本、售价、折扣、竞对等）；
• 项目评审（销售发起商机评审、项目信息评审、合同评审的流程，确保项目盈利）；
• 产品开发（自身软件产品开发、客户适配开发、代工厂生产装配）；
• 交付验收（主要验收硬件的到货数量、包装，以及定量验收整体产品的功能）。

1. 产品备案

产品备案是大厂B端产品进行商业售卖的必备流程。

“软硬一体”的产品一般要在系统里备案为两个产品——例如我们的类音箱产品，就在系统里备案为一个“硬件”产品加一套“软件”服务，因为硬的部分和软的部分无论从成本核算、开票及计算毛利、客户经费限额上都存在很多差异。

例如：软件的成本一般为服务器的分摊折旧成本，随着产品数量增加，它的边际成本在一定范围内可以认为是0——当软件服务被调用的并发量不超过一定限额时，不需要加服务器，可以认为成本是不变的。

而硬件的成本则是随着产品数量的增加，以分段线性的方式增长，这里分段的原因主要是产品量产后，硬件代工厂的成本走阶梯定价（参考下方示意简图）。

所以“软硬一体”的产品拆为“软件”和“硬件”进行备案，对TO B项目的成本核算都带来诸多便利。

同时，软件的开票税率为6%，而硬件部分的税率为13%，拆开备案有利于财务分别进行计收。

也有利于预算员在审核项目时，分开计算两部分的税后毛利（即扣掉相应比例税额后的毛利）。财务和预算作为商业化过程中，产品经理接触最多的两个职能，降低与他们的沟通成本能大大缩短内部沟通、审批的时间。

除了降低与内部职能部门沟通成本，“软”、“硬”拆开备案也更贴合客户的经费审批规律。

我们经常遇到客户对合同的开票类型有所要求——客户的整体项目经费必须按软件、硬件2：8消耗，所以我们必须开出对应比例的发票给到客户。如果我们的类音箱产品仅备案为一个产品，往往仅能归为硬件产品，开硬件发票，白白少赚了20%的客户经费。

所以将“软硬一体”产品的软、硬部分拆开进行产品备案，能简化TO B项目的成本核算、降低内部沟通成本，同时更加贴合大多数B端客户的需求。

2. 项目评审

我们厂B端项目评审主要分为三个节点：商机评审、项目信息评审、合同评审。

前两个评审环节主要是由销售和售前架构师负责向项目评审委员介绍客户信息、项目交付的产品、产品维保范围、项目利润、项目进程等核心信息；第三个评审环节，是由大厂法务主导，对项目合同进行评审和意见修改。

在第三个环节，“软硬一体”的产品往往会受到法务和财务较多的挑战，需要产品经理花费较多时间向这些职能部门解释到底卖给客户的是怎样的产品形态，如何交付，如何售后维保。

其中，法务对于合同的服务维保特别关注，这里需要明确“软”和“硬”两个部分的区别。

在笔者接触的TO B项目中，软件的服务维保有效期通常为3年，即产品激活后3年内需要保证客户软件的迭代和更新。硬件的服务维保通常按国家三包政策，责任范围内免费质保一年，一年后提供有偿维保服务。

3. 产品开发

由于我们给客户交付的“软硬一体”类音箱产品涉及到两个部门（上文所提的基础技术部门和商业化部门），其实“软”和“硬”的部分开发周期是不耦合的——我们是在硬件设计开发完成后才根据客户需求进行软件应用的设计、开发。

这里的软件不仅包括设备端上的固件代码，也包括配套的云端服务。设备端上的固件代码开发、迭代周期以周，甚至天为单位，在签署合同到第一批产品交付的半年内，我们软件一共迭代了100多个版本。

“软硬一体”的产品最关键的是要将OTA应用做好、做robust，这样产品在量产交货后还可以持续不断地迭代，降低了项目交货前的交付压力——最如果OTA应用如果出了问题，产品交付后终端用户无法操作升级，若出现BUG只能走返厂刷机的方式。

4. 交付验收

对于”软硬一体”的产品和项目交付，验收的过程往往比纯硬件产品的交付验收更加复杂。

硬件产品的交付验收通常只要核对了硬件数量及配置无误，插电可用后，客户即可签署验收单。但“软硬一体”的产品往往要对产品软件部分的性能进行更加定量的测评，测评会根据产品的功能要点，定义具体的测评标准，例如：

• 产品算法的准确率达到95%
• 服务的稳定性（SLA)达到3个9
• 服务链路的耗时不超过200毫秒
• 诸如此类…

对于我们交付的类音箱产品，客户主要在意的是诸如唤醒率、识别准确率等百分比。客户会在我们的指导下或者邀请第三方专业测评机构进行现场验收测试，实测指标没有问题后，再签署验收单。

四、产品经理的职责注意点

综合上文，在“软硬一体”产品交付中，个人认为产品经理最重要的职责有两点：

1. 定义清晰产品中“软件”和“硬件”分别是什么，并向销售、售前架构、法务、财务等同事阐明这一定义

有利于他们分别向客户进行产品宣传、推进产品商业化中的各项流程性工作。同时，清晰的定义有助于产品经理在开发过程中、及产品交付后快速定位产品问题所在，找到负责的研发。

例如：如果我们的类音箱产品出现唤醒问题，到底是该找负责结构件的硬件工程师，还是负责端上固件代码的嵌入式工程师，还是负责云端链路的后端工程师呢？

这部分判断起来对非技术背景出身的产品经理可能有难度，需要找架构师协助，但尝试去深入理解产品中的“软件”和“硬件”还是非常有必要的。

2. 根据产品“软硬一体”的特性，把控好TO B项目的设计开发和商业化流程中的各个时间节点，梳理好各个节点的依赖关系

例如在产品备案时对硬件部分需要进行过充分的验证，并敲定硬件配置，否则备案时产品的成本无法明确，在备案完成后更换硬件需要重新走多项审批流程。

产品设计开发和商业化流程两条线并不是独立的，而是交织在一起互相依赖的，产品经理需要通过积累项目经验、踩坑经验才能不断完善流程和节点把控能力。