多个产品负责人可能会消除成功的机会

It was the end of the year, and I was excited to plan the roadmap for the next quarter. Unfortunately, I was unaware of the nightmare, which was just about to start.

到了年底，我很兴奋地计划下一个季度的路线图。 不幸的是，我没有意识到噩梦即将开始。

We were three Scrum Teams and three Product Owners. Until then, I used to believe that one Product Owner per team should work. But after four long hours of useless discussions, I concluded that multiple Product Owners for the same product cause massive inefficiency beyond increasing the odds of falling into a feature factory pitfall.

我们是三个Scrum团队和三个产品所有者。 在此之前，我以前一直认为每个团队应有一名产品负责人。 但是经过四个长时间的无用讨论，我得出的结论是，同一个产品的多个产品负责人会导致严重的低效率，这不仅增加了陷入功能工厂陷阱的可能性。

Despite having three Scrum Teams, we worked on the same product, and we even had a shared Product Backlog. Yet, somehow we couldn’t agree upon a single direction. Each Product Owner wanted to take a different road. Beyond that, we were component teams, which made the dynamic even more complicated, since we could not achieve our goals alone. We needed to collaborate and handle the dependencies.

尽管有三个Scrum团队，我们仍在开发同一产品，甚至还有一个共享的产品待办列表。 但是，无论如何，我们无法就一个方向达成共识。 每个产品负责人都想走不同的道路。 除此之外，我们是组成团队，这使动态情况变得更加复杂，因为我们无法单独实现目标。 我们需要合作并处理依赖关系。

The hard truth is that we planned the roadmap full of compromises, dependencies, and frustrations. Each Product Owner had a different opinion of what mattered the most. No need to say, but our quarter was a disaster.

硬道理是，我们计划的路线图充满了妥协，依赖性和挫败感。 每个产品负责人对最重要的事情都有不同的看法。 无需多说，但我们这一季度真是一场灾难。

I started wondering, once we scale Scrum. Should we also scale the role of the Product Owner? How many teams can a Product Owner lead efficiently?

一旦我们扩展了Scrum，我就开始怀疑。 我们是否应该扩大产品负责人的角色？ 产品负责人可以有效领导多少个团队？

减去相加 (Adding by subtracting)

Have you ever seen a bus with multiple drivers? One bus, one driver.

您是否看过有多个司机的公交车？ 一辆巴士，一位司机。

Even when a bus driver is being trained, there only is a single person at the wheel. For a single bus, there is always only one driver.

即使当培训公共汽车驾驶员时，方向盘上也只有一个人。 对于单个总线，始终只有一个驱动程序。

In 2016, I worked at a Startup. I was the Product Owner. There was one Scrum Team of seven Developers. As we grew, we went from 7 to 21 developers. We formed three Scrum Teams. However, I was the only Product Owner. I felt like we were moving fast, discovering, learning. It was such an incredible experience. Decisions were made quickly because there was a single Product Owner.

2016年，我在一家初创公司工作。 我是产品负责人。 有一个由七个开发人员组成的Scrum团队。 随着我们的成长，我们从7位开发人员发展到21位开发人员。 我们成立了三个Scrum团队。 但是，我是唯一的产品负责人。 我觉得我们正在快速前进，发现，学习。 真是令人难以置信的经历。 由于只有一个产品负责人，因此可以快速做出决定。

We were structured as feature teams, not that I was aware of that in 2016. But that is how we worked. As the Product Owner, I would define the goals to achieve, and we worked from end-to-end with each team. The outcome was fantastic. When I look back, I connect the success of this team to having feature teams working with just a single Product Owner.

我们是由功能团队组成的，并不是我在2016年意识到的。但这就是我们的工作方式。 作为产品负责人，我将定义要实现的目标，并且我们与每个团队进行了端到端的合作。 结果非常棒。 当我回头看时，我将这个团队的成功与功能团队仅与一个产品负责人联系在一起。

I learned from my experience that we can add productivity by reducing the number of Product Owners. Product Owners can be responsible for multiple teams; up to three worked well in my case. Allow me to explain to you more about my opinion.

我从经验中学到，我们可以通过减少产品负责人的数量来提高生产力。 产品负责人可以负责多个团队； 在我的情况下，最多三个可以正常工作。 请允许我向您解释我的观点。

In the example I mentioned at the beginning of the text, we were also three Scrum Teams. However, each Development Team was responsible for a set of components. Also, each team had its Product Owner. The product was the same, and the three Scrum Teams worked on the same product. What surprised me the most is the number of problems we always faced:

在本文开头提到的示例中，我们也是三个Scrum团队。 但是，每个开发团队都负责一组组件。 此外，每个团队都有其产品负责人。 产品是相同的，并且三个Scrum团队使用相同的产品。 最让我惊讶的是我们一直面临的问题数量：

• Lack of accountability: no one was accountable for any experience from end-to-end

  缺乏问责制 ：没有人对端到端的任何经验负责

• Priorities defined on the component level: priorities were set per team, instead of Product level

  在组件级别定义优先级 ：每个团队设置优先级，而不是产品级别

• High level of dependencies: slowness on delivering results due to massive dependencies among the teams

  高级别的依赖关系 ：由于团队之间的巨大依赖关系，导致结果交付缓慢

• Slow decisions: Product Owners had endless discussions until they could make a decision, which generally seemed to be a compromise, instead of fostering collaboration

  缓慢的决策 ：产品负责人经过无休止的讨论，直到他们可以做出决定为止(通常似乎是妥协)，而不是促进协作

• Ping-Pong blame game: Product Owners shift problems to the other teams

  乒乓怪游戏 ：产品负责人将问题转移到其他团队

When I compare both scenarios, I believe that multiple Product Owners limit the odds of succeeding. Considering a single product, I have experienced more success once the Product Owner is fully accountable for the product, from end-to-end. If it’s not realistic to have a single Product Owner, at least each Product Owner should be responsible for the end-to-end experience to foster accountability and reduce dependencies.

当我比较这两种情况时，我相信多个产品负责人会限制成功的几率。 考虑到单个产品，一旦产品负责人从头到尾全面负责该产品，我将获得更多的成功。 如果只有一个产品负责人是不现实的，则至少每个产品负责人都应对端到端的经验负责，以增强责任感并减少依赖性。

The Scrum Guide says the following:

《 Scrum指南》指出：

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

产品负责人是一个人，而不是委员会 。 产品负责人可能代表了产品待办事项列表中委员会的要求，但是那些想要更改产品待办事项条目优先级的人必须解决产品负责人。

— The Scrum Guide, November 2017

— Scrum指南 ，2017年11月

多个产品负责人导致不良结果 (Multiple Product Owners lead to poor results)

Being a Product Owner is a challenging role. We have to make decisions every day. We need to understand our customers, prioritize, run discoveries. It represents tons of work. However, it’s fun to do that, and Product Owners get energized by doing so. Every day brings new learnings as well as perspectives. But the fun may end once the team needs to scale.

成为产品负责人是一个具有挑战性的角色。 我们必须每天做出决定。 我们需要了解我们的客户，确定优先级，进行发现。 它代表着大量的工作。 但是，这样做很有趣，并且产品所有者因此而充满活力。 每一天都带来新的学习和观点。 但是一旦团队需要扩展，乐趣可能就结束了。

Scaling Scrum can lead to multiple scenarios. Therefore, we should be careful once we need to scale — one of the vital aspects to succeed while scaling is to keep the teams as autonomous as possible. However, a common decision is to fully scale the teams, having a Product Owner per Scrum Team, that’s the moment when the fun is over.

扩展Scrum可能导致多种情况。 因此，一旦需要扩展，我们就应该谨慎-成功扩展的重要方面之一就是保持团队尽可能的自治。 但是，一个共同的决定是要充分扩展团队，每个Scrum团队都有一个产品负责人，这就是乐趣结束的时刻。

A standard scenario is to separate the teams into components. Thus each team will be responsible for one part of the product. In this case, we will face:

一个标准的方案是将团队分成多个组成部分。 因此，每个团队将负责产品的一部分。 在这种情况下，我们将面对：

• Dependencies: a goal cannot be achieved without involving more teams. Therefore, creating dependencies which will slow down the whole process

  依赖关系 ：没有更多团队参与就不可能实现目标。 因此，创建依赖关系会减慢整个过程

• Conflict of decisions: Product Owners will focus on the component the team works on, instead of having a more significant goal

  决策冲突 ：产品负责人将专注于团队工作的组成部分，而不是拥有更重要的目标

• Feature factory: the vision will eventually be forgotten, which will lead to an excessive focus on the components. Thus causing the feature creep effect

  功能工厂 ：最终将遗忘愿景，这将导致对组件的过度关注。 从而引起特征蠕变效应

As Product Owners, we don’t want to fall into this amount of inefficiencies. We wish instead to progress as fast as possible. That’s why we should refrain from having one Product Owner per team. An excellent Product Owner can handle multiple teams, at the end of the day, despite being tired, the Product Owner will be fulfilled. The role of a Product Owner is demanding; you should know that before you jump into it.

作为产品负责人，我们不想陷入这种低效率的境地。 相反，我们希望尽快取得进展。 这就是为什么我们应该避免每个团队只有一位产品负责人。 一个优秀的产品负责人可以在一天结束时处理多个团队，尽管很累，但产品负责人将得到满足。 产品负责人的角色要求很高； 在跳入之前，您应该知道这一点。

Imagine you are working as a Product Owner for a SaaS company for many years. After a period of hyper-growth, you now are a Product Owner for around 5 Scrum Teams. You’re doing Scrum by the book: one Product, one Product Backlog, and one Product Owner. You love your job, even though it is quite stressful, and you work way too many hours. But hey, you know what you sign up for when you begin working at a start-up.

想象一下，您担任SaaS公司的产品负责人已有很多年了。 经过一段时间的快速增长，您现在是大约5个Scrum团队的产品负责人。 您正在按照书来做Scrum：一种产品，一种产品待办事项列表和一个产品所有者。 即使工作压力很大，您也喜欢工作，而且工作时间太多。 但是，嘿，您知道在初创公司开始工作时会注册什么。

— Maarten Dalmijn, Product Owners lose their job when SAFe is introduced

— 引入SAFe后 ， 产品负责人 Maarten Dalmijn 失业

尾注 (Endnote)

I have learned that scaling the Product Owner role does not go together with scaling the development teams. More Product Owners do not mean more autonomous teams. On the contrary, it means more inefficiency, and probably a misleading direction due to conflicting decisions.

我了解到，扩展产品负责人角色并不能与扩展开发团队一起工作。 更多的产品负责人并不意味着更多的自治团队。 相反，这意味着效率低下，并且可能由于决策冲突而产生误导。

I want to emphasize that being the only Product Owner of three Scrum Teams was challenging, time-consuming, and sometimes even stressful. However, it’s the moment I could benefit the most from Scrum. It’s one of the best experiences I’ve ever had.

我想强调的是，作为三个Scrum团队的唯一产品负责人是具有挑战性，耗时的，有时甚至是压力很大的。 但是，这是我可以从Scrum中获得最大收益的时刻。 这是我经历过的最好的经历之一。

Great Product Owners are looking for significant challenges. Great Product Owners do not want to become responsible for a small part of the product. It’s more gratifying to have massive challenges than getting frustrated by bureaucracy and falling into the feature factory pitfall.

伟大的产品负责人正在寻找重大挑战。 伟大的产品负责人不想对产品的一小部分负责。 与面临官僚主义的挫败感和陷入功能工厂陷阱相比，拥有巨大的挑战更令人满足。