很难给出产品责任人的一个完整职责列表。这跟公司文化、个人和团队的能力、竞争对手等等上下文环境相关。这种上下文环境极大地影响着产品责任人在不同的公司如何开展起工作。因此我不会试图提供一份产品责任人的职责检查列表（“比如必须参加sprint计划会议”），而是认为更有价值的是，思考产品责任人给团队提供的两样东西：愿景和边界。
提供愿景
很多产品责任人的职责包括确定产品的愿景，做好沟通交流。最好的团队是那些因为产品责任人分享的引人注目的愿景而把热情激发了出来的团队。我们要卖东西给谁？我们产品的独特特性是什么？我们的竞争对手在干什么？我们的产品如何随着时间升级？当然对于交付给内部客户的应用程序和服务，这些问题是不同的，但拥有一个共同的愿景对激励团队，在开发人员和用户之间建成一个长期的联系通道是非常重要的。
愿景不仅仅只是清晰地存在于头脑里，产品责任人还必须把它给团队解释清楚。他可以通过创建、维护产品backlog并排好优先次序来做到这点。关于产品责任人是否是实际撰写产品backlog的人，这在ScrumMaster和团队间存在着很大的不同意见。我可以肯定地说，我不在意谁是具体写产品backlog的人，这对我而言无所谓；要紧的是，产品责任人是控制这一切的人。如果产品责任人把这代理给业务分析员，后者的延误导致没有写成产品backlog，那么这依然是产品责任人的责任。
除了保证产品backlog的存在，产品责任人还要通过回答团队成员下面的这些问题，不断给愿景添加细节：你希望用这种方式工作吗？当你说如此这般时是指什么？虽然产品责任人可以把回答问题的任务委托给别人，但他要负责他们能得到答案。产品责任人可以说：“如果你存在有关购物车和付款功能如何运行的问题，可以咨询Nirav，”但Nirav如果没有回答或提供帮助，作为一个好的产品责任人，你需要给出自己的答案，弄清楚为什么Nirav不能回答，并指定另外一个人，或找到其他解决办法。
提供边界
愿景和边界可以被当做项目中的竞争方面的因素考虑。愿景展示了产品会变成什么样；而边界则描述了愿景被实现时的现实情况。边界由产品责任人提供并经常表示为限制条件，如：
我六月份需要它
我们要减少一半的每单位开销
它的速度要加倍
跟现在版本比，它只要用一半的内存
我经常告诫公司，产品责任人可以决定一些事情——尤其是日期——然后我得到愤怒的回答：“不，”他们告诉我，“估算时间是团队的事。产品责任人所需要做的全部事情就是排好优先级。”尽管这些说法是对的，但产品责任人有责任定好边界，这决定了产品成功与否。
大部分经验丰富的Scrum团队成员都愿意同意，产品负责人完全有权力可以这么说：“我们起码需要开发产品blacklog中这些内容，否则这个产品本身就不值得发布。”但是，一旦他对最后期限说出类似的语句，许多具有类似经验的人却会反对这一点。
但是，让我们看看Takeuchi和Nonaka在对形成Scrum基础的六个团队的研究中说了什么，那是在1986年发表的第一篇关于Scrum的论文。
“富士-施乐的领导团队要求开发出一台截然不同的复印机，并给予FX-3500项目组两年的时间把它制造出来，该机器要求只用高端线一半的成本，但具备同样的功能。”（139）
显然团队接到了一个有挑战性的问题——要求具备当前公司最好的复印机的性能，但成本只有一半——并且给出了解决该问题的时间期限；该要求还算合理。当产品负责人过度地限制问题，或者是制订一个不可能的解决方案时，他们就做错了。假若富士-施乐管理层给团队只有一个月的时间去解决问题，团队会明白所有努力将是徒劳的，甚至都不会去试试。实际上管理层给该团队提出这个问题时，已假定有足够的操作空间，以便他们寻求找到一个解决方案。产品负责人所具有那些艺术性甚于科学性的工作的一部分，就是给项目提供一个足够的边界，激励团队在边界之前就能解决困难问题，而同时又不会设置过多的边界，以防止问题的解决变得不可能。
当为某个挑战性问题进行头脑风暴时，通常的建议是“跳出箱子外”思考。然而，有证据显示，只要箱子构造良好，那么在“箱子里面”思考更容易出现更好的解决方案（Coyne, Clifford, and Dye 2007）。他们还提到，当别人告诉我们要在箱子外面思考时，缺少约束反而令人不安。
在一个典型的头脑风暴促进会上，随意想象一个你想改善的产品。箱子外的可能性包括让产品更多或更小，更轻或更重，更漂亮或更粗糙（或者用100种方式改变外观）；还可以让产品贵一点或便宜一点，把它分成几部分或者和其他产品绑定；可以改变产品功能，使用年限，让它操作简便，提高和其他产品的契合度；抑或让它更容易接触，能让更多人可以承受，或者维修简便。但是你怎么知道哪个方向更能出成果呢？没有任何提示的情况下，人们无法知道他们是不是应该继续在一开始决定的方向前行还是改弦更张。最后结果可能是，他们无法处理未知的情况，只好偃旗息鼓。（2007，71）
产品负责人的工作是建造新箱子——边界——团队可以在里面思考。这个新箱子能防止团队迷失在无限的可能性中，给予他们比较和做出选择的基础。新箱子的边界由业务上最重要的约束所决定，可包含类似最小保证的功能、极快的性能、减少的资源消耗，当然还有日期。
每个团队只需要一个产品负责人
对于未接触过Scrum的团队来说，ScrumMaster的工作将很花时间。他会忙于培训团队成员的Scrum知识，鼓励大家以不同方式思考遇到的问题，消除团队前进的障碍等等。刚开始时，这甚至是份全职的工作，这取决于团队的磨合程度和面临的障碍。随着时间的推移，情况也在改进。最终ScrumMaster排除了很多重复发生的问题，团队也开始熟悉Scrum，并非常欢迎它的自组织特性。当这些变化发生后，团队花费ScrumMaster的时间会越来越少。如果我们用图形表示团队对ScrumMaster时间的需求，那么它看上去就像图7.1.
图7.1 团队对产品负责人和ScrumMaster的时间需求以不同的方向变化
对比团队对ScrumMaster和产品负责人的不同需要。当团队第一次接触Scrum时，他们并不在行；他们会纠缠于产品backlog要放入多少细节，一个sprint可以完成多少工作，在sprint中怎样合作等等；团队成员要学习如何一起工作的新实践与新方法；他们不会很快——至少和他们精通了Scrum后比起来，速度不会很快。当团队加速后（通过自己的进步和ScrumMaster对障碍的逐步清除），他们将能在每个sprint完成更多工作，这意味着他们有更多的问题需要问产品负责人。
因此，当团队的效率提升时，他们对产品负责人的时间需求也增加了。甚至当团队成员学到了领域的专门知识，也能独自承担更多的责任时，该情况也是适用的。
团队对产品负责人和ScrumMaster的时间需求的反向关系显示在图7.1中。图中的这条线说明，尽管一个有经验的ScrumMaster与两个或三个团队（取决于那时每个团队需要多少帮助）一起工作是可接受的，但是不建议两个以上的团队共享同一个产品负责人，而是建议每个团队最好是拥有一名全职的产品负责人。产品负责人的工作很有挑战性，其工作的一个部分是对外的：与客户联络，了解和顺应市场趋势；另一部分是对内的：与团队一起建造产品。当对内与对外的职责需要同时兼顾时，对外的、面向客户的职责总是具有更高优先级。每一个负责新开发和客户支持的开发人员都能证实跟客户相关的问题总是要优先处理。
正如一个产品负责人只为一个团队工作，每个团队也应该只有一个产品负责人。偶尔我也见过一个团队有两名产品负责人的情形，但这通常导致在这个不愿意做很困难命令的组织里有人说：“你们的产品负责人很一般”。找到人做出困难的命令，给团队指定一名产品负责人，鼓励他收集来自于那些也应能成为产品负责人的成员的有益的请求和反馈。
有两个产品负责人的团队极有可能要陷入 “妈妈说不；我们问爸爸去”的怪圈。当然只有功能紊乱的（或者绝望的）团队才会从一个产品负责人那里得到“错误”的答案，然后又去向另外一个问同样的问题。甚至他们最终会发现必须要靠自己来找到正确的答案。不过据我认为，有两个产品负责人的团队在他们选择向谁问问题前，都会考虑哪个产品负责人会给予最满意的答案。
产品负责人团队
某些情形下，一个人是无法承担产品负责人的全部职责。研究员Angela Martin、Robert Biddle和James Noble发现产品负责人这一角色“一直比项目中的开发者和其他参与人员承受着更多的压力”。（2004，51）Ron Jeffries是极限编程的发明人之一和Scrum认证培训师，他认同：“直到第一、二本书出版后，我们才完全意识到一个XP客户/Scrum产品负责人所承担的工作量。很显然，他们应该是一个小组。”
一个通用的解决方案是采用一个产品负责人小组。把产品负责人的角色的职责分散到一个产品负责人团队里，并在该团队中挑选出某个人，让他作为那个有最终责任和权力的人即可。即使是一个团队，开发小组也只需要找到一个确定不变的人询问问题。Ken Schwaber和Mike Beedle写道“产品负责人不是委员会，只是一个人”（2001，34）。要保证每个团队能确定一个为他们做决定的人。好的Scrum团队的开发速率很快，让委员会回答所有问题是无法与之匹配的。产品负责人不是总能立刻回答开发团队所有的问题，有时他告诉开发团队“我需要和同事商量一下”是可以的。不过，这种有根据的谨慎不能被委员会的决定所代替。
作者:Mike Cohn
