编辑导语:如何才能做好产品管理，在产品优化的不断迭代之旅中，保证产品设计不偏离产品愿景和产品战略？也许，你可以看看这篇文章。在这篇文章中，作者总结了在产品管理过程中可以借鉴的七条原则。让我们看一看。

产品管理是一门相对较新且发展迅速的学科。每周都会出现一些业界领袖关注的产品开发最佳实践的新文章。信息的泛滥可能会让人们搞不清应该遵循哪些实用的指导方针，以及如何在自己的工作和团队中寻找改进的机会。

此外，这种不断的变化意味着今天被认为是最佳实践的案例明天可能会过时。例如，今年早些时候，有报道称Spotify不再遵循“Spotify模式”，尽管它曾被誉为大型产品开发组织实施灵活和精益原则的典范。

那么，有没有可以简单应用的最佳实践呢？

然而，有一个解决这一困境的方法。与其追求对最佳实践不断变化的理解，不如揭示这些实践案例背后的原理。这些原则比实践本身更深刻，并且随着时间的推移更加稳定。然后，你可以为你自己、你的团队和更大的组织实践这些“最佳原则”，以适应特定的环境，而不是直接应用最佳实践案例。

在这篇文章中，我将分享产品管理和领导的七个原则以及它们的一些含义:

从问“为什么”开始理解问题持续聚焦授权团队拥抱不确定性平衡投入、产出、结果和学习迭代，迭代，迭代

关注原则而不是实践的好处在于，这些原则可以应用于组织的任何层面。无论你是产品经理、团队领导、CPO还是初创公司的CEO，你都将能够在自己的权限范围内找到运用这些原则的方法，改进你的工作和组织。

首先，从为什么开始，问“为什么”

第一个原则，“从为什么开始”；这也是西蒙·辛克的TED演讲(和一本同名的书)的标题。

从“为什么”思考，就是在讨论“做什么”和“怎么做”的细节之前，讨论要围绕“为什么”:我们工作的更深层次的目的是什么？我们想要实现什么？我们对未来的愿景是什么？

约翰·多尔(John Dole)指出了理想驱动者和利润驱动者的区别——理想驱动者是在自己的激情指引下实现更深层次的目标，而利润驱动者则试图抓住当前所有的机会。

但伟大的公司和好的产品往往是由理想的驱动者打造的。与利润驱动者相比，理想驱动者往往会表现出更大的内在动机(因为他们致力于一个对他们来说很重要的目标)，他们在面对困难时更有毅力，更注重细节。建立一个理想驱动的团队需要从问“为什么”开始。只有拥有共同的信念，别人才能成为公司和产品未来愿景的理想驱动者。

问“为什么”在各个层面都是可能的。显然，公司和产品负责人的主要职责之一就是为产品设定方向，包括作为产品战略和发展曲线基础的理想愿景。因此，对于一个理想驱动型组织的领导者来说，确保这一愿景得到广泛传播并被团队接受，作为他们存在的理由是至关重要的。

甚至这个原则在独立产品团队的应用也是如此。

你可能对自己做的每一件事都没有宏伟的愿景，但将产品团队的所有工作与产品愿景和公司使命联系起来仍然是必不可少的。此外，即使你是独立工作，你也可以讨论你为什么在一个团队中这样做:实现整体愿景不仅仅是一个小拼图，还包括这个功能将如何改善你的客户的生活(和/或为公司的成功做出贡献)。

总之，无论你是产品负责人，还是产品经理，甚至只是一个产品团队成员，你都可以遵循问为什么的原则，不断地在你的日常工作和你的宏伟理想之间建立联系。

二、理解问题理解问题

产品管理的第二个原则是真正深入地理解你正在解决的问题。

乍一看，这个原理听起来显而易见，甚至微不足道。你怎么解决你不懂的问题？

然而，在实践中，我们往往只追求与众不同的想法，而没有花时间去真正理解将要解决的问题。我们当前和潜在的客户中谁确实有这个问题，他们是否足够关心这个问题以支付解决方案的费用？

因此，遵循这个原则，第一个也是最需要的关键产品管理技能是同理心，这意味着能够设身处地地为他人着想，从他们的角度看问题。

如果你不了解你的客户是如何看待这个世界的，你就很难尝试为他们解决问题。

但是，你不能只站在客户的角度短视，否则你不可能比他们更好地解决这些问题。所以要真正理解问题，需要从不同的角度去看，这就需要产品团队思维的多样性。

理解问题也意味着在试图解决问题之前先定义问题。然而，这也意味着知道问题和解决方案通常是相互依赖的，尤其是在有技术支持的产品中。

比如，当新兴技术开启了可能改变我们对问题理解的新可能性时，我们也必须回过头来调整对问题的定义。这就是为什么“双钻石”设计流程往往存在数码产品的根本性缺陷——将产品设计或产品改进的过程划分为独立的阶段，分别发散总结问题和解决方案。

更好的比喻是“设计稿”，表现的是一种对混沌的寻找，然后随着时间的推移逐渐清晰。

当然，有时候你的工作几乎完全集中在产品问题上。毕竟你要的是创业，而不仅仅是解决人家的困难。比如盈利功能或者转换机制的改进，主要是为了商家的利益，而不是用户的利益(除非你想直接免费提供那些内容)。

但是，平衡很重要。为了让企业获得价值，你必须首先为客户创造价值，而这需要你解决他们的问题。所以，首先了解并解决客户的问题，然后专注于为你的企业提取价值。

第三，继续坚持不懈地专注专注

当你开始思考“为什么”，真正理解了你想解决的问题，就到了什么都不关注的时候了。持续的专注意味着做的比预期的少，但是尽最大努力。

持续关注意味着理解一个伟大的产品不仅仅是以一种可接受的方式做很多事情。一个伟大的产品意味着真正修复一些东西。这意味着把更少的事情做得更好。

持续聚焦的原则意味着80:20的方法可能会在产品开发中被误导。80:20方法意味着付出20%的努力可以获得80%的价值，然后只交付这80%的价值。

然而，事实是，这种差异通常是通过后20%实现的，因为他们需要更多的努力。如果剩下20%的价值很容易实现，那么大家都会去做。再往前一点，你的产品对看重剩下20%的客户更有吸引力，这是很难复制的。

所以，持续聚焦意味着你不能通过遵循框架或者计算ROI来区分产品的工作优先级。

首先，这些框架忽略了创新产品开发背后的根本不确定性。然而，更重要的是，这些框架永远不会告诉你需要专注于难以构建的差异化功能，也不会告诉你关注客户的愉悦，因为回报几乎不会立竿见影。

与遵循框架不同，您需要根据愿景、战略和对客户及其问题的深刻理解来设定优先级。

最后，这个原则需要明确:没有单一的优先化过程。相反，优先事项有许多层次，在每一个层次上，要削减的远多于要集中的。

制定产品愿景是重中之重，因为产品愿景之外的任何事情都不应该被关注。产品策略的选择，产品路线图主题，这个主题中的问题领域和解决思路是更深层次的重点，每一个层面都需要不断的聚焦。换句话说，这个原则也适用于从领导者到个人贡献者的所有级别。

四。授权给团队

产品管理的第四个原则是通过授权团队和所有参与产品开发的学科之间的跨职能协作(至少包括产品管理、设计和R&D之间的协作)来解决客户问题(以业务服务的形式)。委派团队不同于焦点小组或交付团队，因为他们被赋予解决问题的目标，而不是要交付的功能项目。

授权团队在工作动力、客户至上、反应速度、创新能力等方面有很多优势。

他们更有动力，因为他们有更高的自主感和使命感。他们更以客户为中心，因为他们可以在与客户的密切接触中学习最佳解决方案，而不是基于高级管理层的决定。他们的速度更快，因为反馈回路在团队内部，不需要在管理链上下波动。他们具有更高的创新能力，因为他们的跨职能性质，即用户、技术和业务的理解是结合在一起的。

对于这个原则，需要注意的是，真正的团队授权需要高层的支持(毕竟团队需要以问题的形式给出目标，而不是功能路线图)。

然而，即使作为一个单独的产品经理，你也可以尽你最大的努力委派给团队的其他成员。

很多初出茅庐的产品经理以为自己的工作就是知道所有的答案，拥有所有的想法，但其实没有什么比这更离谱的了。你可以利用团队的集体知识，通过更多元化的思考，确保整个团队从过程一开始就参与进来，从而产生更好的结果。这尤其意味着工程师应该参与发现阶段，甚至在解决方案想法形成之前。

当然，并不是每个团队成员都平等地参与整个过程。在发现阶段，设计和产品管理的工作量仍然较大，在交付阶段，工程师的工作量也较大。

然而，让工程师更早地参与这个过程可以帮助他们展示自己的观点(例如，强调技术带来的潜在的新颖方法)，将他们的工作与更大的目标联系起来，并确保每个人都同意所选择的方法。

一起入手，一起寻找解决方案，也会让大家把更多的精力放在选定的方案上，也就是说更加注重细节和做工，从而得到更好的产品。

动词 （verb的缩写）拥抱不确定性

给产品团队授权尤其重要，因为这符合第五条原则:拥抱不确定性。

产品开发从根本上说是一项有风险的工作。这种风险不仅仅在于你的想法能执行得有多好。远不止于此:无论你对产品创意最初的信心如何，大部分创意都无法实现你想要的虚拟价值(对客户和企业而言)。另外，除非你投入大量的精力去探索，否则你将无法识别那些糟糕的想法。这就是产品管理的不确定性公理。

如果你不接受这种根本性的不确定性，你将永远无法推出一款伟大的产品。

接受这种不确定性就意味着接受失败，承认理论上听起来很伟大的想法并不能保证任何实际价值的实现。这意味着你不得不一次又一次地放弃你所爱的东西。也意味着有时候你可能会有一系列的坏主意，一个接一个的失败。

这个可能很难接受。没有人喜欢一直失败。所以要明白这是产品开发的基本属性，没什么好羞愧的。相反，每一个未能实现其假设价值的想法都应该被理解为一个学习的机会。

因此，遵循这个原则意味着验证所有的想法。这意味着任何想法，即使来自高级利益相关者或客户，也不是神圣不可侵犯的——一切都需要证明其独特性。

这种验证需要尽早进行——交付后才能发现没有产生设想的价值，这意味着巨大的资源浪费。我们更愿意把一些已经发布的内容扼杀掉，而不是留在产品里(因为越来越复杂)，但如果能通过原型验证想法，并意识到不可行，那就更好了。

许多验证实践遵循拥抱不确定性的原则。在评估它们是否适用时，重要的是要明白，真正可以信任的唯一信号是人们“用脚和钱包投票”。

仅仅询问某人是否有问题或者想要更好的解决方案，很可能会得到肯定的回答。然而，这是言不由衷的。如果你真的想知道问题是否足够重要，或者你的解决方案对客户是否有效，你必须让他们投入时间和/或金钱——开始使用你的解决方案，或者更好的是，为它付费。

这可以是原型或最小可行产品(MVP)的形式，但没有行动的语言不应被理解为验证想法的有力证据。

不及物动词平衡投入、产出、结果和学习平衡投入、产出、结果和学习

在前一个原则之后，下一个重要的原则是平衡输入、输出、结果和学习。传统的软件开发过程管理往往以一种短视的方式关注产出:我们产生了多少新的功能？

但从产品发展的不确定性公理来看，并不能保证越来越多的功能会完全有利于客户(或企业)。因此，现代方法已经意识到关注结果(对于客户和企业)是很重要的。

然而，即使注重结果也有其挑战。相反，你还需要考虑输入(用于制定产品决策和决策过程的信息质量)和学习(如何将获得的结果反馈到产品开发过程中)。

与团队授权一样，只有在高级经理的支持下，你才能完全遵循这一原则。如果以产出来衡量团队，团队很难专注于其他方面。然而，确保结果、输入和学习不被完全忽略是即使是单个团队成员也可以注意的事情。

在确认你真的在解决你想解决的问题的时候，这种平衡的需求尤其重要。过于注重短期结果的组织可能会陷入“A/B测试陷阱”，即在A/B测试中，每一个产品变更都必须对照产品的当前版本进行测试。当然，A/B测试是科学衡量变革影响的好工具，但也可能仅仅为了优化而扼杀真正的创新。

在单个团队中实现这一原则的另一个重要方法是确保对学习的反馈环给予足够的重视。学习、从成就中提取发现并反馈到过程中的挑战在于，今天的工作只会在遥远的未来得到回报，甚至会让不同的人受益(当产品团队的当前成员已经离开的时候)。然而，为了产品的长期成功，重要的是收集经验教训，记录下来，并以某种形式分享出来。

七。迭代，迭代，迭代，迭代，迭代，迭代

产品管理的最后一个原则就是迭代，迭代，迭代。这个原则不仅包括通过Scrum或其他敏捷软件交付实践的软件交付迭代，还包括产品发现、交付和改进的整个过程的迭代。

从产品发现开始，误解了MVP。很多人认为MVP应该是你的新产品或新功能的第一个版本，范围越小越好，这样你仍然可以验证或证伪核心价值假说。

更好的理解MVP概念的方法是，它是一个验证目前风险最大的猜想或假设的工具。

这意味着两件事:第一，MVP不一定是产品。事实上，一般来说，一个原型或概念证明通常不会比一个完整的和可扩展的产品生产和验证更便宜。其次，一旦最有风险的假设被验证，另一个假设就成为下一个最有风险的假设。

这意味着你现在可以迭代创建另一个MVP来验证下一个假设，直到剩下的假设承担了足够的风险，你才有信心创建一个真正的产品。一个产品真正的第一个版本不再必须是有很多“捷径”的最有价值的产品——因为你降低了风险，你可以构建一个用户会乐于使用的产品，而不是蹩脚的半衰期体验。

换句话说:应该有一系列的MVP，然后是一个不是MVP的v1产品。

在许多迭代软件开发实践中，迭代交付几乎是一个给定的概念。我在上面已经提到了一个特别重要的方面:确保整个团队，包括工程师，不仅参与交付过程，还参与发现迭代。通过这种方式，您可以确保在发现和交付之间没有困难的“移交”过程，这将使迭代过程成为更加线性和平滑的过程。

最后，迭代的原理还包括产品发布后会发生什么。太多的团队试图尽快摆脱他们已经成功发布的功能:“这个工作得很好，参数也得到了改进。我们开始下一个待办事项吧！”

但是根据持续聚焦的原则，通常最好是多关注什么是有效的，把它从优秀提升到优秀。再说一次，伟大的产品是能够真正解决问题的产品。所以，当你发现一个功能可以给你的客户带来价值的时候，为什么不把它做得突出呢？

所有这些原则只是指导思想。根据环境、文化、流程和产品的不同，您可以在自己的组织中以多种方式实施这些原则。不管怎样，我希望这些原则能对研究你现在正在遵循的做法以及如何改进有所帮助。

本文翻译已获得作者官方授权(授权截图如下)

作者:延斯-法比安·戈兹曼；；译者:李；修订:徐曼璐、李、；编辑:李

原文链接:https://jefago . medium . com/seven-product-management-principles-55f 4909 c 9 a 2

本文由@TCC翻译情报局翻译发布。每个人都是产品经理。未经许可，禁止复制。

标题来自Pexels，基于CC0协议。