1. 管理产品，而不是团队

　　作为产品经理或产品所有者，要专注于你的工作，要管理产品而不是团队。对产品提供指导，包括它的市场，价值主张，业务目标和主要功能。要明确分工，让 ScrumMaster 或指导人员来制定流程和组织问题；让开发团队来指出需要怎么做才能实现用户故事和其他产品积压事项。

　　这里有一个常见的错误，那就是介入并扮演 ScrumMaster 的角色，在没有 ScrumMaster 或者如果个人正在努力做好工作的时候。虽然这可能会在短期内会有一定的成效，但从长远来看，肯定是弊大于利的。承担太多的责任意味着会过于分散自己的精力：不知不觉就会让某些东西悄然溜走。要么你会忽略一些产品责任，要么将你的健康置之脑后。两者皆非你所愿。

　　2. 将团队当作平等的伙伴

　　还记住 Golden Rule 吗？你想如何被别人对待，就应该以同样的方式对待他人。团队成员不是你的资源，但却是创造你的产品的人。如果你与团队的关系很差，那么你的产品很可能会受到影响。尊重团队成员的 UX / UI 和技术决策，以及他们决定如何完成工作的权利。要诚实和开放。提供建设性的反馈意见并说出你的担忧。但是，不要吩咐别人怎么做他们自己的工作，也要克制分配任务的欲望。开发团队需要能够管理他们自己的工作（使用 Sprint backlog 或看板）。如果团队有斗争，那么帮助团队是 ScrumMaster 的工作——而不是你的（正如上面所讨论的那样）。

　　3. 帮助团队看到更大的蓝图

　　开发一个成功的数码产品需要的不仅仅是技术知识。在不了解产品上下文的情况下，包括客户和用户是谁，产品为他们创建什么样的价值，什么使得产品与众不同，以及它将如何有利于企业等，制定正确的解决方案几乎是不可能。因此，你应该帮助团队获得相关的市场和领域知识——例如，让团队参与研究和验证工作，邀请他们和你一起访问客户——确保他们知道产品战略和产品发展蓝图，以及企业目标和 KPI。这不仅会带来更好的技术决策和更优的产品。还可以简化了你的工作量：了解更大的蓝图可以让你的团队来帮助创建用户故事，并支持你管理产品积压。

　　4. 让团队参与到产品决策

　　当你拥有和管理产品的时候，开发团队应该理解和支持重要的产品决策。实现双赢的最好办法是让团队成员参与到决策过程。这也充分利用他们的创造力和知识，并将可能导致更优的决策。有一些技术可以帮助你实现双赢，例如：

　　要清楚的是，合作需要领导。作为产品的负责人，你应该是开放和协作的，但同时又果决。目标是让开发团队建立共识，但不回避艰难的交互。不要满足于最小的共同点，能够在意见不能一致的时候勇于做出决定：伟大的产品不会因为是少数而服从多数。

　　5. 在团队上花足够的时间，但不要忽视你的其他职责

　　花时间和团队一起合作以工作于用户故事，回答问题，以及参加会议。如果你不具备或难以达到这样的条件，那么你并非是在指导团队。在最坏的情况下，人们会厌倦等着你来给答案，因此不再咨询你。因此，你最终可能会得到一个需要额外返工或者功能发布不了的产品。

　　但是，如果你对团队的问题不堪重负，那么要指导团队帮助大家看到更大的蓝图，并让团队参与到产品积压管理和用户故事创建中。这将使他们能够自主开展工作，并且减少你不得不回答的问题量，在你的团队实现用户故事的全速冲刺中。

　　虽然在团队上留足足够的时间是如此重要，但也不要忽视其他产品管理的工作，例如与用户接洽，工作与产品战略和路线图，以及管理利益相关者。如果你过于以团队为重点，那么你的产品很可能会受到影响。

　　6. 期待高标准，但不要逼迫大家

　　对团队负责，期待大家做好工作——即保持承诺和尊重达成的协议，交付冲刺目标，团队遵守完成定义以及创建可工作，文档化和测试过了的软件。但是要认识到，软件开发是具有挑战性的，而且是人就会犯错误。如果有一次冲刺目标错过了，也不要对团队发火。但是如果团队屡次不能发布承诺过的事情，那就需要介入了。调查原因，并探讨如何帮助，例如，可以创建较小的用户故事或更优的验收标准。

　　不要强迫开发团队工作，不要要求完成比他们实际能应付的更多的任务。否则，团队会变得失去动力，并开始走像牺牲质量和忽略文档这样的捷径。在最坏的情况下，大家会生病或跳槽。相反，让团队参与设置一个有意义的冲刺目标，不但能够为团队提供动力和指导，还可以尊重团队决定工作如何完成的权利。这将建立一种可持续的速度，并让你的团队保持动力。

　　7. 给团队空间来试验和学习

　　为了创造价值，产品需要提供一些新的东西；它需要创新。为了帮助你的产品在将来创造价值，团队需要时间来学习他们的技能，研究新的技术和工具。但是，如果你一直要求大家工作于新的功能，那么这些就都不可能。因此，你应该给予团队足够的空间来试验新的点子，掌握新的知识。有些团队使用 gold cards 来分配时间以便于冲刺试验和学习；有些人使用 hack days。无论哪种方式对你的团队有用，这都将有利于你的产品和团队士气。

　　8. 全面参与会议（或不露面）

　　这似乎是一个微不足道的忠告，但是从客观上来说，我看到有不少人敷衍了事地参加开发团队的会议。参加会议前要做好准备，全面参与——电话静音，收起你的笔记本电脑和平板电脑——或者干脆不要参加。

　　在 Scrum 的背景下，产品经理和产品负责人的两个最重要的会议，通常是冲刺规划和冲刺审查。你应该总是致力于出席这些会议，并做好必要的准备工作，比如，优先产品积压和提炼用户故事以用于冲刺计划或邀请合适的人，并选择合适的产品验证技术用于审查会议。但不要促进这些会话。让 ScrumMaster 来担当这个角色。