文章来源：Founder Park
文章作者：Startup Recipes
编译来源：What I Learned at Clubhouse
作者 | Anu Atluru
翻译 | 孙薇
来自 Clubhouse 创始成员的 25 条创业经验分享。
Clubhouse，这个 2021 年大火了一把的实时语音聊天房应用如今已经成了过气网红，但 Clubhouse 从早期 1000 名起始用户到月下载量超过 900 万的过程中的得与失，仍然是极具价值的，特别是来自 Clubhouse 内部高管的分享。
本文作者 Anu Atluru，Clubhouse 的第一位社区负责人，在这篇文章中，她分享了她在 Clubhouse 从 1000 名早期用户开始的 2 年发展过程中学到的一切。从 Clubhouse 的产品、社群和运营等方面总结了对于初创企业实用的 25 条经验。Anu Atluru 是一名创业者、天使投资人和创作者，她在 Clubhouse 担任了两年的社区负责人。
以下为分享原文：
过去几年，我在创业方面颇有心得，对于做好初创公司这件事，也有了一些自己的想法。最近两年，我一直在 Clubhouse 工作，得益于团队水平和增长速度，以及投身了新的产品类型，我的学习进度有了突飞猛进的进步。
最开始，这个应用仅有 1 千余名用户，里面的房间（Rooms）都还没有命名，甚至连「俱乐部（clubs）」都不存在。团队成员也仅有几名创始人而已。从这个起点开始，Clubhouse 开始迅猛发展，作为早期员工和社区负责人，在公司里我成了一个相当活跃的人，在这个应用的各个角落，几乎都能见到我的身影。
最近几个月，我渴望有更多时间以创始者的身份来探索一些新的想法，所以我决定离开 Clubhouse，同时作为顾问继续工作。关于如何建立及扩大初创企业的规模，尤其是在产品、社群与团队方面，以及如何以公开的形式完成这些工作，我总结了许多个人经验，并提炼了个人观点。
01产品
经验一：博得构建下一个目标的权利
在追逐下一个具有创造性和实验性的闪亮点子之前，确保自己已经按计划或一开始的做法坚持到底了。「博得构建的权利」，以及「尊重次序」是我已经刻到骨子里的原则。
在最初的阶段，这可能意味着在写下第一行编码前，要对用户需求进行谨慎的评估，并使用无代码最小化可行性产品（no-code MVPs）进行测试。在确定范围阶段，这可能意味着要对第一个版本中的功能进行仔细斟酌。在产品发布之后，在思考下一个版本的功能前，先要严格确保并评估当前版本的功能是否完成。诸如此类。
在元层面上，建立一个考虑到战略匹配、优先级、功能范围、产品发布、评估与迭代等事项，并具有一致性的产品开发过程是极有价值的。
经验二：力争拥有优秀的用户体验和足够好的 UI
简单来说，产品能否正常运行比看上去的视觉效果更为重要，尤其是在产品的初级阶段，对于愿意提供协助的早期使用者更是如此。
优秀的用户体验令产品的核心交互更加容易，因为清晰、容易又简单。而差劲的用户体验会让用户很难明白你想要他们做些什么（甚至都不知道你想让他们这样交互）。差劲的用户体验甚至会让用户放弃一个优秀的产品创意。
从另一方面来说，一个「足够好的」UI 就是……足够好的（特别是 UI 本身就很主观）。举个例子：颜色和字体框架能影响用户对于产品的功用和受众的看法（比如，用户的目标年龄及性格）。然而，一款具有强大实用性和优秀用户体验的差异化产品应当克服这些。
有事实为证：用户报告的 bug 和产品反馈几乎都是与用户体验相关的（或者就是在要求新功能），而那些看似 UI 方面的问题通常与可用性方面的问题同时出现。
经验三：产品判断力更需要技巧而不是天分
很难定义什么样的产品判断力是优秀的，因为这与经验有关——只有在事实和时间证明之后，我们才知道之前的判断是对是错。这更像是一种技巧，而不是纯粹的天分；只有经过练习，你才会愈加娴熟，并保持这样的能力。可以说，最划算的时间投资莫过于花时间深入了解用户：
体验自己的产品（尽可能久，直到你甚至能预测目标用户群组将如何对产品的变化做出反应）；
体验其他产品（了解不断变化的社会文化趋势，理解可能在满足类似需求方面具有竞争力的产品）。
产品策划认为，专业知识、同理心或者创造力的某种组合是做出恰当产品判断的基础，借助用户直接对产品和市场做出深入了解，有助于提高这些能力。这倒不是说必须在早期就构建用户体验研究功能，最佳结论可能来源于你自己的体会（参见经验六和经验二十二），以及参考团队的集体智慧。
经验四：警惕产品复杂化
产品的头一个版本通常都很简单。随着不断构建，产品在质量、实用性和经验方面都会逐渐稳定起来，但到了某一个临界点之后，「稳定」就会悄无声息地变成「复杂」。
这些迹象表明你的产品可能太过复杂：已经发布了一大堆功能，但什么都没删；产品能看得见的地方都被塞满了，没地方给新功能了；用户不清楚该怎么使用这个产品，也不知道要用它做什么。
逐渐复杂化是人为导致的问题。我们在做某样东西时，会产生情感依赖。舍不得将大家辛辛苦苦做出来的东西丢弃掉，也不太根据数据做决定。也或者，我们只是不太清楚用户需要和看重的那一两个核心交互是什么，所以很难抉择。
有了这样的心理预期，及早建立检查点，在发布前就将成功和失败的概念定义下来。构建可靠的流程和追踪正确的指标，有助于建立客观的关键性决策。
02社群
经验五：一个「社群」实际上是许多社群的集合
如果你有两名用户，或许就有了两个用户模型。这只是个例子，不过就算用户群基数再小，对于你的产品，在用户体验、观点、目标和对团队的需求方面，他们也可能有很大的区别。因此，随着社群的发展，用户群会自然分化成许多不同的社区。
用户细分算不上什么学术工作，只是一项具有战略性和可操作性的工作。我们通过定性的洞见、数据和参考用户，协助完成用户模型的定义，并在战略层面上将价值观点与用户类型相匹配。选择提高某个用户分类的优先级，降低另一个。在操作层面上，将用户划定到特定的分类中，并根据类型需求，对他们提供支持。然后建立系统、分配资源，以便在更大规模上实现良好的用户细分。
经验六：与用户沟通（即便你觉得这样是多余的）
这不是一次性的任务，也不是某个人的工作，而应当是整个团队的任务。当试图搞清楚该构建什么样的产品时，准备发布产品时，甚至是用户抗拒产品时，你都应当与用户沟通一下。探讨的话题不只是产品本身，还有他们所属社群的内在驱动力与需求。如果能以产品自身吸引到用户，就算是赚到了！
中间会有许多陷阱，无论是逻辑上的，还是情感上的。就如乔布斯所说，「有些人说：消费者想要什么就给他们什么，但那不是我的方式。我们的责任是提前一步搞清楚他们将来想要什么。」就算事实如此，与用户沟通仍然很有价值。用洞见来理解问题，提炼解决方案，而不要自己去制造洞见。
另一个潜在的陷阱——「最直言不讳的用户并非我们想要的用户。」如果想区分你想要的用户和不想要的用户，请确保你确实知晓其中的区别（参考经验五）。然后努力接触到你想要的用户，我敢保证，对于你在考虑的每个功能、程序或策略，都能找到思虑良久的支持者和批评者。
经验七：通过用户与用户之间的互动创造价值
一个真正的社群是根据其成员之间的交互、关系和价值互换来定义的。因此，围绕你的产品来建立社群，不应只将重点放在团队与用户的互动上，也应当考虑到用户与用户的互动。找到团队所需（比如产品洞见、用户教育、用户成长）与现有用户的需求、兴趣一致和不一致的地方。使用这些来协助识别和测试新的参与方案。
重要的是，不只要告诉用户你想让他们参与什么，还要展示出来。社群与产品之间的协作在这里可能会非常有价值。举个例子：为了解决用户的上手问题，通过产品（比如新手教学）与社群（用户主动分享），在实践中演示功能。如果想要用户用到创建功能，和现有的创建者合作，展示优秀的流程和输出是什么样的。你的用户和支持者们可以增强团队的影响力。
经验八：信任和安全需要持续不断地努力，而不是一个终点
管理用户的信任、安全和隐私必须要有意识、持续不断地努力，什么时候开始都不嫌早，也永远没法做得完。首先，要预测一下什么是只有你的产品在这个领域能遇到的挑战，然后找出用产品、流程和团队解决这些挑战的办法。
你希望用户如何与你的产品、与其他用户、与你的团队互动，就依此创建一组初始规则（比如：社群指南！）。从现有的用户那里获取意见，避免使用专业法律术语，这样就可以很快完成了。这也有助于让你的团队对之后的发展更加清晰、有迹可循。
如果想要建立一个开放的网络社区，这一点尤其重要。弄清楚哪些规则是你想要集中控制，而不是让用户自行决定的。所有集中的规则会设置一个范围标准，由你的团队担任仲裁者；而其他的则允许不在你的控制范围内。
03走向市场与成长
经验九：默认忽略来自亲友的正面反馈，除非有客观数据
通常，最早使用你产品的用户都是你的亲朋好友和同事，他们与你有私交，跟你的成功利益相关。
如果无法让你的初期用户使用并喜欢上你的产品（假设他们正是目标用户），这很可能是准确的负面信号。但如果他们确实喜欢这个产品，甚至表现出「理想」用户的行为（比如与他们的朋友分享产品），你仍应将这种行为当作是错误的正面信号！这是有价值的反馈，但并非客观的质量或潜力增长指标。
如果看到有朋友的朋友开始一次次邀请自己的亲友，这才是更明确的信号。你终于能看到不依赖自身直接关系和影响力的主动行为了。
经验十：在做产品与市场匹配前，先做产品与 GTM 匹配
产品与市场匹配（即产品市场契合度）是一种结束状态，而将产品导入市场（GTM）策略却是由你控制的。如果产品与 GTM 不匹配，就无法创建与市场契合的产品，只能撞大运了（谁又想靠运气呢？）。
产品与 GTM 匹配的一个案例是选择要服务的正确用户群。如果你在构建一个基于群组的产品，请找出是否存在群组的「领袖」原型，这个原型又是否是你应当明确服务并围绕他来构建的。确保你在追捧的这名用户对于你正在构建的产品是正确的选择，反之亦然。
另一个案例是选择有效的种子用户筛选策略。如果你在构建一个闭合或默认私有的网络，可以选择许多不同的群组进行测试，因为实际上它们是彼此互相隔离的。但如果你在构建一个公开或默认公共的网络，第一个群组更为重要——聚焦在在用户特征、规模和节奏上，这个群组会决定早期的用户行为和文化、影响成长方向并为产品的塑造提供反馈。
经验十一：在你需要之前就开始建立一个增长引擎
成长速度是无法选择的，你可以影响或拉慢它（比如给初期访问加上大门），但投入-产出关系不是线性的，而且也需要时间来弄清楚之间的关系。无论你的初始用户是逐渐递增，还是病毒式上涨，你都必须建立一个增长引擎。
尽早开始了解你的产品是如何增长的，这样当（而不是如果）增长率发生变化时（无论上升还是下降），你都能知道影响杠杆是什么，并可以快速进入执行模式。将增长引擎当作一组「循环」（即复合电路），而不是「漏斗」（即不复合的单向通道）。
经验十二：投入社群主导的成长飞轮
传统的产品驱动成长（PLG）意味着需要构建一个在获取和留存用户方面能够自给自足的优秀产品。这是一种直接的产品对用户销售模式，也是「最优产品胜出」模式。而社区驱动成长（CLG）则让社群参与到这个过程中，实现「推荐最多获胜」的模式。
对实用工具型产品而言，PLG 可能是最合适的，能够在第一天（比如没有用户群），或者产品受到社交网络追捧的情况下立刻提供价值。当产品的主要功用不是实用性（比如提供娱乐、身份状态及社交联络）的功用时，人们也许会有多种选择，这时 CLG 就脱颖而出——在这里，一个充满活力和大声表达的社群会起到作用。
举个例子：就算产品只有一小部分作为社群组织者或者「网络节点」的初期用户，也可以协助产品获得并留存用户。权衡 CLG 当然是因为它具有可操作性，但是速度会更慢，可能也更难找到巨大的规模经济。然而，经过验证的社群主导方式也可以通过创造性的方式植入产品中。
04策略与运营
经验十三：「什么都做」不是策略
策略在定义你想做的事情和不想做的事情方面是平等的。优秀的策略可以整理成小册子，是可执行、可衡量的。会迫使你按顺序处理不同的（或分散的）优先级，而不是以并行的方式来处理它们。策略会推动团队一致化，推动招聘和资源优先级的安排。优秀的策略会在企业内部公开传播、不断重申，其精髓也会被分享给用户。
大多数团队一开始都有策略。然而，产品一旦发布，就无法保证会按照期望或设想执行了。出现多个用例和用户群时，这件事确实令人高兴，但也可能会令你的策略模糊起来（尤其是有人要求你更改产品路线图时）。在这种时候，你必须决定哪个方向符合你的策略，哪个方向会分散你的精力——因为什么都做并非策略。
经验十四：顺境时扩大范围，逆境时缩小范围
知道什么时候收缩，什么时候扩张，但绝不要停滞不前。顺利时（比如产品健壮、成长优秀、团队运营良好、士气高涨）扩张工作的范围，实验更多策略。如果在一个或多个方面不顺时，重新审视优先级，并缩小工作范围。这在宏观与微观层面上都很有帮助，无论是对于一家公司、一个团队还是个人而言。
经验十五：每个团队都需要强有力的运营
运营不只是一种职能，而是一种技能。在创业初期，基本上你只有一个跨职能的团队，那么一个强大的运营就足够了。但随着企业成长，也许你为每个职能都设定了独立的团队，「运营」可能就会被孤立。或者，你可能设立几个不同的跨职能团队，分别负责每个业务目标。
无论如何，请确保每支团队都有一个强有力的运营——无论是团队本身的成员，还是运营团队中抽调过去的成员。良好运营的一部分是将重大挑战分解成可操作的工作计划，获得团队的认同，然后坚持不懈地执行这些计划。确保每个团队都有能干的负责人和支持者来扮演这个重要的角色。
经验十六：知道何时衡量投资回报率，何时不用
你可以根据金钱或时间来考虑投资回报率（ROI），无论是你自己的、团队的还是公司的。在投入资源前，先要考虑这个问题；已经运行了一段时间后，也要考虑这一点。通常来说，是有办法提前计划优先级和关注点的。有时候，这可能意味着构建运营模型，有时候则是基于直觉和团队经验，进行简单的 80/20 法则实践（即二八定律，约仅有 20% 的因素影响 80% 的结果）。
但有时候，投资回报率并非最好的衡量方式——通常是对于规模较小、实验性的其他创造性的举措而言。不要急于认为在当下成本和效率不明确时平衡的举措就是没有价值的。相反，要清楚地勾勒出目标，并建立一个过程来衡量投入与产出，预期的影响与实现的影响。
05创建与管理团队
经验十七：专注于技能，而不是职能
对于早期阶段和高成长性创业公司来说，传统的组织职能定义过于僵化，我开始从技能的角度考量。
任何工作可能只需要四项硬技能，分别是数据、设计、工程和运营。每项「工作」都需要这四项技能的组合——产品经理可能也是重要的运营角色，市场营销也可能是个面向数据的角色。「职能」倾向于在有特定的目标和特定环境时，关注这些技能的应用，职能并不总是跨企业的，但技能通常是跨企业的——在招聘时要两点都考虑到。
以这个框架作为起点，任何角色都能更好地分解细化，理解所需的技能，以及日常工作的性质。这样，在招聘时就更有效率，对企业结构和团队整合也更有利，也有助于员工的发展。
