开发者七问七答:什么是产品化?

简介: 开发人员天天做的东西,是不是产品?

1

阿里妹导读:

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

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

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

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

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

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

2

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

3

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

4

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

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

5

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

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

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

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

1)定义客户和用户,给出客户画像;

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

3)定义产品核心功能和护城河;

4)明确价值和市场定位;

5)建设产品能力:面向客户;

6)建设配置能力:面向交付;

7)建设开发工具:面向开发(插件生态,小程序生态);

8)降低成本,快速可复制;

9)优化和打磨用户体验;

10)定义商业模式和盈利模式(可选);

11)定义计费方案(可选);

12)建设标杆应用(对于平台类产品适用,如宜搭);

13)联合行业领袖建立标准(头部玩家适用,如office)。

7、终极问题:如何做一个优秀的互联网产品?

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

目录
相关文章
|
机器学习/深度学习 数据挖掘 数据库
从入门到精通:如何成为一名优秀的Python工程师
Python语言近年来在技术领域中越来越受到重视,成为了许多公司招聘的热门技能之一。本文将介绍如何成为一名优秀的Python工程师,从基础知识的学习到实践项目的经验总结,帮助你走上成功的道路。
346 0
|
10月前
|
自然语言处理 前端开发 API
10个常用的无头CMS(Headless CMS)
无头CMS是一种内容管理系统,它将前端和后端分离,只关注内容的创建和管理,而不处理呈现内容的前端界面。传统的CMS通常将内容管理和展示耦合在一起,即内容的创建、编辑和展示都依赖于特定的前端界面和模板。而无头CMS则将内容与前端逻辑完全解耦,提供了一种更加灵活的方式来处理内容。
1925 5
|
存储 弹性计算 运维
Hologres计算组实例&分时弹性入门实践
本文整理自 Hologres 产品团队的观秋老师关于Hologres 计算组实例&分时弹性入门实践的分享。内容主要为以下三部分: 1. Hologres 计算组实例介绍 2. 计算组实例入门实践 3. 分时弹性入门实践
356 16
|
JavaScript Java 数据库
人事|基于SpringBoot+vue的人事管理系统设计与实现(源码+数据库+文档)
人事|基于SpringBoot+vue的人事管理系统设计与实现(源码+数据库+文档)
501 0
PPT 配色方法
PPT 配色方法
177 0
|
运维 Java 开发工具
Flink-Java自建UDF使用案例
Flink-Java自建UDF使用案例
|
前端开发
功能:多文件上传,统一提交
功能:多文件上传,统一提交
428 0
功能:多文件上传,统一提交
|
存储 编译器 C语言
C++ 入门篇之类 & 对象的关系
C++ 入门篇之类 & 对象的关系
|
资源调度 JavaScript
vue项目添加状态管理Vuex,路由router,axios
Vue开发实战02-vue项目添加状态管理Vuex,路由router,以及http请求axios
555 0
vue项目添加状态管理Vuex,路由router,axios
|
云栖大会 Anolis
龙蜥社区用户案例征集开始啦,欢迎投稿!
龙蜥长期征集用户案例,欢迎广大用户投稿。

热门文章

最新文章