惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Help Net Security
Help Net Security
www.infosecurity-magazine.com
www.infosecurity-magazine.com
SecWiki News
SecWiki News
Webroot Blog
Webroot Blog
AI
AI
S
Secure Thoughts
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
Cloudbric
Cloudbric
Hacker News - Newest:
Hacker News - Newest: "LLM"
T
The Exploit Database - CXSecurity.com
Latest news
Latest news
N
News and Events Feed by Topic
Simon Willison's Weblog
Simon Willison's Weblog
Scott Helme
Scott Helme
S
Schneier on Security
H
Hacker News: Front Page
Forbes - Security
Forbes - Security
T
Troy Hunt's Blog
Know Your Adversary
Know Your Adversary
S
Security Affairs
V
Visual Studio Blog
Stack Overflow Blog
Stack Overflow Blog
博客园_首页
腾讯CDC
GbyAI
GbyAI
有赞技术团队
有赞技术团队
Last Week in AI
Last Week in AI
N
News and Events Feed by Topic
WordPress大学
WordPress大学
The Register - Security
The Register - Security
Engineering at Meta
Engineering at Meta
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Cisco Talos Blog
Cisco Talos Blog
人人都是产品经理
人人都是产品经理
大猫的无限游戏
大猫的无限游戏
Recent Announcements
Recent Announcements
V
V2EX
S
Securelist
Security Archives - TechRepublic
Security Archives - TechRepublic
B
Blog RSS Feed
PCI Perspectives
PCI Perspectives
Security Latest
Security Latest
I
InfoQ
I
Intezer
L
LangChain Blog
雷峰网
雷峰网
NISL@THU
NISL@THU
博客园 - 【当耐特】
Microsoft Azure Blog
Microsoft Azure Blog
阮一峰的网络日志
阮一峰的网络日志

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
我在Clubhouse学到的创业经验
我是芝士 · 2022-08-15 · via 人人都是产品经理

编辑导语:Clubhouse所带来的这把火已经没有去年年初时烧得那么旺,但其出现、以及后续的相应现象,都表明这款音频社交软件本身有值得拆解的地方。本文作者便阐述了Clubhouse创业过程中的许多思考,一起来看。

编者按:作为一家初创企业和开辟新品类的产品,Clubhouse 从一开始就吸引了不少的眼球。尽管这款产品现在已经远不如当初那么火,但它的发展之路依然有很多东西值得学习。Clubhouse 的一名早期员工最近辞职开始创业,为此他总结了自己那段经历的各种经验,希望能为自己创业路上的产品、社区和团队建设提供参考。相信这些经验对于广大创业者也很有帮助。

过去几年,我学到了很多关于建设初创公司的知识,并且对如何做好这件事变得更加固执己见。过去 2 年我是在 Clubhouse 度过的,我们团队的才能、公司的增长速度,还有开发一种全新类别的产品的本质,这些都是令我有所收获的推动力。

刚开始时,这款 APP 只有大约 1000 名用户。聊天室没有标题,“club”还是莫须有的事。团队成员只有创始人而已。从那时候起,Clubhouse 一直在公开的状态下进行开发。作为早期员工以及社区负责人,我有很多的机会要面向公众,公司的几乎方方面面我都需要处理。

最近几个月,作为一名创始人,我渴望有更多时间再次去探索新想法,我决定离开 Clubhouse,但仍继续担任顾问。在如何建立初创企业并将其发展壮大这件事情上,尤其是关于产品、社区和团队的建设上,以及如何在公开的状态下做这件事方面,我总结了许多的个人经验,并提炼出一些有用的观点。

一、产品

经验1——赢得开发下一个东西的权利

在追逐下一个创造性、实验性或吸引人的想法之前,先得把打算推出或已经推出的东西做好。“赢得开发的权利”与“尊重先来后到”这些原则已经被我内化了。

在最早阶段,这可能意味着在写任何代码之前,都要对用户需求进行尽职调查,用无代码 MVP 进行测试。在确定范围时,这可能意味着要严格控制功能的版本 1 需要包含的内容。在发布之后,这可能意味着在考虑下一步之前,要严格确保功能的质量,评估功能是否取得了成功等等。

从根本上建立做出一套一致产品的开发流程,综合考虑战略匹配、优先级、范围、发布、评估与迭代,这种做法的价值很大。

经验2——努力打造出色的 UX 和足够好的 UI

简而言之,东西是怎么运作的要比看起来如何更重要。对于处在早期阶段的产品来说更是如此,因为那时候的产品离不开早期采用者的支持。

出色的 UX 可以促进产品的核心互动——清晰、易用及简单。如果用户体验糟糕,用户很难会做你想让他们做的事情(甚至连让他们知道你想让他们做什么都很难)。糟糕的用户体验会让用户放弃好的产品创意。

另一方面,“足够好”的 UI 意思就是……够好就行(尤其是因为这个主观性更强)。比方说,用什么颜色和字体可能会影响对产品用途的感受,也会影响受众(比方说目标年龄段和个性特点)。但是,实用性很强,用户体验出色的差异化产品应该可以克服这一点。

有部分证据表明这一点:错误报告和产品反馈几乎总与 UX(或新功能请求)有关,而那些看似与 UI 相关的往往与可用性问题存在重合。

经验3——产品判断力与其说是天赋不如说是技能

拥有好的产品判断力很难定义,因为这属于经验性的东西;只有在事后在时间的检验下你才会被证明是“正确的”。这更多属于一种技能,而不是纯粹的天赋;你必须不断练习才能变得更好,并将这种能力保持。毫无疑问,你的时间最应该投入到这里——去深入了解用户是如何:

  • 体验你的产品的(深入到甚至可以预测各种目标用户群对产品改变的反应);
  • 体验其他产品的(了解不断发展的社会文化趋势,并了解可能可以满足类似需求的竞争产品)。

产品思想家说,要想有好的产品判断力,具备专业知识、同理心或创造力的一定结合是基础。直接通过用户去深入了解产品和市场对这三个方面都有帮助。这未必就意味着要尽早建立用户体验研究功能。最好的结果来自于自己动手(参见经验#6与经验#22),并利用团队的集体智慧。

经验4——谨防复杂性蔓延

产品的第一版通常都很简单。但随着不断的开发,产品在质量、实用性与体验方面都会变得更加健壮。但是,这种趋势会遇到临界点,过了临界点之后,“健壮”可能会悄然切换成“复杂”。

产品可能过于复杂的一些迹象:你已经推出了一堆功能,但还没有杀死任何一个功能。界面已经没有多余地方放置新功能。用户不清楚该拿产品来做什么,以及该怎么办。

复杂性蔓延是人的问题。我们不想给人以抛弃别人的工作的感觉。我们对数据的依赖程度还不够,不能靠数据来做出决定。或者,我们只是不清楚用户需要和看重的一两个交互是什么,因此很难选择该留下什么和继续做什么。

要对此有预期,然后设立早期的检查点。在发布之前先定义好成功和失败。设立可靠的流程,跟踪对的指标,帮助做出客观、果断的决定——还有,别忘了要建立一个框架去废止一些东西!

二、社区

经验5—— 一个“社区”其实是许多社区的集合

如果你有 2 个用户,可能就会有 2 个用户角色。这是为了举例,但即便是一小部分用户也可以拥有截然不同的体验、观点、目标和需求,需要团队和产品关注。因此,随着网络的发展,用户会逐渐形成许多不同的社区。

用户细分不是纸上谈兵;做得对的话,这是具有战略意义的,可操作的。利用定性的洞察解、数据和参考用户来帮助定义角色。在战略层面上,要将价值主张与用户细分相匹配。要确定优先考虑哪一个用户群,而不是一碗水端平。在运营层面上,将用户分类进特定的细分市场,提供相应支持。然后就是开发系统,分配资源,规模化地做好这件事情。

经验6——与用户交流(哪怕你觉得没有必要)

与用户交流不应该是一次过的事情,而应该是每一支团队都要做的事。你想确定要开发什么产品时,准备要发布产品时,甚至当用户排斥你的产品时,你都应该与用户进行交流。不仅要与他们谈产品,还要谈他们的动机和需求。如果可以用产品固有的方式吸引用户的话,那就会锦上添花!

这一路上你可能会遇到许多陷阱(逻辑和情感陷阱)。这里需要回忆一下乔布斯哲学的原话——“有些人是消费者现在想要什么就给他们什么,但我的做法不是这样的。我们的工作是在他们弄清楚自己想要什么之前先帮他们弄清楚。”就算这话没错,但与用户交流仍然很有价值。只需要利用你的洞察去理解问题和改进解决方案,而不是自己硬造出来。

还有一个潜在的陷阱——“嗓门最大的用户不是我们想要的用户。”如何区分谁是不是你想要的用户?先确保你的确了解其中的区别(参见经验#5)。然后做些工作去接触你想要的用户。无论你在思考什么功能、程序或策略,我相信你都可以找到深思熟虑的拥护者和批评者。

经验7——通过用户之间的互动创造价值

真正的社区要靠成员之间的互动、关系以及价值交换来定义。因此,随产品一起建设的社区不应只关注团队与用户的互动,也应该关注用户与用户的互动。找出团队需求(比方说产品洞察、用户教育、用户增长)与参与用户的需求和兴趣之间一致或不一致的地方。用它来帮助识别和测试新的互动计划。

重要的是,不要光说不做,要向用户展示你希望他们如何参与进来。社区和产品之间的协作也非常有价值。

比方说,为了解决用户教育问题,通过产品(比方说引导流程)和社区(用户主导的引导流程)演示在用的功能。如果你希望用户也参与创作,那就邀请现有的创作者参与进来,展示好的流程和输出是什么样的。用户和支持者可以增强团队的影响力。

经验8——信任和安全不是终点,需要持续努力来维系

管理用户的信任、安全和隐私必须是有意识的、持续的努力;这件事情什么时候做都不会太早,也永远不会有“做完”的那一天。首要任务是预测产品在该领域会遇到的独特挑战。然后,弄清楚如何通过产品、流程和团队来应对挑战。

制定初步规则,约束用户与产品、彼此之间以及与你的团队互动的规范(也叫:社区准则!)。向现有用户寻找输入。预先避开法律术语,所以这是一项快速练习。这也可以帮助你的团队思路更加清晰,并为决策提供指导。

如果你想建立一个开放网络的话,这一点尤其重要。弄清楚哪些规则你希望自己控制,哪些空间留给用户。任何东西一旦中心化就是设置了全网标准,你的团队可能就是仲裁者;任何去中心化的事情均可视为获得了许可,而且你可能会失去控制。

三、进入市场与增长

经验9——朋友的反馈属于误报,除非另有证明

产品的最早用户往往是你的朋友、家人、同事——是你手把手领进门,会分享你成功果实的人。

如果你无法让第 0 天的支持者使用并喜欢上你的产品(假设他们在目标市场里),那可能是一个准确的而且是负面的信号。但是,如果他们确实喜欢产品,甚至表现得很像“理想”用户(比方说还向朋友分享产品),你仍然应该把它当作是误报!作为反馈是有价值的,但这不是质量或增长潜力的客观指标。

再多拓展一个分离度——如果你看到朋友的朋友反复邀请自己的朋友的话,可以把它视为更强的信号。因为这种反馈的意图已经与朋友和你的直接关系以及你的影响无关了。

经验10——产品—GTM 匹配先于产品—市场匹配

产品与市场匹配是最终状态;但是进入市场 (GTM) 策略这个输入则是你可以控制的!如果没有产品与 GTM 的契合,就无法制造出产品与市场的契合;你只能碰巧找到(谁想靠运气呢?)。

关于产品与 GTM 匹配,一个例子是选择合适的服务对象。如果你正在开发基于群的产品,请确定这个群是否存在“领导者”原型,并明确这是不是你应该针对的用户,然后开发相应产品。 简而言之——确保你追求的用户适合你在开发的产品,反之亦然。

另一个例子是选择有效的播种策略。如果你开发的是一个封闭或默认是专用的网络,就可以选择许多不同的群组进行测试,因为这些群其实是相互隔离的。如果你开发的是一个开放或默认是公共的网络,那么选择什么样的聚类用户打头炮至关重要——要刻意按照设定的特征、规模和节奏播下网络的种子。这一群人将设定早期的用户行为和文化,影响增长的方向,并提供反馈,进而塑造产品。

经验11——未雨绸缪,先开发增长引擎

增长率多少你无法选择。你可以影响它或者像打点滴一样调整(比方说对早期访问做门控),但输入—输出关系不是线性的,而且弄清楚公式也需要时间。无论你是逐个去吸引早期用户,还是有幸取得了病毒式的增长,你都必须建立起增长引擎。

要尽早了解增长是如何发挥作用的,这样当增长率发生变化(向上或向下)时,你就能知道撬动增长的因素是什么,然后快速地进入执行模式。要把增长引擎看作是一系列的“环路”(复合的电路),而不是“漏斗”(没有复合的单向通道)。

经验12——投资于社区主导的增长飞轮

传统的产品驱动型增长(PLG)是指开发出一个很出色的自助式产品,基本上实现用户的自主获取和留存。这是产品对用户的直销销售,属于“最好的产品获胜”法。社区驱动型增长(CLG)则是让社区参与到这个过程中,从而实现“最好的推荐获胜”。

最适合 PLG 的也许是工具型产品,可以在第一天就提供价值的那种(比方说,不需要用户网络的形成),或者那种经过了社会或文化验证的产品。当产品的主要目的不是实用性(比方说,作用是娱乐、显示地位、建立新的社会联系),并且人们可能有很多选择时,CLG 就会脱颖而出——对于这方面的产品,一个充满活力、有声有色的社区大有可为。

比方说,即便是身为社区组织者或“网络节点”的一小部分早期用户,也可以为产品背书,并用非正式的手段获取、引导并留住用户。当然, 因为 CLG 的运营性,所以增长速度会比较慢,而且可能更难形成很好的规模经济。但是,经过验证的社区驱动增长法也可以用创造性的方式植入到产品之中。

四、战略与运营

经验13——战略并非万能

战略同样与定义你想做什么和不想做什么有关。好的战略一页纸就能写清楚。好的战略可操作,可衡量。战略迫使你按顺序处理不同(或发散)的优先事项,而不是并行进行尝试。战略推动团队协调、招聘以及资源的优先排序。好的战略公开透明,会反复灌输给公司内部,其精髓也会分享给用户。

大多数团队确实是从战略出发的。但是,一旦产品推出,就没法保证别人会按照你期望或希望的方式使用。当你开始看到出现多个用例,形成更多的细分用户时,一方面会感到兴奋,但这也可能会令战略出现模糊(尤其是如果需要变更产品路线图时)。

在这种情况下,你将被迫就哪些方向契合战略,哪些会分散注意力做出决定——因为什么都做肯定不是战略。

经验14——收放自如,好光景扩张,坏时光聚焦

知道什么时候该放,什么时候该收,但永远都不该躺平。当情况进展顺利时(比方说产品强大,发展良好,团队运作良好,士气高涨),扩大工作范围,进行更多的实验。如果情况不是很好,重新审视优先事项,缩小范围对于公司、团队或个人而言,无论是宏观层面还是微观层面,这种做法都很有帮助。

经验15——每一支团队都需要一名强有力的运营者

运营不仅仅是一种功能,也是一种技能。在初创企业早期,团队基本上是跨职能的。有一位一个强有力的运营者就足够了。但随着初创公司的发展,可能每一种职能都需要设立独立的团队,“运营”可能就会被“烟囱化”。或者,你也可以设立几支跨职能团队,每一支团队负责实现一个业务目标。

不管怎样,都要确保每支团队有一名强有力的运营者——这个人可以是来自团队本身,也可以是空降过来的。要想运营得当,需要的工作之一是将重大挑战分解为可操作的工作计划,让团队保持一致,然后持之以恒地贯彻执行。确保每支团队都有个人拥有扮演这一有价值角色的技能、权力和支持。

经验16——知道什么时候该衡量 ROI,什么时候不该衡量 ROI

可以去评估一下金钱或时间的 ROI(可以是你自己的、你的团队的,甚至公司的)。在投入资源之前先考虑好,不过当事情用某种方式做了很长一段时间时也要评估一下;通常还是有空间确定优先事项以及进一步关注的对象的。有时候这可能意味着要建立运营模式,而有时候则是要靠直觉和团队的经验,做简单的二八原则练习。

但有时候对于小规模、实验性或其他创造性举措来说,投资回报率往往不是最好的衡量标准。要抵制这股冲动,不能因为缺乏明确的成本收益方程式就认为东西没有价值。相反,要阐明目标,建立流程来衡量输入与输出、预期影响与实际影响。

五、建设与管理团队

经验17——关注技能,而不是职能

对于早期和/或高增长的初创公司来说,传统的组织职能定义过于严格。相反我开始思考技能方面的事情。

无论做什么工作,可能只需要 4 项硬技能——数据、设计、工程以及运营。每项“工作”都需要这 4 种技能的一个独特的加权平均。当产品经理也许运营的权重会比较高一些。而当营销的话可以是一个面向数据的角色。 “职能”往往侧重于在明确的目标和背景下应用这些技能。跨组织之后职能未必能成功转化;但技能往往可以——在招聘的时候要两者兼顾。

有了这个框架,你就可以更好地分解任何一个角色,了解所需的技能以及日常工作的性质。这可以帮助你更有效地进行招聘,更好地组织和整合团队,并帮助员工发展。

经验18——团队不应该分“上游”或“下游”

简单地说,在大多数组织都有这 3 个一级域——制造、销售与支持。比方说,在消费科技初创企业中,产品、设计和工程团队大概就组成了“制造”域。 “前台”团队可以做“销售”(比如营销),“后台”团队可以做“支持”(比如客户成功)。重要的是——不要将这些域视为彼此的上游或下游;而应该视为互相协作的关系!

很容易会忘记在不同的域之间建立起有力又灵活的接触点,尤其是在扩张的时候。不同的子团队之间也应该如此(你懂的)。要确保团队之间的及时沟通、协作与共同决策。

经验19——在高速增长期,雇初创企业阶段的变色龙角色

高增长感觉就像你在经营一家大公司,但是却只有一支小团队,并且这件事情就像一夜之间发生的一样。让自己摆脱这种失衡很有挑战。首先,你应该有理由相信自己的产品已经与市场契合,这样新招员工才能与战略方向相匹配。这对于专业和高级职位招聘来说当然更为重要。招聘的时机也很重要,因为随着公司规模的不断扩张和复杂度的增加,不断扩大的团队反而会减慢你的速度。

新聘用的高管应具备 3 种类型的专业知识:扩张所需的流程和系统建设能力、招聘和管理团队,以及行业经验的运用(最好能够端到端地应对类似挑战)。聘请的人要具备这种专业知识,而且好奇心要足、愿意使用产品、肯与用户交谈、行动快速精益、能担任独立顾问或管理人员,可跨职能协作。

是,你肯定有很多问题要问。你需要的是能够实现从 0 到 1 ,并且具备实现从 1 到 n 经验的人——也就是说,早期或发展阶段的角色他们都可以担任。

经验20——对未来要乐观,对过去要现实

乐观很有价值,但乐观是向前看。回顾过去时,需要充分用现实主义去反思。团队复盘是很好的工具。有哪些好的假设、决定和结果?哪些不好?为什么?

就哪些事情进展顺利,哪些进展不顺利进行沟通也很重要。团队成员都是聪明人,无论是因为他们接近数据、与团队成员交谈、与用户交流,还是大量使用了产品,无论如何他们都会知道情况。信任和士气的机遇不仅仅是乐观或成功,也是靠一致的透明度、一致性以及统一的行动计划建立起来的。

经验21——企业文化建立在私信和 1:1 谈话的基础上

与其他时间发生的事情相比,你在全员大会上说了什么,或者在 #general slack 频道上发了什么帖子不那么重要!行为展示文化,大多数行为,不管是好的和坏的,都发生在幕后,在 Slack 的私聊上,在比公开表态更频繁的 1:1 会议上。

招聘的时候也要记住这一点!前 10 到 20 名员工对公司的文化和方向有着直接或间接的巨大影响。这回极大影响到他们之后雇用的人、他们设定的团队文化,以及他们在各个层面和所有渠道的互动方式,因此要从整体上去评估文化契合度。

六、在初创公司工作

经验22——成为自己产品的超级用户

如果说与用户交流很重要的话,那么成为你自己产品的用户同样重要。 (幸运的是,在消费技术领域,你几乎总是自家产品的潜在用户。)

之所以要这样做有很多原因:

  1. 这可以让你对用户感同身受;
  2. 这可以让你的团队感同身受;
  3. 有助于明确用户反馈,了解缺乏背景的数据;
  4. 可以揭示新的产品想法,也因此:可以提高你的产品判断力!

专业提示:了解你自己和团队的使用模式。在团队当中找到高级用户,并通过他们获得洞察。跟踪使用情况是如何变化的(产品有没有变更都要跟踪),并了解原因。产品和面向用户的团队尤其需要沉浸其中,随时掌握情况。

经验23——解锁自己与他人

只要有可能,不要依赖或等待别人去移除障碍。类似技能、信息、获取或时间之类的东西属于有形障碍。无形障碍通常与沟通或心理障碍有关,比如缺乏一致性或恐惧。要积极主动,识别和消除你自己的障碍,进行透明的沟通(参见经验#24),并在必要时让其他人能很容易帮助到你。试着主动帮助其他人解除障碍就更好了。

经验24——充分交流可以,不要承诺过多

对于在快节奏、高度不明确、跨职能团队环境下工作的人,如果我必须给他们提供一条建议的话,我的建议是——充分交流(Overcommunicate)。这一条无论是宏观还是微观层面都适用,随时都适用。例子:

要有求必应,设置好背景,哪怕没法快速响应或者可能根本无法满足(也即:不要承诺过多)。

让人们了解你的工作状态。例如,以易于理解的形式分享每周的进度更新。链接到一个中心位置,让人们可以随时深入了解相关工作或赶上进度。

不要请求许可,请求原谅,但要提前通知。分享你的思考过程和行动计划,并为辩论或分歧留出空间。一般来说别人都会同意的。

向每个人(不仅仅是下属)提供建设性的反馈,同时也要求对方做同样的事情。要定期做这件事。

设定边界,避免影响到个人健康、人际关系和目标。不用说,这些应该是合理的;然后再就此进行沟通!

经验25——知道你想进入哪条车道

最近几个月,在考虑离开 Clubhouse 时,我曾经与公司内外的导师和朋友都交流过。对于同一类问题,他们的回答基本上大同小异。 “你想做什么?” “你的职业发展方向是什么?” “短期与长期哪个重要?”

创业这条职业道路的一个共同的框架出现了——创始人、高管或投资者。这三者并不存在层级关系,因为完全属于不同的车道,但重要的是要知道你现在在哪条车道上,之后你想开到哪条车道。有些人宁愿呆在一条车道上;有些人则喜欢时不时换换道。

我还发现思考一下活力也很有帮助。人们经常问你在扮演某个角色时是不是觉得精力充沛;我倒想问一下你对做其他事情的想法有多兴奋。在活力这件事情上,相对与绝对的影响一样大。

一旦你明确了自己想要什么,请确保你

  1. 培养相关技能;
  2. 明确自己的目标;
  3. 跟踪自己的进展;
  4. 定期放眼长远思考大局以及;
  5. 找到一个由志同道合者组成的社区。

我的一点浅见——最后不管你想做什么,都要用心投入去做。

原文链接:https://36kr.com/p/1858104577185409

译者:boxi;来源于神译局,36氪旗下翻译团队。

本文由@神译局 授权发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议