编辑导语：如何才能做好产品管理，并在持续的产品优化迭代之旅中，保证产品设计不脱离产品愿景和产品策略？也许，你可以看看这篇文章。本篇文章里，作者就总结了产品管理过程中可借鉴参考的七条原则，一起来看一下吧。
产品管理是一门相对较新，且在不断快速发展的学科。每周都会有一些行业领导者关注的产品开发最佳实践的新文章出现。纷杂泛滥的信息可能使人们迷茫于遵循哪些实践指南，以及如何在自己的工作和团队中寻找改进机会。
此外，这种不停息的更迭意味着今天被认为是最佳实践案例的东西明天可能就会过时。例如，今年早些时候，有消息称 Spotify 不再遵循着“Spotify 模式”了，即便它曾一度被誉为贯彻灵活和精益原则的大型产品开发组织的模范。
那么，在这些最佳实践中有可以被浅显应用的吗？
不过，这个困境有一个解决方案。与其追求对最佳实践的不断改变的理解，不如揭示这些实践案例背后的原则。这些原则比实践本身更深层次，而且在时光变迁中更稳定。然后，您可以以适应特定背景的方式为自己、团队及更大型组织实践这些“最佳原则”，而不是直接运用最佳实践案例。
在本文中，我将分享产品管理和领导力的七项原则以及它们的一些含义：
- 从问“为什么”开始
- 理解问题
- 持续聚焦
- 授权团队
- 拥抱不确定性
- 平衡投入、产出、结果和学习
- 迭代，迭代，迭代
着眼于原则而不是实践的美妙之处在于，这些原则可以沿用于组织的任意层级。无论您是团队中的产品经理、团队负责人、CPO 还是初创公司 CEO，您都将能够找到在自己职权范围内应用这些原则的方法，以及改进工作与组织的方式。
一、从问“为什么”开始 Start With Why第一条原则，“从问为什么开始”（“Start With Why”）；也是西蒙·辛克的 TED 演讲的题目（还有本同名书）。
从“为什么”开始思考，意味着在讨论“做什么”和“怎么做”的细节之前，讨论应该先围绕“为什么”展开：我们工作的更深层次目的是什么？我们想实现什么目标？我们对未来有什么愿景？
约翰·多尔指出了理想驱动者和利益驱动者之间的区别——理想驱动者受自身的激情指引去实现更深层级的目标，而受利益驱动者则力图抓住所有当前出现的机会。
但伟大的公司和好的产品往往是由理想驱动者建立的。与利益驱动者相比，理想驱动者往往表现出更大的内在动机（ 因为他们致力于一个对他们来说很重要的目标 ），面对困难时更有毅力，更注重细节。建立理想驱动的团队需要从问 “为什么”开始。只有拥有共同的信念，才能让他人成为为公司和产品未来愿景努力的理想驱动者。
从问“为什么”开始在各个层面都是可能的。显然，公司和产品领导者的主要职责之一是为产品设定方向，其中包括作为产品战略和发展曲线的基础的理想愿景。因此，对于一个理想驱动的组织的领导来说，确保这个愿景被广泛传播，并被团队作为他们存在的理由而接受是至关重要的。
甚至这个原则的运用，在独立的产品团队中也是如此。
你可能不会对你所做的每一件事都有一个宏伟的愿景，但将产品团队的所有工作与产品愿景和公司使命联系起来仍然是至关重要的。此外，即使是独立性工作，你也可以在团队中讨论你为什么正在做这个事：这不仅仅是实现整体愿景的一小块拼图，还包括这个功能将如何改善你客户的生活 （和/或有助于公司的成功）。
总之，无论你是一个产品领导者、产品经理，甚至仅仅是一个产品团队成员，你都可以遵循从问为什么开始的原则，在日常工作和宏伟理想之间不断建立联系。
二、理解问题 Understand the Problem第二个产品管理原则是真正、深刻地理解你正在解决的问题。
乍一看，这个原则听起来很明显，甚至微不足道。你怎么会去解决自己不懂的问题呢？
然而，在实践中，我们常常只追求有特色的点子，而没有花时间去真正理解这将解决的问题，我们当前和潜在的客户中有谁确实有这个问题，以及他们是否足够关心这个问题来为解决方案买单。
因此，遵循这一原则，首先且最需要关键的产品管理技能是同理心，这意味着能够设身处地为他人着想，从他们的角度看问题。
如果你不了解你的客户是如何看待这个世界的，你就很难试图为他们解决问题。
但是，你也不能目光短浅地只从客户的角度出发，否则你也不会比他们更好地解决这些问题。因此，真正理解问题需要从不同的角度来看待问题，这需要产品团队思维的多样性。
理解问题还意味着要在试图解决问题之前先定义问题。然而，这也意味着了解到问题和解决方案往往是相互依赖的，特别是在技术支持的产品中。
例如，当新兴技术开启了可能改变我们对问题理解的新可能性时，我们也必须回过头来调整问题的定义。这就是“双钻石”设计过程在数字产品中往往存在根本性缺陷的原因——将产品设计或产品改进的过程划分为独立的阶段，分别针对问题和解决方案进行发散和总结。
一个更好的比喻是“设计草稿”，它表现了一种对混乱的探寻，然后随着时间的推移而逐渐清晰。
当然，有时你所做的工作几乎完全集中在产品问题上。毕竟，你想要的是建立一个企业，而不仅仅只是解决人们的困难。例如，盈利功能或转换机制的改进主要是为了商业利益，而不是用户利益（除非你想直接免费提供那些内容）。
然而，平衡是很重要的。为了让业务获得价值，你必须首先为客户创造价值，而这需要你解决他们的问题。所以，首先要理解并解决客户的问题，然后专注于为你的业务提取价值。
三、持续聚焦 Focus Relentlessly当你开始思考“为什么”并真正理解你想要解决的问题时，是时候心无旁骛了。持续聚焦意味着做比设想中更少的事情，但是要做到极致。
持续聚焦意味着要明白，一个伟大的产品并不是仅仅以还可以的方式做了很多事情。一个伟大的产品意味着真正搞定一些事情。这意味着把更少的事情做得更好。
持续聚焦原则意味着 80:20 的方法可能在产品开发中被误导。80:20 方法意味着用 20% 的努力可以实现的 80% 的价值，然后只交付这80%的价值。
然而，事实是，这种差异化通常是通过最后的 20% 来实现的，因为它们需要更多的努力。如果剩下的 20% 的价值很容易达成，那么每个人都会这么做。通过多走一段路，你的产品对那些重视剩余 20% 价值的客户更具吸引力，而这是很难复制的。
因此持续聚焦意味着你不能通过遵循框架或计算 ROI 来对产品的工作进行优先排序。
首先，这些框架忽视了创新产品开发背后的根本的不确定性。不过，更重要的是，这些框架永远不会告诉你需要将重点放在难以构建的差异化特性上，也不会告诉你要关注顾客的愉悦感，因为回报几乎不会立竿见影。
与遵循框架不同，您需要基于愿景、战略和对客户及其问题的深刻理解来确定优先级。
最后，这个原则需要明确：不存在单一的优先级排序过程。相反，有很多层级的优先级，在每个层级上，需要删减的远远多于需要集中的。
制作产品愿景是最高优先级的，因为任何产品愿景之外的东西都是不应该被关注的。产品战略、产品路线图主题的选择、该主题中的问题领域和解决方案想法是更深层次的优先级别，每一个级别都需要持续聚焦。换言之，这个原则同样适用于从领导者到个人贡献者的各个层面。
四、授权团队 Empower the Team第四个产品管理原则是通过授权团队、产品开发中涉及的所有学科之间的跨功能协作（至少包含产品管理、设计和研发之间的协作），来解决客户问题（以业务服务的方式）。授权团队不同于专题小组或交付小组，因为他们被赋予了要解决问题的目标，而不是要交付的功能项目。
被授权的团队在工作动机、以客户为至上、响应速度和创新能力方面有很多优势。
他们更有动力，因为他们有更高的自主性和使命感。他们更以客户为中心，因为他们可以在与客户的密切接触中了解到最佳解决方案，而不是基于高级管理层的决策。他们有更快的速度，因为反馈循环在团队内部，不必在管理链上上下波动。它们具有更高的创新能力，因为跨职能的性质，即对用户、技术和业务的理解结合在一起。
对于这一原则，需要注意的是，真正的团队授权需要高级管理层的支持（毕竟，团队需要以问题的形式给出他们的目标，而不是以特性路线图的形式）。
然而，即使作为一个单独的产品经理，你也可以尽最大努力授权给团队的其他成员。
许多第一次做产品经理的人认为他们的工作就是知道所有的答案，拥有所有的想法，但事实上，没有什么比这更离谱了。你可以利用团队的集体知识，通过更加多样化的思维，确保整个团队从流程的一开始就参与进来，从而产生更好的结果。这尤其意味着工程师应该参与发现阶段，甚至在解决方案想法形成之前。
当然，并不是每个团队成员在整个过程中的参与程度都是相同的。在发现阶段，设计和产品管理的工作量仍然较大，在交付阶段，工程师的工作量也较大。
然而，让工程师更早地参与到这个过程中，可以帮助他们把自己的观点展现出来（例如，强调技术带来的潜在新颖方法），将他们的工作与更大的目标联系起来，并确保每个人都认同所选方法。
一起开始，一起发现解决方案，也会让每个人都对所选的解决方案投入更多的精力，这意味着更加注重细节和工艺，从而获得更好的产品。
五、拥抱不确定性 Embrace Uncertainty授权给产品团队尤其重要，因为它顺应了第五个原则：拥抱不确定性。
产品开发从根本上来说是一项有风险的工作。这种风险不仅仅在于你的想法能被执行得多好。它远不止于此：不管你最初对产品创意的信心如何，大多数创意都无法实现你所希望的虚拟价值（对客户、对企业）。此外，除非你投入了大量的精力去探索，否则你将无法识别那些坏主意。这就是产品管理的不确定性公理。
如果不接受这种根本的不确定性，你就永远不会推出一个伟大的产品。
接受这种不确定性意味着接受失败，承认理论上听起来很棒的想法无法保证任何实际价值的实现。这意味着你要一次又一次地放弃所爱。这也意味着你有时可能会有一连串的坏主意，会一个又一个地失败。
接受这一点可能很难。没有人喜欢一直失败。因此，重要的是要理解这是产品开发的基本属性，没有什么可羞愧的。相反，每一个没有实现假设价值的想法都应该被理解为一个学习的机会。
因此，遵循这个原则意味着验证所有想法。这表示任何想法，即使是来自高级利益相关者或客户的想法，都不是神圣不可侵犯的——一切事物都需要自证其与众不同的地方。
这种验证需要尽可能早地进行——交付后才发现它并没有产生设想的价值，这意味着巨大的资源浪费。比起将一些已经发行但却未能传达价值的内容留在产品中（因为不断增加的复杂性），我们更愿意将其扼杀掉，但是如果能够通过原型去验证想法 并意识到它并不可行的话便会更好。
有许多验证实践都遵循着拥抱不确定性的原则。当评估它们是否适用时，要理解真正可以信任的唯一信号是人们“用脚和钱包投票”很重要。
仅仅问某人是否有某个问题或想要更好的解决方案，很可能得到肯定的回答。然而言不由衷。如果你真的想知道问题是否足够重要，或者你的解决方案是否对客户有效，你必须让他们投入他们的时间和/或金钱——开始使用你的解决方案，或者更好，为之付费。
这可以是原型或最小可行产品（ MVP ）的形式，但没有行动的语言不应该被理解为验证想法的有力证据。
六、平衡投入、产出、结果和学习 Balance Inputs, Outputs, Outcomes, and Learning
继前一个原则之后，下一个重要的原则是平衡输入、输出、结果和学习。传统的软件开发过程管理常常目光短浅地集中在输出上：我们产出了多少新功能？
然而，从产品开发的不确定性公理来看，并不能保证推出越来越多的功能对客户（或企业）完全有利。因此，现代方法已经意识到关注结果（对于客户和业务）是重要的。
然而，即使只关注结果，也有它的挑战。相反，您还需要考虑输入（用于做出产品决策和决策过程的信息质量）以及学习（如何将已获得的结果反馈到产品开发过程中）。
与团队授权一样，你只能在高级管理人员的支持下完全遵循这一原则。如果团队是通过产出来衡量的，那么团队就很难关注其他方面。然而，确保结果、投入和学习不被完全忽视，这是甚至单个团队成员都可以关注的事情。
这种平衡的需求在确认你确实在解决想要解决的问题时尤为重要。过于关注短期结果的组织可能会陷入“A/B 测试陷阱”，即每个产品变更都要在 A/B 测试中针对产品的当前版本进行测试。当然，A/B 测试是科学地衡量变化影响的好工具，但它也可能扼杀真正的创新，只为了优化。
这一原则能够在单个团队中实现的另一个重要方法，便是确保足够重视学习的反馈循环。学习、从所取得的成果中提取发现，并将其反馈到过程中的挑战是：今天的工作只会在遥远的将来获得回报，甚至造福于不同的人（当产品团队的当前成员早已离开时）。然而，为了产品的长期成功，重要的是收集经验教训，记录并以某种形式共享。
七、迭代，迭代，迭代 Iterate, Iterate, Iterate
最后一个产品管理的原则是迭代、迭代、再迭代。这一原则不仅包括通过 Scrum 或其他敏捷软件交付实践交付软件的迭代，还包括产品发现、交付和改进产品的整个过程的迭代。
这始于产品发现和被误解的 MVP。许多人认为 MVP 应该是你发布的新产品或新功能的第一个版本，范围应该尽可能小，这样你仍然可以验证或推翻核心价值假设。
理解 MVP 概念的更好方法是：它是一个验证当前最具风险的猜想或假设的工具。
这意味着两件事：首先，MVP 不一定是产品。事实上，通常情况下，一个原型或概念验证通常不会比一个完整的、可扩展的产品生产和验证成本更低。其次，一旦风险最大的假设得到验证，另一个假设就成为了下一个风险最大的假设。
这意味着你现在可以迭代并创造出另一个 MVP 去验证下一个假设，直到剩下的假设承担足够小的风险，你才有信心创造出真正的产品。真正产品的第一个版本不必再是一个有很多“捷径”的最有价值产品——因为你已经降低了风险，你可以构建一个用户将乐于使用的产品，而不是一个蹩脚的半生不生的体验。
换句话说：应该有一系列 MVP，然后是一个不是 MVP 的 v1 产品。
在许多迭代软件开发实践中，迭代交付几乎是一个给定的概念。我在上面已经提到了一个特别重要的方面：确保包括工程师在内的整个团队不仅参与到交付过程中，还参与到发现迭代中。这样你就可以确保发现和交付之间没有困难的“移交”过程，这将使迭代过程成为一个更加线性的流畅过程。
最后，迭代的原则还包括产品发布后发生的事情。太多的团队试图尽快摆脱他们已经成功发布的功能：“这工作得很好，参数已经改进了。让我们开始下一个待办事项吧！”
不过，按照持续聚焦的原则，通常最好是加倍关注有效的东西，并将其从优秀提升到卓越。再说一次，一个伟大的产品是一个真正能搞定一些事情的产品。所以，当你发现一个功能可以为你的客户带来价值时，为什么不让它脱颖而出呢?
所有这些原则都只是指导思想。根据上下文、文化、流程和产品的不同，您可以通过多种方式在自身组织内实现这些原则。无论如何，我希望这些原则能够对研究您现在所遵循的实践以及如何改进它们有所帮助。
本文翻译已获得作者的正式授权（授权截图如下）
作者：Jens-Fabian Goetzmann；译者：李琳菲；审校：徐曼鹭、李泽慧、张聿彤；编辑：李莉好
原文链接：https://jefago.medium.com/seven-product-management-principles-55f4909cd9a2
本文由@TCC翻译情报局 翻译发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Pexels，基于CC0协议。
,
