下载掌阅APP，畅读海量书库
立即打开
不管你选择开发什么产品，改变开发、测试和部署方式都至关重要，但很多公司只是变成了更有效率的功能工厂。它们发布了大量的新功能，却看不出这些功能对用户有什么价值，也看不到它们对业务有什么影响。事实上，大多数公司产品路线图上的功能和项目，只有一小部分能够产生正向的投资回报。大多数行业分析师认为投资回报比例在10%～30%。
请你将公司真正需要的功能列表与新发布功能产生的实际成果比较一下，如果新功能没有带来预期的回报，那么改变解决问题的方式就变得至关重要。这个问题的根源在于，这些功能团队的设置是为公司内部的利益相关方服务，而不是以对业务有利的方式服务于公司的用户。
业务主管和其他公司利益相关方了解他们自身的具体工作需求，于是他们会列出可以帮助自己完成工作的功能和项目列表。他们将这些工作作为优先事项交给功能团队，然后要求对方提供标明交付日期和交付成果的产品路线图。
那么，为什么在这份产品路线图里的功能中，只有极少数能够真正产生预期的回报呢？请注意，产品路线图里的每个功能都是针对某个潜在问题的潜在解决方案。它可能是与用户相关的问题，例如用户无法弄清楚如何有效使用产品；它也可能是与公司相关的问题，例如产品的服务开通成本太高。
在功能团队模式中，产品路线图里的功能首先由功能团队的设计师设计，然后由功能团队的工程师开发。但是该功能是否会为你的用户或公司提供价值，则取决于谁在路线图上要求开发该功能。这通常是公司利益相关方，他们可能了解自己的需求，但对科技产品至关重要的新兴技术缺乏深入理解。他们也很少有机会与用户就他们的需求和问题进行交流。因此，在功能团队模式中，你无法要求功能团队对业务成果负责。功能团队仅负责产出，即功能的实现。如果某个功能没有产生预期效果，功能团队可推卸责任，表示他们是按照相关指示开发功能。
但是，下达指示的公司利益相关方也不想对失败负责，这也是事实。他们大概率会称交付的功能不是他们期望的那样，或者交付时间比他们预期的时间长。这就是公司利益相关方和功能团队之间普遍缺乏信任的原因。功能团队模式产生的另一个不良后果是积累大量“孤儿”功能，这些功能没有产生真正的价值，但一直在等待未来某一天可能得到更新迭代，而这种情况很少发生。结果就是技术债务会迅速积累，可能导致管理失控，最终大大拖慢功能团队的进度。在最糟糕的情况下，这种模式甚至可能使整个业务陷入瘫痪。
无论出于什么原因，一旦公司不能为用户持续创造价值或失去创新的能力，竞争对手就能够通过更具吸引力的解决方案抢走用户，这只是时间问题。 这种情况已经在无数公司上演。你当然可以打价格战，也可以启动营销和促销活动，但这些措施充其量只能延迟不可避免的结局，即最终被竞争对手取代。
让我们将功能团队与一个赋权的产品团队进行对比。在这种情况下，产品团队不会收到写满功能和项目的列表，而是被告知一组需要解决的问题，以及期望达到的结果。产品团队会与公司利益相关方坐下来，从他们要求的特定功能反向思考，倒推出用户或公司面临的底层问题，然后讨论衡量成功的标准与期望的结果，这些都不难做到。
赋权的产品团队认为，与其简单地执行公司利益相关方期望的功能开发，不如肩负起为用户和公司找到解决方案的重任。这意味着产品团队要提出以下几个解决方案：
· 有用户价值的解决方案，即用户愿意购买或使用它。
· 产品易用的解决方案，即用户能够弄清楚如何使用它。
· 技术可行的解决方案，即工程师知道如何利用团队的时间和技术来解决问题。
· 业务可持续的解决方案，即该解决方案在营销、销售、财务、服务、法务和合规方面符合公司的业务规范。
为什么赋权的产品团队必然优于功能团队？除显而易见的理由，比如更强的主人翁精神带来的士气提升，以及直接为用户测试潜在解决方案获得的知识外，最主要的原因是，优秀的产品型公司理解赋予工程师自主权对创新至关重要，而赋权的产品团队正是为了利用好这种优质资产而建立的。
在功能团队模式下，工程师只是单纯地开发功能，设计师则负责让它外观漂亮。他们实际上就像雇佣兵一样。更糟糕的是，如果你用了外包工程师，他们就真的是名副其实的雇佣兵了。然而， 在一个赋权的产品团队中，工程师不仅仅负责开发产品，设计师也不仅仅负责设计。他们还肩负着帮助公司探索出正确解决方案的责任。这正是“赋权的产品团队”的含义。
工程师的优势在于，他们每天都在使用新兴技术，这使他们处于可以发现最新可能的最佳位置。当这些得到赋权的产品工程师与产品经理和产品设计师协作，并直接接触用户时，你就明白了那些受用户喜爱的创新产品或服务是如何诞生的。我们承认，这里特别强调了赋予工程师权力的重要性。这样做的原因是，在尚未转型的公司中，与其他角色相比，工程师的外包占比更高。这通常需要公司更好地理解工程师在产品开发中的角色。
当赋权的工程师与一位经验丰富的产品设计师（擅长设计有效且引人入胜的用户体验），以及一位能够理解用户和公司业务规范的、有能力的产品经理结合在一起时，你就拥有了解决难题所需的跨职能综合能力，开发出既令用户喜爱，又为公司创造效益的产品。
虽然产品上市时间对一个要为结果负责的赋权的产品团队而言很重要，但更重要的是产品创收时间。换句话说，就是实现业务成果的时间。如果一个赋权的产品团队发布了一个功能，但没有产生预期的成果，那么他们会对该功能或开发方法进行迭代，直到看到成果为止。
以产品创收时间作为产品团队的目标，会激励团队快速确定特定的想法或方法是否可行，这就是产品探索的核心。产品团队可以直接开发他们的各种想法，然后看看哪些能实现。但这很浪费时间，并且会在用户面前暴露很多糟糕的想法。相反，产品团队也可以通过一套完整的工具和方法来快速测试想法。
通常，产品团队会创建原型，原型有多种形式，但所有原型都有创建速度快且成本低的特点。每个原型被用来测试不同的风险或验证假设。 一般的经验法则是，产品探索中测试的任何想法都应该比工程师实际开发、测试和部署产品所花费的时间及成本至少低一个数量级。 在许多情况下，原型要比产品低两个数量级。
如果一个典型功能通常需要3～5次迭代才能达到预期的成果，并且如果每次迭代都需要功能团队来开发，每次迭代需要几个月的时间，那么你通常需要1～2年的时间才能使开发的功能产生预期回报。而且，这还是在公司利益相关方愿意继续将这些必要的迭代纳入其产品路线图的情况下。
相比之下，如果将需要解决的问题分配给赋权的产品团队，团队成员有执行产品探索的能力，那么这3～5次的迭代可以在几天或几周内完成，迭代后的产品版本也可以交付到用户手中，这样通常在几周后就能实现预期的成果。如果你曾经想搞清楚为何小型、赋权的产品团队能够比大型公司的功能团队更高效、持续地产出，那么这正是答案所在。我们在第10章中将讨论哪些技能可以帮你改变解决问题的方式。
改变解决问题的方式不仅仅能节省金钱和时间，更重要的是，它能为你创造一种持续为用户创造价值的机制。与其让功能团队服务于公司内部的利益相关方，不如改用赋权的产品团队，以能创造公司效益的方式为用户服务。这并不是无关紧要的改变，它可以从根本上改变公司的运作方式。
但请注意，有些关键的公司利益相关方可能因失去对技术资源的控制权而不满。他们可能会被动抵制，甚至有些人会积极抵制。这就是为什么如果没有公司最高层明确并实际的支持，转型往往会失败。同时，有的公司目前在任的一些产品经理、产品设计师和工程师可能不愿意承担，或者没有能力承担这份额外的责任。
事实上，承担解决用户问题的责任比被动开发产品功能的难度要高得多。你需要确保产品团队成员达到合格水平，并为他们提供必要的指导和业务的背景信息才能取得成功。详情请参阅第二部分。 由产品经理、产品设计师和工程师组成的实力强、跨职能、赋权的产品团队，以既令用户喜爱，又为公司创造效益的方式共同解决用户问题，这就是产品经营模式的第一性原理。 详情请参阅第8章。
如果你正在改变解决问题的方式，那么有一个重要的问题是：待解决的问题源自哪里？在传统模式中，待解决的问题通常来自公司利益相关方，因为他们在产品路线图中优先考虑自己的需求。而在采用产品经营模式的公司中，待解决的问题则来自基于洞察的产品战略。
但是，如果你想在提升产品战略方面的产品领导力之前，先专注于加强解决问题的能力，该怎么办？针对这种情况，有一种非常实用的转型方法，称为“成果路线图”。
如果你今天去找公司利益相关方，问他们有哪些要解决的问题，这可能会引起混乱，因为大多数产品路线图实际上都列满需要产出的功能清单。路线图上不是要解决的问题，而是要开发的功能。
幸运的是，通过逆向工程来解决这些问题并不困难。逆向工程的工作方式是，首先你从现有的以产出为导向的产品路线图入手，然后逐项检查路线图上的每个项目，确定希望每个功能解决什么问题，以及成功的衡量标准，即预期成果是什么。你还是会解决以前需要解决的问题，但现在你给产品团队探索潜在解决方案时提供了一定的自由度，从而使团队成员能够专注于成果。然后，你可以学习产品探索的技术来帮助你实现这些成果。成果路线图的另一个好处是，它可以帮助你的公司利益相关方不再只是关注功能和交付日期，转而讨论待解决的问题和期望达到的成果。