站在一个开发人员的视角探讨一下产品化

• 相关概念?
• 开发人员天天做的东西，是不是产品?
• 什么团队需要做产品化?
• 怎么做?
• 需要多少投入?
• 建议路径

相关概念?

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

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

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

大部分内部系统开发团队做的都是介于系统和产品之间的一种形态。很难将我们现在手头上的几个应用称之为产品。
如果一个应用只能在一个特定场景给一个特定客户使用，这是一个系统，并不是一个产品。

产品应该是能快速复制给多个客户使用的。

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

什么团队需要做产品化?

做了N年系统+积累了较多有价值的业务能力+行业里有竞争力+愿意且有能力服务更多客户 => 需要产品化

怎么做?

具体可以分为以下几个步骤

产品能力的积累和建设

提升产品的使用价值(客户来衡量)

低成本的可快速复制

有能力快速服务不止一家客户,使用方式分为

• saas方式(支持多租户)
• 专有化交付
  • 降低产品交付的成本
    • 服务器数量
    • 依赖的三方软件

去掉不必要的功能

• 最小模块功能集
• 可以让客户自定义功能,仅对使用的功能付费

优化用户体验

视觉/交互

需要多少投入?

持续改进

建议路径

PD、UED、运营、开发、交付、商业一起参与做产品化的一般路径

• 定义客户和用户，给出客户画
• 定义客户需求痛点以及产品主要解决的问题
• 定义产品核心功能和护城河
• 明确价值和市场定位
• 建设产品能力：面向客户
• 建设配置能力：面向交付
• 建设开发工具：面向开发（插件生态，小程序生态）
• 降低成本，快速可复制
• 优化和打磨用户体验
• 定义商业模式和盈利模式（可选）
• 定义计费方案（可选）
• 建设标杆应用（对于平台类产品适用，如宜搭）
• 联合行业领袖建立标准（头部玩家适用，如office）

原文链接 (opens new window)