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

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

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、终极问题:如何做一个优秀的互联网产品?

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

目录
相关文章
|
数据可视化 安全 搜索推荐
探析低代码开发平台的核心能力
探析低代码开发平台的核心能力
175 0
|
4天前
|
人工智能 数据可视化 数据处理
告别编码难题,低代码平台让应用开发更简单!#高效开发
在数字化时代,企业对应用开发的需求日益增长,低代码平台JeeLowCode应运而生,通过可视化开发、高效数据处理、强大的技术核心和AI智能辅助,大幅降低了开发门槛,提升了开发效率与应用质量,支持多种数据库和丰富的插件生态,旨在让开发变得更简单、更高效,促进企业数字化转型。
35 9
|
2月前
|
监控 数据可视化 前端开发
利用低代码平台加速软件开发:现状与未来
【10月更文挑战第18天】低代码平台通过可视化界面和预构建模块,使非专业开发者也能快速构建应用程序,提高开发效率并扩大参与群体。本文探讨了低代码平台的现状、优势、挑战及未来影响,包括提升开发速度、降低技术门槛、减少维护成本和促进业务与IT协作等方面。同时,文章也讨论了定制化限制、性能问题和依赖性风险等挑战,并提供了实施低代码平台的最佳实践建议。
|
2月前
|
监控 数据可视化 API
探索低代码/无代码平台的崛起及其对开发者的影响
【10月更文挑战第14天】低代码/无代码平台通过可视化工具和预构建模块,使非技术用户也能构建应用,改变了软件开发格局。这不仅降低了开发成本,提高了效率,还促使开发者角色向顾问和策略师转变,加速了创新,扩大了市场。文章探讨了其核心优势及对开发者的影响。
|
3月前
|
缓存 运维 开发者
开发者的利器:Rainbond 赋能你的产品创新
在当今快速变化的技术环境中,普通开发者面临的挑战日益增加。无论是在小型初创公司还是在大型企业中,开发人员都被迫面对繁杂的运维任务、复杂的环境配置以及技术的迅速迭代。这些问题不仅消耗了开发者的时间和精力,也限制了他们对业务本身的专注。为了解决这些痛点,Rainbond 应运而生,它为普通开发者提供了一个友好、高效的解决方案。
|
7月前
|
IDE JavaScript 前端开发
开发者能力的提升之路
开发者能力的提升之路
|
安全 关系型数据库 Java
低代码平台深度剖析
低代码平台深度剖析
229 0
|
运维 监控 开发者
平台工程实践,让应用开发如搭积木一般简单
在过去,传统的应用程序部署和管理通常是一个复杂且耗时的过程。这包括硬件和服务器的采购、配置、维护以及应用程序的手动部署和扩展。随着云原生概念的普及,虽然带来了扩展性、可用性等方面的改进,但也意味着运行单个脚本部署一个完整应用程序的日子一去不复返了。
193 0
|
Kubernetes 算法 安全
隐语1.0设计理念深度解读:让产品易用,让研发也易用。
隐语1.0设计理念深度解读:让产品易用,让研发也易用。
931 0
|
安全 数据可视化 测试技术
【低代码开发】:探索应用开发的未来趋势
【低代码开发】:探索应用开发的未来趋势