敏捷咨询总结：你真的懂“产品”吗？90%的人可能都想错了

什么是产品？这个问题表面简单，实则不然。

产品，是提供给市场、用以满足某种需求的事物。

公司销售各式各样的产品——零售商品、金融产品、飞机座椅、汽车。

在软件开发领域，同样可以构建产品：

• 有些是直接产品，如文字处理器、游戏、操作系统。
• 有些则是通往其他产品的渠道，如在线零售、旅游预订网站、移动银行应用、搜索引擎。

本文讨论的产品通常指软件产品，但其中许多概念也远超软件范畴。

首先明确几个基本结论：

• 产品始终存在。它或许并不总是显而易见，但一定存在，并需要被识别出来。
• 每个产品都有消费者。消费者可以使用者，任何从产品中获益的人，无论其是否付费。消费者可以购买者，任何为产品付费的人，无论其是否使用。消费者可以兼具两者身份。
• 每个产品都有生产者。生产者通过以下方式获得核心收益：增加收入，降低成本或避免支出，创造社会效益。

实践中，一种常见误区是将较小的功能模块甚至技术组件误当作产品，却没有明确的客户对象或价值主张。

另一种常见模式是康威定律的体现：设计系统的组织……其产生的设计等同于组织内的沟通结构。

这常导致组织内不同部门（或层级）建立一系列相互关联的“系统”，却很少关注真正的产品或客户是谁。这也是Scrum将此角色称为“产品负责人”，而非系统、功能或组件负责人的原因。

最佳方式是从客户视角思考产品：满足何种客户需求？客户期望是什么？何种改进能让客户生活更轻松？

以汽车为例，产品是什么？是发动机、娱乐系统、方向盘、空调，还是汽车本身？关键在于从消费者视角出发。谁是使用者？谁是购买者？

为自己购车，则既是购买者也是使用者；为孩子购车，则父母是购买者，孩子是使用者。汽车公司设计时必须兼顾两者：父母关注安全气囊与评级，孩子可能在意颜色与多媒体系统。

另一方面，汽车公司自身也是其内部组件（如引擎、娱乐系统、气囊）的购买者与使用者。因此，理解一个产品，必须同时理解其使用者与购买者。

确定了产品，下一个问题是：“它是一个可行产品吗？”

可行产品指能为生产者实现收益的产品，这也意味着需要有有效的方法来衡量收益。目前可以明确，为最大化投资回报率，衡量产品收益是产品负责人的核心责任。

以常见的自动化测试小组或业务分析组为例，它们很少能直接产生可观的ROI。失败案例屡见不鲜：自动化测试小组是在开发产品吗？是的。但其带来的质量提升效益切实可见吗？开发团队会接纳用于测试自身代码的测试环境吗？系统部署后，由谁维护？除非这些工作与开发团队紧密协同，否则很难产生ROI。无论如何，关键在于理解成本与消费者感知价值，并建立反馈机制以确保产品持续可行。

一个重要启示是：定义产品时，标准应尽可能高，同时不忘核心目标。必须从消费者视角找到正确的价值区。消费者需要什么？愿意为什么付费？什么能提供价值？

回到汽车例子：消费者只想买方向盘或座椅吗？不，他们要的是一辆完整的、可用的汽车——这才是能带来价值的产品。

如果团队结构围绕多个零散的价值区建立，会导致产品负责人过多，协调开销巨大。试想：若每个汽车部件都有一位产品负责人，却无人为整车提供统一愿景。

在此架构下，要为某一价值区添加大型特性，就需将其拆解分配到多个组件中。这会带来巨大开销：管理大量依赖关系，引发技能短缺、时间、质量与集成问题。为处理这些依赖，常需设立“特性”负责人来协调并对该特性负责——通常这个角色就是项目经理。

上述模式可能引发一系列新问题：

• 顺序型生命周期：为保持组件间依赖一致，需制定移交计划（如组件B完成后移交组件F），导致流程僵化。
• 不必要的依赖管理与协调开销：在计划驱动中，依赖协调全由管理人员承担（许多是非技术性的）。相反，明确目标并将实现细节交由功能团队，更能获得承诺并快速交付可工作功能。
• 处理低价值特性：特性由不同价值的功能组成。当整体特性被拆解到各组件并由上而下管理时，无法通过反馈识别高、低价值部分。
• 移交、信息分散与高库存：单个特性活动需按顺序完成，移交通过文档规范进行，导致信息孤岛、库存积压与过多交接。
• 忽视客户与整体产品：工作按组件团队的活动组织时，客户自然被置于次要位置。管理依赖、挑战与障碍使得客户反馈反而被视为麻烦。
• 不透明的进度衡量：顺序型方法缺乏反馈，只能衡量计划执行进度，而非价值目标进度。
• 虚构工作：组件团队无实际工作时，为证明存在，可能制造“重要工作”，导致资源浪费。
• 质量低下：过度关注单个组件质量，整体特性质量却被忽视。局部优化损害整体目标，且组件间技术问题常因时间不足而未妥善解决，长期必然引发技术债务。

因此，不应只考虑组件，而应视作一个整体（更大）的产品。这需要过程，且产品负责人需有能力协调众多开发团队。

记住，理想的产品负责人如同创业者——无论产品大小，产品愿景只应有一种声音。正如一家公司只有一位CEO，无论员工是100名还是10万名。

这即圣诞老人规则。圣诞老人再忙，也不会找来其他圣诞老人帮忙。他如何应对？依靠精灵。随着产品规模扩大，产品负责人应减少参与日常战术事务，更聚焦于战略与方向。他可以从团队、利益相关者、助手（精灵）那里获得帮助，将战术工作委派出去。作为圣诞老人，他可以授权，但依然对圣诞节的完美呈现负最终责任。翰德恩咨询认为， 明确这一责任归属，是确保产品在扩张过程中不偏离愿景的核心。

价值区之间的共享服务，本质上是技术层面的依赖管理与集成。随着持续集成、基础设施即代码和测试自动化的普及，这一领域已得到较好理解。技术层面的依赖协调更具可预测性：最终要么拥有一个可工作的产品，要么一无所有。

相关课程：

精益产品创新