作者：Antoine Sakho | 翻译：Kc chen | 校对：Morisen
原文链接：https://medium.com/@antoinesakho/why-web3-needs-product-management-6afabf903df0
DAO需要有凝聚力的产品战略和完美的交付，才能茁壮成长并与Web 2.0的巨头们（头部公司）竞争--这篇文章是讨论他们如何能做到这一点（并在过程中将产品管理去中心化）。
随着 DAO（去中心化的自治组织）的兴起，去中心化的活动和组织是当今的热门话题。像 Sushiswap 或 BanklessDAO 这样的社区已经围绕着这个想法聚集起来--并成功地将这些想法变成了成熟的产品，而不影响其透明和分布式的社区性质。但是，去中心化似乎在有明确定义的目标，以及小团队和做出贡献的人的有自主权方面的项目中效果最好。例如，想象一下，一个社区 / DAO 想要提升一篇博客的影响力：每个成员都可以使用自己的社交网络来推送这篇文章，提升人们对它的认识。但是当你有更复杂的目标时，会发生什么？或者，当你的问题多于答案时？我们如何能以一种有组织的、高效的、有吸引力的方式将解决复杂问题的过程去中心化？
为什么要集中管理？
在过去的十年里，产品管理有了很大的发展，公司从功能工厂 (feature factory) 的方式转向小型、自主、结果驱动的团队--也就是小队 (squads) 或产品团队（正如Marty Cagan广泛宣扬的）。
这些产品团队已经取代了传统的、功能性的筒仓 (silos)，即独立的工程、设计和战略团队，成为软件初创企业和巨头的标准结构，一个关键原因是速度。因为这些团队被授权（他们把控他们所负责的领域）和自给自足（他们拥有完成产品所需的所有技能），他们可以更快地做出决定，并赢得他们所要争取的市场。
但要有效地做到这一点，关键是要有人（1）在深入了解客户的基础上定义一个有凝聚力的产品愿景，（2）使团队成员与这一愿景保持一致，以及（3）帮助协调他们的活动，以完成一个成功的产品。进入产品管理，其存在的理由是：
引导[团队]从找出核心问题到产品发布，确保网络中的每个节点都了解其他节点的进展情况，并确保用户越来越需要正在开发的产品。[...]在一个速度为王的世界里，世界正在发生指数级的变化，在行动前有时间形成共识往往是一种奢侈。为了保持速度，团队需要每天做出关键的决定，而这些决定在利益相关者之间有重大的交易和/或利益冲突。推动这些决定是产品经理的工作，没有其他人可以做。[...] 最后，组织规模带来了多个团队。一个有效的产品开发系统可以协调和集中这些团队，以实现公司的愿景。[...] 产品经理通过确保没有重复的工作和分享基础设施来支持公司的效率，使其他团队能够更快地发展。
—— 节选自 Brandon Chu 的《产品管理的黑匣子》
因此，看待产品管理的一种方式是将其作为集中信息和决策的核心，在一个以指数速度发展的世界中实现速度和规模。而产品管理以及它所释放的所有效率，对于扩大我们每天都在使用的 Web 2.0 产品的规模起到了重要作用。
去中心化的产品管理（dPM）的挑战
也许是因为 web3 非常重视去中心化，产品管理作为一种功能在大多数 DAO 中似乎都不存在。我们认为，这造成了统一和协调方面的巨大问题。决策瘫痪、委员会设计、无休止地寻求共识......我们已经在 DAO 内的团队构建产品的方式中看到了许多低效率的现象。去潜伏在几个 DAO 的 Discord 服务器中，你会亲眼所见以上的情况。这些问题会直接反映在糟糕的用户体验上，这种体验困扰着今天的许多 web3 产品，严重限制了用户的使用意愿。
每当 DAO 将开始有几个团队在同一个产品上工作时——通常是产品规模扩大时的情况--这些问题就会被放大。考虑一下这些场景：
- 一个 DAO 中的两个团队同时决定致力于提高产品的注册率。第一个团队决定将注册按钮移到登陆页面的中心位置，并设置一个大的 CTA，全部放在折叠上方。第二个小组认为社交证明是问题所在，并希望将折页上方的部分改为一个大的快乐客户引言的旋转木马。当然，这两种变化不可能同时发生，如果没有实体来促进举措的协调和资源的分配，大量的时间将被浪费，这可能导致失去重要的上市时间，或者更糟糕的是，没有实际的改进。
- 团队想要改进一个特定的产品，他们创建提案供整个社区投票（这不是调查社区和讨论潜在的想法，而是实际要求成员决定哪一个应该被实施）。大多数投票者可能没有产品开发方面的专业知识，这可能导致投票给一个实际上可能损害产品的想法，或者甚至可能一开始就不可行。想象一下，对整个国家进行调查，在两种疾病的实验性疫苗中做出选择。这些投票中，有多少人会有任何科学背景来选择最佳方案？这就是为什么运作良好的民主国家依靠专家来做出（或至少建议）技术决定。如果 DAO 有一个技术委员会来批准代码修改，为什么不对产品开发采取同样的方法？
或者，也可以考虑以下的方式。
- 团队决定独立构建功能，并在没有协调的情况下，最终创造了一个产品的科学怪人（即混乱和复杂）。这样的产品由于缺乏重点而难以获得大量的采用和规模。这篇文章展示了例如Sushiswap是如何在没有协调和指导的情况下发展的，损害了其获得市场份额的能力，甚至使其面临被破坏的风险。"当然，Uniswap可能没有Sushi的范围广，但它有一个可以说更重要的东西：方向。有一种讽刺意味的是，一个名为寿司(Sushi)的项目在精神上感觉更接近于海鲜饭(paella)。[......]如果Sushi想赢得怀疑者，并成为不仅仅是加密货币最引人注目的案例研究，它将需要制定一个更清晰的前进道路"。
这样的场景体现了缺乏协调会导致破坏性的拉锯战，不会为组织增加价值。那么，我们如何才能使 dPM（去中心化的产品管理）成为现实，避免浪费宝贵的时间和资源呢？
迈向 Sub-DAO 和产品委员会
传统公司最常见的模式是按层级组织。战略决策通常是由组织结构图的最高层做出的，然后再下放到执行这些决策的团队。这种方法最初似乎是唯一能让大公司真正工作并向共同目标迈进的方法--但代价是让员工感到大多没有权力和不快乐，正如过去20年中工作满意度的下降和目前的 "大辞职 "似乎表明的那样。
但是，如果我们能够只将两个世界最好的部分带入 DAO 呢？一方面是传统组织中常见的战略方向和快速执行，另一方面是去中心化网络的所有权和授权？我们可以看看子 DAO (Sub-DAO)。
子 DAO 是我们在许多 DAO 中看到的一种模式。他们可能被称为不同的名字（例如，他们在 BanklessDAO 内以公会的名义出现），但子 DAO 不过是为 DAO 做出贡献的个人的一个子集，具有强大的领域专业知识（即设计、金融、工程），一套狭窄的责任、目标和（可选）预算。Aragon Network DAO 是这种方法的一个例子，到目前为止，已经创建了三个子 DAO，运用选举更快地做出合规、执行和技术决策。
这些子 DAO 可以随时改变、解散，或由母 DAO 否决其决定，既能对日常议题进行快速决策，又能对高层议题进行完全分散的决策。当然，选举也是在社区参与和投票下进行的。
产品团队是 Web 2.0 企业的皇冠上的明珠（为 Facebook、亚马逊、谷歌等公司产生高影响力和价值），但有趣的是，我们在 web3 领域没有看到很多产品子 DAO。利用具有特定职责的子 DAO 的设计和选举产生的委员会，我们建议创建 "产品委员会 "子 DAO，将我们在 Web2.0 中看到的影响力和价值创造带到去中心化的世界中。
Teresa Torres（著名的产品人，《持续发现习惯》的作者）最近写了一篇文章，她概述了产品领导应该如何用结果来领导他们的产品团队。类似（不能说完全相同）的方法是我们所设想的。
领导层和产品团队的不同活动从 Teresa Torres 分叉出来，并适应于产品委员会的情况
接下来的章节将以 Aragon Network DAO 为例，但也可以适应任何类似的 DAO，考虑到它们的独特情况。
职责
产品委员会负责：
- 定期检查 Aragon Network 的战略和目标。
- 将目标转化为需要解决的问题（或机会），例如，Aragon Network 有一个在特定时期增加活跃 DAO 的目标。产品委员会将其转化为两个问题--例如，"创建 DAO 太复杂了"（一个获取问题）和 "没有足够的 DAO 成员参与治理"（一个激活/保留的问题）
- 定义一个周期（即一个学期）所需的预算，并将其提交批准。
- 为 Aragon 产品中需要解决的具体问题创建赏金/补助金（在批准的预算范围内）。
- 审查/评估提交的悬赏/赠款，并选择获胜者。
- 为特定项目雇用社区成员或团队（在批准的预算范围内），例如，产品委员会想进行竞争对手分析，但没有人力去做。它可以为这个特定项目雇用某人。
- 为社区成员提供产品指标的公共（或门控）仪表盘。
- 提供当前和未来潜在举措的路线图。
- 发展设计系统并确保其在 Aragon 产品中的正确应用。
尽管产品委员会负责上述所有工作，但这并不意味着它应该在没有咨询社区的情况下做出决定。子 DAO 的设计并不意味着摆脱了社区的参与，它只是使对话更加集中，决策更加迅速。
产品委员会应该不断地就其决定（问题和机会的定义、优先级等）对感兴趣的社区成员进行调查，并以明确和透明的方式进行沟通。
在一定条件下，在明确定义的规则下，社区应该能够罢免委员会成员，如果他们的行为不符合组织的最佳利益。
角色
一个产品委员会的最低配置应该是：
- 产品负责人——确保产品为客户以及 Aragon 提供价值。产品负责人负责跟踪指标，找到用户体验中潜在的差距，以达到组织的目标。
- 产品设计负责人——确保产品有很好的可用性，用户可以很容易地得到他们来时的价值。产品设计负责人还负责确保设计系统的发展，跟上最新的 UI/UX 趋势。
- 技术负责人——确保产品运行时尽可能没有错误，并确定需要做的潜在改进/修复。技术带头人还负责确保委员会创建的拨款从技术角度来看是可行的。
这个三人组应该不断保持一致，就像一个普通的产品团队一样。
当然，额外的角色/职位可能是必要的，特别是取决于组织的规模和/或产品的数量。
流程
下面的图片显示了主要的流程，它允许产品委员会确保在分散的情况下保持一个有凝聚力的产品策略和令人满意的交付。值得一提的是，其他子流程或变化可以（也会）存在，这取决于每个案例。
1/ 分配责任
主 DAO 分配现在由产品委员会负责的角色和责任。
2/ 申请+选举
社区成员可以在选举期间申请填补开放的角色，社区投票选举成员。选举可以每年进行一次，这样团队就有时间来交付成果。在 DAO 存在的前几个学期，这些角色可能（全部或部分）由主 DAO 中的一些核心团队直接提名填补，所以产品管理的分权过程以渐进方式发生。
3/ 定义
鉴于母 DAO 已经定义了一定时期内（例如一个学期）的目标和目的，产品委员会将其转换为必须解决的问题。 作为一个例子，设想母 DAO 设定的目标是增加 Aragon 法院的监护人数量（Aragon 法院是 web3 的争端解决系统，依靠人类监护人来裁决所产生的争端）。产品委员会应该深入挖掘问题，采访人们，进行用户测试，并提出需要验证的假设。
- 是否有足够的人知道 Aragon 法院？
- 是否有足够的激励措施来成为监护人？
- gas 成本是否太高，使监护人的互动变得可行？
对假设的验证可以由产品委员会来完成，也可以由社区通过使用用户研究补助金来完成。让我们假设问题已经被确定。在这一点上，产品委员会为每个应该解决的问题定义补助金和/或赏金计划，并在适用的情况下，将它们与可衡量的KPI目标联系起来，这将有助于评估所产生的工作的影响。
4/ 提交建议书
一旦团队交付，产品委员会就会审查交付，以确保质量和遵守 Aragon 的标准（这可以包括一系列的主题，如，UI 组件，代码标准，品牌语气等）。该委员会应根据需要要求其他子 DAO 提供指导或验证（例如，作为技术委员会如果代码被审计）。
5/ 提案选择
产品委员会可以咨询社区，帮助选择他们认为会带来更多价值的提案——可能不止一个。最终的决定将由委员会做出，为给定的提案分配一个具体的奖励。奖励将以托管合同的形式支付，其中包括一个或多个里程碑--确保团队预先知道有资金支付其工作，并将在交付后释放。
6/ 交付
提交入选提案的团队开始进行交付工作。这可能包括从用户调查研究到准备部署的实际代码。
7/ 审查
一旦团队交付，产品委员会将审查交付，以确保质量和遵守 Aragon 的标准（这可能包括一系列的主题，如 UI 组件、代码标准、品牌语气等）。如果需要的话，委员会应该要求任何其他子 DAO 提供任何指导或验证（例如，作为技术委员会，如果代码应该被审计，例如）。
如果交付满足了最初的要求，无论是代码的交付，还是 KPI 目标的实现，或者是两者的混合，产品委员会就会发放该里程碑的付款。否则，它可以要求额外的修改，并反复进行，直到交付满足最初指定的标准。
然后，产品委员会在交付后保持对指标的跟踪（并公开提供给 ANT 持有人），以便社区可以了解解决所定义的问题/机会的进展。我们还可以在此设想使用 UMA KPI 选项，在达到 KPI 目标后自动释放资金。
社区参与产品委员会的决策
有人可能会说，这种设计给了少数人太多的权力，这只是集中式的决策而已--但与传统的组织相比，子DAO的概念本身就邀请社区成员参与关键的决策，尽管是以一种策划和高效的方式。除了子DAO可以让社区参与他们的决策外，社区本身解散子DAO、否决其决策或干预的机制也使得子DAO的设计更没有过度集中化的风险。
为了在产品委员会内部创造更强的激励机制以实现最佳决策，并让其成员参与到游戏中来，我们甚至可以设想一个系统，产品委员会的当选成员可以通过押注他们自己的DAO治理代币来 "支持 "一个去中心化团队的提案--在成功的情况下获得利润（从给予其提案的团队的奖励中获得），在失败的情况下失去其股份。
最后的思考
DAO正处于其成熟周期的早期阶段，这带来了机遇，但也带来了挑战。我们看到的一个挑战是，涌入该领域的巨额资本可能会造成一种虚假的安全感，导致DAO无视产品的采用和发展。
随着DAO模式的扩大，更多的组织将崛起，我们相信，对去中心化产品管理的需求只会变得更加明显。不愿意解决这个问题的DAO将被甩在后面。
Web3正在给传统的商业和所有权模式带来严重的颠覆，使社区和个人能够参与到塑造未来的产品和服务中。如果我们能够将正确的资源分配给正确的机会，我们就能加速这种颠覆，就像产品管理使Web2.0公司成为巨头一样，DPM（去中心化的产品管理）将使DAO能够对抗这些巨头。
参考文献
[1] https://svpg.com/product-vs-feature-teams/
[2] https://www.readthegeneralist.com/briefing/sushi
联系我们
- Discord: https://discord.gg/seedao
- Twitter: https://twitter.com/see_dao