作者：Antoine Sakho
翻译：Kc chen
校对：Morisen
原文链接：
https://medium.com/@antoinesakho/why-web3-needs-product-management-6afabf903df0
本文内容由SeeDAO翻译公会翻译出品
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想赢得怀疑者，并成为不仅仅是加密货币最引人注目的案例研究，它将需要制定一个更清晰的前进道路"。
定期检查Aragon Network的战略和目标。 将目标转化为需要解决的问题（或机会），例如，Aragon Network有一个在特定时期增加活跃DAO的目标。产品委员会将其转化为两个问题--例如，"创建DAO太复杂了"（一个获取问题）和 "没有足够的DAO成员参与治理"（一个激活/保留的问题） 定义一个周期（即一个学期）所需的预算，并将其提交批准。 为Aragon产品中需要解决的具体问题创建赏金/补助金（在批准的预算范围内）。 审查/评估提交的悬赏/赠款，并选择获胜者。 为特定项目雇用社区成员或团队（在批准的预算范围内），例如，产品委员会想进行竞争对手分析，但没有人力去做。它可以为这个特定项目雇用某人。 为社区成员提供产品指标的公共（或门控）仪表盘。 提供当前和未来潜在举措的路线图。 发展设计系统并确保其在Aragon产品中的正确应用。
产品负责人 - 确保产品为客户以及Aragon提供价值。产品负责人负责跟踪指标，找到用户体验中潜在的差距，以达到组织的目标。 产品设计负责人--确保产品有很好的可用性，用户可以很容易地得到他们来时的价值。产品设计负责人还负责确保设计系统的发展，跟上最新的UI/UX趋势。 技术负责人--确保产品运行时尽可能没有错误，并确定需要做的潜在改进/修复。技术带头人还负责确保委员会创建的拨款从技术角度来看是可行的。