产品管理所需要的技能很广泛，所以我试着把6个类别的要求归纳成排行靠前的3到4个类别：从很大程度上来说，这是一份很“有生命的”原则清单。当然，我不指望这份清单能够详尽无遗，它也没法反映出产品经理这个角色的整个职责范畴，而且这些原则还会随着时间的推移而不断演进。
领导团队
1.你的团队应该能够复述你们的愿景、目标和价值观。如果团队没法做到，那说明你跟他们的沟通还不够，团队还不够齐心。
2.你应该知道自己正在参与的是一场什么样的比赛，并且知道该如何不断得分。在这一点上，Adam Nash这篇文章（https://adamnash.blog/2011/12/16/be-a-great-product-leader/，https://adamnash.blog/2020/02/10/be-a-great-product-leader-amplify-2019/）框架非常有指导意义。
注：对于这一条，一位当了19年软件产品经理的网友在hacker news上是这么回复的：
令我吃惊的是，“客户”这个词在本文中出现的次数之少（仅在领导团队一节出现）。以我的经验，产品经理的头号工作是了解客户。尤其是以下这些事情：
——他们的痛点
——他们的工作流（产品如何适应其工作流）
——为什么他们热爱你的产品
——产品什么地方可以做得更好（为什么）
——买家、用户、拥护者是谁
——你的解决方案最（不）适合哪种类型的客户/痛点
如果不是组织内最了解客户的人，PM就很难做到优秀。
3.你的团队应该知道如何去达成目标。在执行上你不需要规定得过细，以至于达到矫枉过正的程度，但高层面的里程碑你和团队是必须了解的。如果你的里程碑是因为未知的事情而没法明确，那就得把这些未知因素明确摆出来。
决策
4.决策要记录下来，要做出解释并且要进行广泛的沟通。这会给人沟通过度的感觉。但如果你不觉得自己沟通过度的话，很可能就是沟通还不够。
5.无论你做出什么样的决定，以及确定了什么样的优先考虑事项，这些都需要证据。确保相关证据的存在是你的工作。你不可避免地要根据自己的判断而不是数据来做出一些决策。倾向于靠判断的决定也是可以的，前提是要进行明确的沟通。
6.决策应该尽早并且经常让利益相关者参与，大家意见的一致性必须明确。你要寻找的是“是的，我同意这一决定，或者是“不，我不同意，但我可以保证最终决定作出后会服从”。要干净利落地解决好意见不同意的问题。
有效沟通
7.没有所谓的沟通过度。“多余”的沟通=足够的沟通。
如果你觉得还没把自己讲烦，那很可能是讲得还不够。不断的沟通交流似乎显得有点“多余”，但事实并非如此。福音传道是这个角色的关键部分，确保组织保持一致并朝着同一方向前进是你的工作。
Marty Cagan 在《启示录：打造用户喜爱的产品》（INSPIRED: How to Create Tech Products Customers Love）中说得最好：布道，坚持不懈地布道。这里是在没有这样的事- 在解释和推销愿景这件事情上，没有过度沟通这一说。尤其是在大型组织里面，近乎不断的布道根本就是不可能逃脱的。你会发现，公司不同角落的人随便在什么时候都会对看到或者听到的某个东西感到紧张或恐惧。在他们把这种恐惧传染给他人之前，你得迅速让他们安心下来。
8.你，作为产品经理，对沟通应该有高得出奇的标准。大多数的功能都会有一个不是沟通的主要“输出”：设计师的是设计，工程师的是代码等等。对于你来说，沟通就是主要的“输出”，输出应该是例外。
9.你必须拥有叙述。当叙事出现真空时，大家就会“创造性地”自己去填补那个真空，而你可能不会喜欢。一旦失去了对叙事的控制，可能就会严重破坏团队的交付能力。
成为高效的运营者
10.牢固的关系可以促进强有力的协作。“拥有牢固的关系”听起来似乎很明显，但是“向上”、“向下”、“横向”管理好关系的重要性不可低估。如果没有牢固的关系和可靠的信誉，你就不会成功。
11.不要把时间和精力浪费在管理每一个项目的盘根细节当中；这个只宜留给不时之需。做好你自己的事情就行，要给你的团队干活的空间。要聚焦在：
设定目标上，也就是“我们参与的是什么样的比赛？” 要带领/帮助团队弄清楚如何到达目的地（确定里程碑、依赖关系、一致性等）。
领导好你的团队。比方说，确定沟通的节奏（更新、Slack频道、同步），开会的节奏，高级的项目里程碑，成功的指标等。
不要打扰。 预先建立好适当的沟通渠道，同时让你的团队随时了解最新信息。参见（12）条下面的“maker的时间表”。
12.优秀要靠他人的成就。产品经理要遵循“经理的时间表”。工程师和设计师遵循“maker的时间表”。帮助你的团队成为出色的“maker”，帮他们排除障碍；有效地应对不断变化的情况。
13.你的工作是排除歧义：作为产品经理，要不断思考如何为团队排除模糊：要让产品需求更加清晰，解决边缘情况，要回答问题等。
14.要自己掌握自己的命运。呃，我现在还不知道该怎么更好地阐述这一点，所以我会说要始终把命运把握住自己手上。了解你的业务，你的产品，你的团队，要及时响应，不断地沟通，做出好的决策，对自己的结果负责，每天进步一点点。
时间管理
15.你所担负的角色当中有80％都是用来寻找合适的产品，推动组织协调一致，剩下的20％则是明确解答团队的“maker”提出的问题。产品团队处在一个不断循环的发现和交付周期之中。在这个周期之中，下述活动是并行进行的：
在理想的世界里，工程师约80％的时间是用于交付，约20％用于发现；而产品经理正好反过来，80％用于发现，20%用于交付。
在大型的复杂组织里，这是一个很难实现的目标，但是要努力把80％的时间用在发现合适的产品（理念，验证，测试等）和沟通上（从而促进组织的一致性，提高清晰度）。
“组织协调一致”是个意义很广泛的用语，像1对1会议，高管战略评审，产品的“深入探究”，乃至于全员大会都算。
16.确保留出时间给策略和“重点”工作，那是你的责任。被1000封电子邮件和Slack消息困扰很自然，但这不能成为借口。确保专门腾出时间做你的重点工作。
会议要开得高效
17.事先让大家知道议程。在会议开始时，先收集意见，就目标保持一致。开会是很奢侈的行为；大家在开会的时候，一般就不是在做事。要控制要你主持的会议，并确保会议开得富有成效。
18.用“DAD”帮助来组织和召开会议。大多数会议其实就是三件事：讨论（Discussion），行动（Actions）以及决定（Decisions）。记录下一切决定，对讨论主题进行沟通，列举所有的行动事项。
19.“ABFU”，或叫随时跟进（我知道这很糟糕）。确保你（或其他人）在大概24小时之内把备忘录发给所有相关的利益攸关者。记录未必总是完美的，但要确保有记录，进行进行过沟通。
20. 要有强烈的好奇心，问“蠢”问题。提出合适的问题，哪怕问题看起来很愚蠢，因为问题是清晰性的催化剂。要开诚布公地提出问题，让其他人都听到答案。你可能不是唯一一个提出这个问题的人。
项目管理及其他
21.每个项目都是发现，设计和交付（以及迭代）的组合；你应该确保项目按此次序进行。虽说预期这些过程会有一些重合，但希望不要在交付过程中对设计进行大范围的更改。
22.要响应及时；否则的话，你可能会误事。作为一切其他职能的枢纽，而且往往是决策者，你必须成为团队的润滑剂。供参考：约2个小时留给Slack，约2天时间留给处理电子邮件。
CIO之家 www.ciozj.com 公众号:imciow