开发者七问七答：什么是产品化？_【阿里技术】

开发人员天天做的东西，是不是产品？...

阿里妹导读：之前参加了企业智能部门如何做，产品化的讨论，大家对产品化的定义和，过程都有各自不同的见解。我觉得这个话题其实可以，扩展下，想站在一个开发人员的视角尝试，探讨一下产品化。下面以自问自答的，方式来展开。

1、当我们在谈产品化时，我们想的是同一个概念吗？

为了更好地理解这个问题，首先要解释“系统、产品、商品”的定义。

我不太想用百科，上的通用定义，如：商品是用于交换的，劳动产品，这对我们今天的话题，没有指导意义，我尝试用更贴近我们日常工作上下文的，方式来给出定义。

系统的定义：各种离散功能组成的，功能集合体。
产品的定义：有使用价值且封装良，好的可复用功能集合体。
商品的定义：以交易为目的的，有使用价值且封装良，好的可复用功能集合体。

举个例子：我用各种零件制作，了一个计时系统，具有计时的功能。给身边的，小伙伴使用没问题，但拿到市场上去，就会被吐槽的体无完肤，“太丑了，感觉好复杂”。

所以我奋发图强，给这个计时系统加上了好看的，表盘和表带，封装成一个颜值高，易操作的产品。看上去专业多了，然后拿到市场上去，就会有人来询盘，多少钱啊老板？

于是我给这个产品定，了个价格，就成了一个商品。

由此可见，系统可以转化为产品，产品也可以转化为商品。

系统转化为产品，的过程就是产品化。产品转化为商品，的过程就是商业化。从系统到产品再到商品，是复杂性逐渐降低，体验逐渐提升的过程。

2、我们开发人员天天做，的东西，是不是产品？

我觉得大部分内部系统开发团队做的都是介于系统，统和产品之间的一种形态。很难将我们现在手头上的几个应用，称之为产品。

如果一个应用只能在一个特定场景给，一个特定客户使用，这是一个系统，并不是一个产品。

产品应该是能快速，复制给多个客户使用的。比如：法务、采购、HRM、财务，等用于公司内部，运营的应用。可以说是业务，能力的集合体，一般满足内部运营，都没什么问题。但拿到外面的，市场上去绕一圈，晒一晒，不一定有竞争力。

更不必说这些系统耦合，了很多公司内部的特殊逻辑，依赖了内部的组件，牵一发而动全身，很难直接复制出去给另一个，公司使用。所以，公司内的很多系统，为了成为真正的“产品”，纷纷开始做产品化的改造。

比如，公司内部项目协作管理平台aone是很好，用的一个系统，但不能说是一个成熟可，复制的产品，因此aone经过，产品化的改造，有了云上版本“云效”。

hsf是很，好的技术中间件，在公司内部使用广泛，但拿到云上售卖还是得经过产品化，封装为edas产品。

3、什么团队需要做产品化？

如果你觉得你做了，几年的系统，积累了较多有，价值的业务能力，在行业里也有竞争力，自信除了现有的使用者，还愿意且有能力服务更多，客户的话。你就需要考虑下产品化，的事情了。

例子：x产品本来是公司，内部使用的办公协作系统，如今产品化向市场开放。

4、开发团队希望将，维护的系统产品化，该怎么做？

我手上维护的BUC、SSO、ACL、VDS，这些都是集团内，使用广泛的系统。

最近一直在做这些系统，的产品化，封装成一个产品叫做，mozi（墨子），两年来，目前这个产品已经服务了集团经济，体生态20多个bu的200多个业务；同时作为基础能力输出，到数字政府领域，已经在多个业务领域，证明了产品价值。

我从我们自己产品化的，经验来讲，如果手头已经有个系统，在这个基础上想做产品化，的话，比较粗略的分，开发团队做产品化具体，可以分为以下几个步骤：

1）产品能力的积累和建设；

2）低成本的可快速复制；

3）优化用户体验。

产品能力的积累和建设

比较容易理解，我们需要提升，产品的使用价值，使用价值是客户来衡量的。对标业界竞品，有差距的补全差距，有优势的巩固优势。这个过程是持续改进的。

低成本的可快速复制

产品要有能力快速服务不止一家客户，这里客户使用方式分为saas方式和，专有化交付方式，saas方式就必须要，支持多租户的能力，专有化交付方式的话，就需要尽可能的降低产品，交付的成本，包括需要占用，的服务器数量，依赖的三方软件等。

去掉不必要的功能，提供最小模块功能集，最好可以让客户，自定义功能集，仅对使用的功能付费。

优化用户体验

这个没啥说的，现在这个时代，颜值就是正义，"dont make me think"。优化视觉，优化交互，优化体验这三件事情要，持续打磨。

5、产品化需要多少投入？

产品化是个持续改进，无限接近完美的过程，而不是一蹴而就，从0到1的变化。

技术部做了个A工单系统，给公司内部的客服，人员使用。虽然界面很丑，bug一堆，但独此一家，别无分店，客服只能一边嫌弃着一边，继续用。

另一个技术部也做了，个b工单系统，在产品质量和用户体验，上深度打磨，推出以后，口碑越来越好，用户越来越多，大量客服纷纷弃前者而来。

从用户视角看，b工单系统的使用价值比a，工单系统高。

换句话说，b工单系统的，产品化程度比较高。B比A更像产品。如下图所示，b比a的产品化，成熟度更高。

但须知“文无第一，武无第二“，b也没法知道自己，的优势能保留多久，也许马上会有其他产品化，程度更高的c产品出现。为了保持领先，不得不持续更新自己的产品，功能和体验。

6、产品化的建议路径是什么？

当然完整的产品化路径，并不仅仅是开发的事情，而是PD、UED、运营、开发、交付、商业一起参与的大工程。

我尝试梳理了下从0到1做，产品化的一般路径，不一定对，以后可能还会补充和删减。

1）定义客户和用户，给出客户画像；

2）定义客户需求痛点以及，产品主要解决的问题；

3）定义产品核心功能和，护城河；

4）明确价值和市场定位；

5）建设产品能力：面向客户；

6）建设配置能力：面向交付；

7）建设开发工具：面向开发（插件生态，小程序生态）；

8）降低成本，快速可复制；

9）优化和打磨用户体验；

10）定义商业模式和盈利模式（可选）；

11）定义计费方案（可选）；

12）建设标杆应用（对于平台类产品适用，如宜搭）；

13）联合行业领袖建立标准（头部玩家适用，如office）。