■从项目制到产品制之2：产品化运作的成熟度

[摘要]
从项目制到产品制，说来只有6个本质不同，但实施起来并非易事。所有产品都需要每两周发布一次吗？不管什么类型的产品，都需要投入大量精力做用户研究吗？是否每个产品都应有一致的增长和运营策略？哪些产品做“虚拟”端到端团队就够了、哪些产品必须有“实体”的端到端团队？怎样才算够“产品化”了？
“什么是数字产品我大概了解了， Top 10的战略产品我们也薅出来了，然后呢，下一步该怎么办呢？”
“有些是技术平台型的产品，也需要两周发布一次吗？”
“我们已经尽力让业务、运营、开发和测试都坐一起了，这样是不是就够了？”
“从项目制到产品制，中间有很多过渡态我能理解。那到底要多‘产品化’才算够了呢？我们做了用户研究、制定了成效价值指标，是否就已经足够‘产品化’了呢？”
“......”
作为组织中产品制转型的推动者，在“确定正确的产品边界”以后，可能很快就会想到这几个问题。从项目制到产品制，说来只有6个方面的不同，但要实施起来，却没有可以一二三按部就班的套路。上面这些问题的背后，本质上是源于：

如何认知当前产品化运作的状态？产品化运作包括哪些实践？哪些实践够了，哪些实践还不够？
各种不同类型的产品，产品实践的侧重点会有不同吗？
如果想要提升产品化运作的成熟度，如何设置适宜、合理的目标状态？
转型的路线是如何的，哪些产品实践是应该尽快去实施的，哪些实践可以缓缓？

本篇就来谈谈这些问题。
1. 如何认知当前产品化运作的状态？
前文谈到，产品制的本质之一，是要如何应对“不确定性” ，构建快速响应外部变化的能力；
而从另外一面看，我们看到了数字产品的容器——大型组织作为一个超级复杂系统，所具有的“复杂性” ，与天生具有产品基因的中小型互联网企业相比，这是转型组织所遇到的完全不同的一面。
在应对外部不确定性上，有四个值得考量的维度：

用户中心（User-centered）：项目制里面基本上是忽略用户的，只是按计划去执行；产品思维最核心之一，就是要以用户（注：这里泛指产品的购买者及使用者，下同）为中心，深入洞察用户，挖掘用户真正需要的，解决用户真正的问题，要求团队有足够深入的用户研究和洞察实践，真正同理到用户、洞察不同细分用户群体的需求、主动探索与用户一起共创方案等。
价值驱动（Value-driven）：以产品为中心，要求管理的核心要素从项目的范围、时间和成本转向给用户带来的实际价值和质量。产品愿景是否清晰？愿景目标是否完全对齐？是否有基于用户实际价值的成功度量？是否综合考虑了用户、客户（购买者）等多方干系人、短期和长期的综合价值？是否提前就需求设想的价值进行了验证？是否总是基于价值进行优先级排序？
快速响应（Rapid Response）：对于不断变化的环境和用户问题，是否总能小步前进、快速上线验证、滚动规划频繁发布？有明确跟踪从想法到上线产生效果的周期、并努力缩短这个周期吗？
持续增长（Continuous Growth）：从0到1后，是否能端到端地对产品的整个生命周期负责，持续关注产品的增长？有明确的获客策略和留存策略及渠道吗？是否进行持续的成效指标数据跟踪、并根据数据来调整策略？

在应对组织内部复杂性上，有两个不可忽略的维度：

沟通协作（Communication & Collaboration）：团队是否对产品有强烈的Owner意识？产品团队契约的关键仪式是否总能按时开展？是否都主动沟通、通过有效地会议进行决策？跨部门跨团队地协作是否顺畅？有没有持续积累产品、业务、技术、实践等一切相关的知识库、并形成持续分享的学习文化?分页标题
治理管控（Steering & Governance）：团队产品相关的愿景、目标、决策信息是否充分透明可视？组织是否能容忍失败、不断培育实验文化？是否构建了充分的跨职能团队、团队是否能够充分自组织？是否支持滚动预算？是否形成持续改进的习惯和文化？

如果把这内外部的六个考量维度放在一起，就会形成如下的一个框架（Digital Product Management Framework, 以下简称DPMF) 。以这个框架为一个基点，通过考量在这些维度上的实践情况，可以对组织当前产品化运作的状态建立一个初步、系统的认知。

本文插图
图1 认知数字产品管理的成熟度 - DPMF

本文插图
图2 认知数字产品管理的成熟度 - 不同维度下的产品实践
比如价值驱动维度：

产品愿景定位（Product Vision Clarity）：产品愿景、价值定位、愿景陈述（电梯演讲）等；
愿景目标对齐（Visions & Goals Alignment）：战略目标上下对齐（精益价值树）、产品路线图、可视化规划路线等；
成功度量（Measures of Success）：成效指标体系、目标度量、机会点度量、举措度量、特性度量等；
系统性价值分析（Holistic Value Analysis）：价值决策因子矩阵（涵盖所有干系人、短中远期)；
早期价值验证（Value Validation）：原型测试、MVP等；
持续按价值优先级排序（Continuous Value-based Prioritization）：价值决策矩阵、周期性优先级决策会。

【■从项目制到产品制之2：产品化运作的成熟度】2. 各种不同类型的产品，产品实践的侧重点有什么不同吗？
“数字产品在组织中的核心定位” ，即数字产品所提供的核心能力，如果粗略地来讲，有三种倾向性：
种倾向性：

本文插图
图3 以一个大型金融企业为例，数字产品的核心能力

业务流程/逻辑导向型（Business-oriented）：数字产品的核心价值在于对于核心业务流程、业务逻辑自动化和封装，比如金融企业中的支付结算系统、卡管理系统、统一支付平台，业务中台服务如统一账户服务，以及内部作业系统如移动办公应用、采购系统等；

用户体验导向型（Experience-oriented ）：数字产品的核心价值在于为用户提供在各个触点上都非常好的互动体验，比如手机银行、线上理财、在线投融资、金融教育视频内容等；
技术能力导向型（Technology-oriented or Data-oriented）：数字产品的核心价值在于提供不可或缺的技术或数据能力，比如DevOps平台、基于大数据分析的用户画像中台服务、通用技术能力AI算法服务等；

本文插图
图4 企业中的数字产品型 B.E.T
这三种不同模式的产品，在产品管理实践的侧重点要求是不同的：

模式B - 重点投资的业务逻辑导向型数字产品：此模式的产品，在价值驱动、沟通协作和治理管控维度上需要更高的成熟度；
模式E - 重点投资的用户体验导向型数字产品：此模式的产品，在用户中心、价值驱动、快速响应、持续增长等方面需要更高的成熟度；
模式T - 重点投资的技术能力导向型数字产品：此模式的产品，则在价值驱动、沟通协作、治理管控上需要更高的成熟度。

3. 提升产品化运作的成熟度，如何设置适宜、合理的目标状态？

本文插图
图5 ThoughtWorks数字产品管理成熟度模型 - 实践成熟度等级
为了提供指引，在DPMF中，提供了从-1到3五个级别的成熟度等级。以成功度量实践为例，这五个级别的含义分别为：

本文插图
图6 ThoughtWorks数字产品管理成熟度模型 - 实践成熟度等级示例
所有产品都需要每两周发布一次吗？不管什么类型的产品，都需要把用户研究做到极致吗？是否每个产品都应有“一致”的增长和运营策略？哪些产品做“虚拟”端到端团队就够了、哪些产品必须有“实体”的端到端团队？答案肯定是不同的，甚至整个组织本身的状态也会影响到成熟度目标的设定，好比变速档要适合坡的高度，否则适得其反——“流畅”就好，而不是“等级越高越好” 。
例如，在一个“数字化转型”有着广泛认知、“敏捷性”深入人心、科技为核心、IT基础平台和创新基础设施已到位的组织里，产品制相对来说有一个较好的土壤，在产品管理成熟度目标可以设置相对得高一些，如模式B的价值驱动、沟通协作、治理管控维度都设置到了最高；模式E则在用户中心、价值驱动、快速响应和持续增长都设置到了最高；模式T则在价值驱动和治理管控上接近最高。

本文插图
图7 不同数字产品型的成熟度目标要求不同
4. 如何构建一个有效的转型路线？
如果应用模型，想要对组织内产品运作的成熟度进行评估，建议步骤如下：

参考上面的数字产品型定义B.E.T ，在组织中识别出需要评估的重点产品；
设定组织中B类型、E类型、T类型的在各个维度上的目标；
深入了解和熟悉每个产品的背景、特点，以及确认是模式B、E还是T；
对每个产品，通过团队成员访谈、实践活动观察、输出产物查验等方式，依次针对6个维度，对照每个分类实践的等级定义，识别每个分类实践当前的状态；
参照组织中对应产品型的目标状态，设置该产品在3-6个月左右想要达到的目标状态，建议选取1-2个重点维度进行提升；
识别在这1-2个重点维度上应提升的实践能力（含团队级别的实践和组织级别的实践）
制定出3-6个月内的实践能

下图展示了，一个组织中3个产品团队的成熟度评估结果，可以看出，每个产品团队提升的侧重点实践会是不同的。

本文插图
图8 不同数字产品型成熟度目标要求不同
藉由成熟度评估的结果，对比组织中对相应产品型的成熟度目标，那就可以制定出相应的实践实施路线图：

按照产品目标相关性及紧急性两个维度，把与目标有差距的实践放在这个矩阵上；
第一优先级为近期聚焦实践；第二优先级为中期聚焦实践；第三优先级为远期聚焦实践。

如图所示，这是上图中的统一支付平台产品团队的实践实施路线图：

本文插图
图9 产品团队实践实施路线图-示例
值得注意的是，在进行实践能力提升时，一些是团队内部自己可以提升的，比如成效度量、用户研究；一些却是在组织层面支撑需要提升的，比如滚动预算、跨职能团队。分页标题
5. 该如何有效使用DPMF？

本文插图
图10 应该如何理解并使用DPMF

这仅可用作一个参考框架，而不能作为一个通用的固定模型。如同《成熟度模型：罪与罚》中提到的， “只有结合组织和业务上下文的成熟度模型才可能产生正向的成效” ，并不存在一个“普适的”、“标准的”产品成熟度模型。每个组织都要基于自己的外部环境和业务上下文，来去选择其中的维度，或者补充其他的维度，或者是把某个维度细化、拆解，基于自己组织的情况来定制或裁剪。
即便是定制好的产品成熟度管理模型，目的也只是为了得到更全局的系统性认知、站在组织视角去审视产品制转型的聚焦点，而不是为了评估和解决数字产品本身的问题。例如，当发现组织产品创新性不足的时候，不是简单地去让各个团队在规定时间内提交若干“创新的idea“ ，而是系统性地看看，主要问题出现在哪方面：是因为没有足够的用户调研能力？没有为市场调研和用户研究提供投入？还是战略目标不清晰、行动举措忽左忽右？还是组织缺乏“实验文化” ，团队因为害怕“失败的创新尝试”影响绩效而不敢有所行动？
各个维度上的衡量结果，不反映不同组织进行横向对比的优劣，也不能反映出不同团队的绩效差异，不能用作对团队绩效的衡量。
实践成熟度要达成的目标，应追求“流畅”——即与组织上下文匹配，而不是越高越好；不用去攀比，非要达成一个看起来“很高”的等级，走形式化会适得其反。
即便是定会好的评估模型，仅仅是为了有一个认知基点，需要不断演进和迭代，而不是提供一套行为规范、强制所有团队一成不变地照此执行。

下一步？
了解了当前组织中产品化运作的成熟度，如何有效提升团队的产品实践能力？团队级实践怎么办？组织级实践怎么办？如何能实现更轻量级的规划？数字产品的成效和进展如何度量？且等后续分解。
文/ThoughtWorks 亢江妹王汝佳
更多精彩商业洞见，请关注微信公众号：ThoughtWorks商业洞见