开发中我们谈的产品化是什么？阿里是怎么看待产品化？

女爷i 2023-07-17 14:01 14阅读 0赞

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

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

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

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

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

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

![format_png][]

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

![format_png 1][]

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

![format_png 2][]

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

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

![format_png 3][]** **

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

## ##

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

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

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

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

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

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

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

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

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

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

## ##

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

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

![format_png 4][]

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

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

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

3）优化用户体验。

**产品能力的积累和建设**

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

**低成本的可快速复制**

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

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

** **

**优化用户体验**

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

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

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

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

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

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

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

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

![format_png 5][]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

### **7、终极问题：如何做一个优秀的互联网产品？** ###

既然是终极问题了，我没法给出标准答案了，欢迎大家在留言区互动、探讨。

[format_png]: /images/20230528/2aced1102f3847509f15c607f27b806c.png
[format_png 1]: /images/20230528/3e05900bc6bf4f30ac47eb3c6d583916.png
[format_png 2]: /images/20230528/ca80ee916a7e42389e081508dc34053f.png
[format_png 3]: /images/20230528/4a1c8b867a4642fc8f7d7d838617ac2e.png
[format_png 4]: /images/20230528/07021582434745f6a15ab97bd648ba9f.png
[format_png 5]: /images/20230528/0145e5aa342f49508485fb2eff184b07.png