想象你打开一个应用，它记住你的名字，推荐你喜欢的音乐，甚至在你生日时送上祝福，你会觉得它很贴心。但很多产品却像冷冰冰的机器，只会机械地回应指令。这篇文章来自 Intercom，一家做客户沟通软件的公司，讨论的就是如何通过设计，让产品变得有人情味，让用户感觉被理解和重视。
文章的核心观点是，个性化不是简单地在界面加上用户的名字，而是深入理解用户的使用场景和情感需求，在每一个交互细节中体现关怀。你可以带走的一个判断是：真正好的产品，不是功能最全的，而是最懂你的。设计者应该像交朋友一样，用心去体会用户的感受，让产品成为用户生活中一个温暖的存在。
你有没有发现，有些内容能在网上疯传，而另一些却无人问津？比如，一个明星的八卦可以瞬间刷屏，而一篇深度的行业分析却可能只有几百人阅读。这篇文章来自 Eugene Wei，一位科技行业观察者，他探讨了信息在社交网络上传播的规律，提出了一个有趣的比喻：传播就像炸弹爆炸，引爆它的往往是情绪，而不是事实。
文章的核心视角是，社交网络的设计天然鼓励极端内容的传播，因为平台靠广告赚钱，需要吸引注意力。同时，人们在分享内容时，不只是在传递信息，更是在玩一种“地位游戏”，通过分享来塑造自己的形象。你可以带走的一个判断是：想要内容被广泛传播，与其堆砌事实，不如制造情绪共鸣，或者创造一种“信息缺口”，让读者产生好奇和转发冲动。
想象你买了一个新电器，说明书厚厚一本，但你翻了两页就放弃了，直接凭感觉乱按，最后发现某个功能藏在不起眼的菜单里。用户研究做的就是类似的事，只不过对象是真实的人。这篇文章来自 A List Apart，一个关注网页设计和开发的网站，它提出了一个动人的说法：用户研究本质上就是讲故事。
文章认为，研究者把观察到的用户行为细节，比如先看哪里、犹豫多久、皱眉在思考什么，串成一个有情节的故事，比冷冰冰的数据更能打动人心。因为人的大脑天生喜欢故事，故事里有角色、有情感，容易被记住。你可以带走的一个判断是：在汇报用户研究时，不妨用讲故事的方式呈现，让听者仿佛亲眼看见用户的使用过程，这样更能推动产品改进。
你有没有过这样的时刻，打开一个软件，转圈圈转了好几秒，心里就开始烦躁，哪怕只是等两三秒，也觉得像过了一个世纪。这篇文章来自 Ink & Switch，一个研究创意工具的实验室，它讨论的是软件变慢这件事，但并不是简单地说慢不好，而是深入探讨了速度对用户体验的影响。
文章提出了一个有趣的观点：慢并不总是坏事，关键在于慢得是否合理，是否让用户有所预期。比如，修图软件处理高清照片时，如果进度条瞬间走完，你可能会怀疑它是否认真处理。作者认为，好的软件应该让用户感知到时间，比如显示进度条或动画，这样即使等待时间长，用户也能接受。你可以带走的一个判断是：与其追求绝对的快，不如让慢变得透明和可预期，这样反而能建立信任感。
你有没有想过，为什么电脑上的很多软件，按钮越来越多，菜单越来越长，有些功能你根本用不到，却依然摆在那里？这篇文章从一个具体的小地方切入，那就是命令行工具，就是那种在黑色窗口里输入文字指令来操作电脑的程序。作者 Dan Luu 是一位知名的程序员，他统计了从 1979 年至今很多命令行工具的选项数量，发现它们几乎都在不断增长。
文章的核心视角是，这种功能膨胀（指软件不断添加新功能，却很少删除旧功能）反映了软件设计的一个普遍问题。原因包括用户需求多样、开发者不断添加选项，以及删除旧功能会得罪老用户等。你可以带走的一个判断是：软件越来越复杂不是偶然，而是设计决策和用户需求共同作用的结果。作为用户，我们可以理解这种复杂性背后的原因；作为设计者，则需要警惕功能膨胀，学会取舍。
你也许见过这样的团队：把早期定下的规矩当成不可动摇的信念，哪怕市场早就变了。比如几年前决定不做某个功能，因为当时觉得会分散注意力，可客户的需求已经悄悄转向，团队却还守着旧原则不放。Basecamp 联合创始人 Jason Fried 发现，这种“不忘初心”的做法有时反而会拖累公司，因为环境在变，当初的判断未必还适用。
他提出一个更实用的思路：做你现在认为对的事，而不是你以前认为对的事。原则应该分两类，一类是无论何时都正确的，比如尊重客户，另一类是只在特定条件下成立的，比如不做某个功能。后者要允许被重新审视。文章用他们公司新增聊天功能为例，说明当客户需要更轻量的沟通时，旧原则就该让位。你可以带走一个判断：区分“常青决策”和“权宜决策”，前者坚持，后者灵活调整，这样既不会失去方向，也不会被过去绑住。
你可能会困惑，为什么自己读了很多书、上了很多课，却感觉没什么进步。人工智能工程师 Chip Huyen 也遇到过这个问题，她发现很多人把“学新东西”等同于“成长”，但收藏一堆文章并没有改变做事方式。她提出一个更朴素的成长标准：你的行为真的变了吗？比如以前写代码先动手，现在先想清楚；以前开会抢着说，现在先听。这些细微改变才是真成长，否则只是在收集信息。
她用自己的经历说明，成长往往发生在不舒服的时候，比如学会放弃完美、分清主次。她以前总想把每件事做到最好，后来意识到这反而耽误了更重要的事。成长不是把所有事都做好，而是知道什么值得做好。你可以带走一个判断：用行为变化来衡量成长，而不是知识量；主动去碰让你有点害怕的事，那才是成长发生的地方。
想象你是一家初创公司的创始人，花了一年时间做出一个自认为很酷的安全产品，却始终找不到愿意付费的客户。文章通过Material Security的早期经历，展示了他们如何从空想转向与潜在用户深度对话，用预售订单来验证真实需求，避免在错误方向上浪费资源。
核心视角是把产品市场匹配看作一个可操作的验证过程，而不是碰运气。读者可以带走一个判断：在投入大量开发前，先用手工服务或原型去获取少量付费承诺，用客户的真金白银来证明需求存在，而不是依赖自己的直觉或问卷反馈。
你也许用过打车或租房平台，发现有时候想找的东西就是没有。这类平台叫双边市场，一边是供应方，一边是需求方，最头疼的是两边人数不平衡。很多人以为解决办法是打广告拉新，但增长专家 Casey Winters 指出，真正的需求其实藏在平台自己的数据里，只是没被认真看。比如用户搜索“实木书桌”很多次，但平台上供应很少，这些搜索就是现成的需求信号。
他举了 Airbnb 的例子，早期发现很多人搜索特定区域，但房源不足，于是他们不是投广告，而是专门去那个区域找房东。这个做法比盲目拉新有效，因为需求已经明确，补上供应交易立刻发生。为什么容易被忽略？因为团队习惯看总量，但总量是由无数细分需求组成的。你可以带走一个判断：在双边市场中，通过分析搜索等需求信号，针对性地补充供应，比泛泛地拉新用户更能促进增长。
当视障用户打开一个满是图片的网页，屏幕阅读器只能念出文件名；当听障人士观看一段没有字幕的视频，他们只能猜测内容。这些日常障碍背后，是大量需要人工处理的标注、转录和描述工作，成本高且难以规模化。文章指出，人工智能恰好能在这类重复性高、规则明确的任务中提供帮助，比如自动生成图片替代文本、实时字幕和语音导航。
核心视角是把无障碍设计从“事后补救”转向“AI 原生”，即在产品设计初期就利用模型能力减少信息缺口。读者可以带走一个判断：AI 不是替代人工审核，而是先完成粗粒度覆盖，让人力聚焦于复杂场景的校验。对于团队而言，这意味着要重新分配资源，而不是简单采购一个工具。文章提醒，任何自动化都要保留人工反馈闭环，否则会放大偏见和错误。
当你在短视频或社交媒体上漫无目的地滑动，时间不知不觉流逝，你可能会好奇：为什么这些产品让人如此上瘾？文章从“美国偶像”这类选秀节目切入，探讨人们为什么愿意花大量时间观看普通人表演，并以此类比互联网产品的吸引力机制。
核心视角是“身份资本”和“社会认同”：人们消费内容不只是为了娱乐，更是为了寻找自我表达和群体归属。读者可以带走一个判断：好产品不是让用户“打发时间”，而是帮他们积累某种可展示的“身份资本”，这才是长期黏性的来源。
很多团队听到“个性化”就急着上算法、堆数据，结果往往花了大力气却只做出“猜你喜欢”式的表面功夫。文章针对这个常见困境，提出在真正动手做个性化之前，先开一场“预备个性化工作坊”。这个工作坊不碰技术，而是让产品、设计、运营等角色坐在一起，把“我们到底想为谁解决什么问题”这件事彻底想清楚，避免把个性化做成自嗨的功能。
核心视角是把个性化从“技术问题”重新定义为“组织共识问题”。文章给出的判断是：个性化失败的根源通常不是算法不够聪明，而是团队对目标用户和业务优先级没有对齐。读者可以带走一个实用动作：在写代码之前，先花半天时间用工作坊模板梳理用户场景和成功指标，这比任何推荐系统都更能决定项目成败。
当团队把营销等同于投放广告、发推文或做活动时，很容易陷入一种状态：预算花了不少，用户却没记住产品。这篇文章从日常工作场景切入，指出营销常被误解为对外喊话，而真正的问题在于团队如何理解自己每天在做的事。
核心视角是把营销重新定义为产品与用户之间的每一次接触，而不是一个独立部门的工作。读者可以带走的一个判断是：与其追问下一个营销活动怎么做，不如先检查产品本身是否传递了清晰的价值信号。营销的起点在内部，不在外部。
当你在网上分享一个模型或代码时，可能没想过它会突然被大量请求淹没。这篇文章讲述了一次意外事件：OpenAI 的某个操作不小心对 Hugging Face 平台发起了攻击，导致服务出现问题。作者整理出了详细的时间线，帮你理解这类事故是如何一步步发生的。
文章的核心视角是“意外攻击”这个概念，它提醒我们，即使是大型 AI 公司，也可能因为配置失误或疏忽，对第三方平台造成破坏。读者可以带走的一个判断是：在 AI 生态中，安全不仅关乎恶意攻击，也关乎无心之失，平台和用户都需要为这种可能性做好准备。
当你在机场等待航班起降时，可能从未想过幕后有一群人在用秒级决策守护每一次飞行。这篇文章通过空管员的第一视角，展现他们如何在高压、多任务和极端不确定性中保持专注与冷静。对于任何需要处理复杂信息流、快速做出高影响决策的产品经理或团队负责人来说，这种日常就像一场关于注意力分配和风险管理的实战演练。
核心视角不是技术操作，而是人的认知极限与系统设计如何相互塑造。空管员依赖的不是超能力，而是经过长期训练形成的心理模型、清晰的工作流程和团队间的默契沟通。你可以带走的一个判断是：在高风险环境中，可靠的系统不是靠个人英雄主义，而是靠把复杂决策拆解成可重复、可验证的步骤。这对设计用户流程或团队协作机制同样适用，提醒我们减少认知负担往往比增加功能更有效。
当你在聊天框里输入一句话，AI 的回答有时天马行空，有时又太过保守。这背后是几个旋钮在起作用，比如温度、top-k 和 top-p。它们决定了 AI 在生成文字时是更随机还是更稳定。文章用具体例子解释了这些参数如何影响输出，并引入了“测试时计算”的概念，即在生成答案时让 AI 花更多时间思考，而不是简单地从模型里直接抽一个词。
文章的核心视角是把生成配置看作产品调优的工具，而不是纯技术细节。对于普通读者，你可以带走一个判断：调整这些参数就像调整菜谱的调料，多一点或少一点都会改变最终味道。理解它们能帮你更好地预测 AI 的“性格”，无论是用于写作辅助还是客服机器人，都能更精准地控制输出风格。
很多团队在尝试让 AI 自动写代码，但发现它经常出错。文章从一次“加拉帕戈斯群岛”的实践出发，讨论了代理式测试流程，也就是让 AI 不仅写代码，还要自己测试和修复。它指出，AI 写代码的真正瓶颈不是生成，而是验证，如何确保生成的内容正确。文章还提到了 LLM 基准测试的局限，即标准测试不能反映真实场景的复杂性。
核心视角是：AI 编程的价值不在于替代人类，而在于改变工作流。读者可以带走一个判断：如果想让 AI 写代码，应该把精力放在构建自动测试和反馈循环上，而不是追求更聪明的模型。这就像训练新人，你需要给他清晰的验收标准，而不是只让他埋头写。
想象一下，你正在打磨一把小刀，刀锋要足够锋利才能切开日常的绳索，而一艘战舰则需要厚重的装甲和巨炮来应对海战。这两者没有谁更好，只是用途完全不同。文章用这个比喻来讨论产品设计中的常见误区：团队常常拿一把小刀的标准去造战舰，或者反过来，用战舰的思路去打磨小刀，结果都不伦不类。
核心视角是提醒我们，先想清楚你究竟在造什么，再决定用什么规格和资源。读者可以带走一个判断：不要盲目追求复杂或简单，而是先定义你的产品要解决的具体问题，然后匹配相应的投入和设计哲学。这样，无论是小工具还是大系统，都能各得其所。
当你在网上购物或刷视频时，后台的服务器其实在同时处理成千上万个请求。为了保证公平，系统会用一种叫“容器”的技术把每个任务隔开，限制它们能用的计算资源。但作者发现，这种限制有时会突然卡住任务，就像高速公路上明明没堵车，却因为限速牌忽快忽慢，导致车辆走走停停。这会让用户感觉网页变慢，而工程师却很难找到原因。
文章用日常比喻解释了“容器限流”这个专业术语，指的是系统给任务设定的资源使用上限。核心视角是：性能问题不一定来自硬件不够，而可能藏在看似合理的资源管理规则里。读者可以带走一个判断：当服务变慢时，除了升级机器，还要检查资源限制的配置是否合理，因为微小的参数调整可能比加钱买服务器更有效。
当你在网上分享自己的模型或数据时，可能没想过会被大公司无意中“攻击”。这篇文章梳理了OpenAI对Hugging Face的一次意外攻击时间线，让你看清事件如何一步步发生，以及普通用户为何会受影响。
核心视角是技术事故背后往往有流程和沟通问题，而不只是恶意。读者可以带走一个判断：在依赖第三方平台时，要留意其安全策略和透明度，别把信任当作默认选项。
当你以为影评只是个人喜好时，作者却从年度电影清单里提炼出关于注意力经济与内容消费的洞察。文章不讨论剧情好坏，而是追问：为什么某些电影能让人沉浸，某些却沦为背景音？这背后其实关乎产品如何争夺用户的时间与情感。
核心视角是把电影看作一种“体验设计”，类比互联网产品的留存与传播机制。你可以带走一个判断：真正抓住人的内容或产品，往往不是靠功能堆砌，而是靠创造一种难以复制的情绪节奏与记忆点。
很多产品上线后热闹一阵就沉寂了，团队困惑于用户为什么来了又走。这篇文章直面这个问题，指出从测试版到成熟产品的跨越，关键不在加功能，而在建立用户离不开的“基石”体验，就像房子从临时帐篷变成永久地基。
核心视角是产品粘性来自“习惯回路”的养成，而非单点惊喜。读者可以带走一个判断：与其追求大而全的发布，不如先找到那个让用户每天回来的最小闭环，再围绕它加固。
创业团队常常在乐观中推进，直到撞上墙才后悔当初没多想。文章提出一个反直觉的做法：在项目开始前，假装它已经失败，然后集体写下失败原因。这种“预先验尸”能提前暴露致命风险，而不是等资源耗尽后再补救。
核心视角是把失败分析前置，当作决策工具而非悲观主义。你可以带走一个判断：任何计划在启动前都应该问“它为什么不会成功”，并认真对待那些答案，这比事后复盘更省成本。
很多产品设计只考虑好看或好用，却忽略了它其实在悄悄改变用户的行为。作者用日常例子说明，界面的布局、按钮的位置甚至默认选项，都在引导人们做出选择，就像超市把糖果放在收银台旁边。设计不是中立的，它自带价值观。
核心视角是设计即干预，每个细节都在塑造使用习惯。读者可以带走一个判断：如果你不想让用户沉迷或走偏，就要主动检查设计中的“行为暗示”，而不是等数据出来再补救。
当大家都在模仿别人的商业模式时，少数公司却靠打破常规模型获得爆发式增长。文章用“破模者”这个概念，讲那些不按行业套路出牌的企业如何重新定义价值交换，比如从卖产品变成卖订阅，或者从抽成变成免费加增值。
核心视角是竞争优势不来自优化现有模型，而来自重构它。你可以带走一个判断：如果你的增长陷入瓶颈，不妨问自己“行业里哪些‘理所当然’的规则可以被推翻”，那可能就是下一个突破口。
当你打算开发一个新的人工智能工具时，最想知道的是别人已经做过什么、哪些方向还有机会。作者分析了九百个最受欢迎的开源人工智能项目，发现很多工具都集中在少数几个领域，比如大语言模型的接口封装、训练和微调，而像数据处理、模型评估这些环节反而被忽视。
文章的核心视角是从项目数量、受欢迎程度和增长趋势来观察整个生态的供需状况。你可以带走的一个判断是：与其挤进已经拥挤的赛道，不如去那些需求存在但供给不足的环节寻找机会，比如为特定行业做深度适配的工具。
当你想知道一个新的人工智能模型到底行不行，通常的做法是拿标准测试题去考它。但作者发现，很多测试题本身就有问题，比如答案可能事先泄露，或者题目和实际使用场景差得很远。他用一个比喻说，这就像冬天给汽车换雪地胎，如果你只看轮胎的花纹而不管路面状况，判断就会出错。
文章的核心视角是提醒我们，评估模型不能只依赖现成的基准测试，还要结合具体任务做“餐巾纸数学”，也就是用简单的估算来验证测试结果是否合理。你可以带走的一个判断是：在相信任何评估结果之前，先检查测试数据是否干净、测试条件是否贴近真实场景，否则结论可能完全不可靠。
如果你用过编程助手，可能会遇到这样的烦恼：它有时会自作主张地修改代码，让你不敢放手让它干活。现在，Claude Code 把“自动模式”设为默认，这意味着它会主动执行更多操作，而不是每步都等你确认。这就像从手动挡汽车换到自动挡，开起来更省心，但也要担心它会不会突然加速。
文章的核心视角是讨论这种默认设置的改变对用户体验和风险的影响。你可以带走的一个判断是：自动模式能提高效率，但你必须清楚它的能力边界，并且保留随时接管控制权的能力，否则在关键任务上可能会出大问题。
当你向一个大型语言模型提问时，它可能给出一个听起来很合理但其实是编造的回答。这就像你问一位专家问题，他却随口胡诌，而你很难分辨。作者提出了一种新的使用方式，叫“询问式大语言模型”，意思是把模型当作一个可以被反复盘问的对象，通过追问和验证来逼近真相。
文章的核心视角是区分两种使用模型的方式：一种是让它直接给答案，另一种是把它当作一个信息来源，通过提问和交叉检查来获取知识。你可以带走的一个判断是：与其指望模型给出最终答案，不如学会设计问题来引导它提供可验证的线索，这样能减少幻觉带来的风险。
当你坐飞机时，可能很少想到背后有一群工程师在确保每一个零件都安全可靠。这篇文章通过采访一位民航工程师，带你走进他们的日常工作：从检查飞机结构到处理突发故障，每一步都需要极其细致和谨慎。你会发现，这个职业远不只是修飞机，而是关乎数百万人的生命安全。
文章的核心视角是从人的角度展示这个职业的挑战和满足感，强调在高度规范化的行业里，人的判断和经验依然不可替代。你可以带走的一个判断是：在安全至上的领域，流程和标准是底线，但真正决定成败的是工程师在复杂情况下如何灵活应对，这种能力需要长期积累。
想象你一年只买几次房、几次车，每次都要花大量时间比价、谈判、签合同。这种低频又大额的交易，效率往往很低，因为你没有机会通过重复练习来优化流程，也缺乏足够的信任基础。文章从个人经验出发，讨论为什么这类交易总是充满摩擦。
核心视角是交易频率和交易金额会决定市场结构。读者可以带走一个判断：如果你在做低频大额交易的产品，别指望靠算法或流程自动化解决一切，真正要解决的是信任和决策焦虑，比如提供更透明的信息或更可靠的担保机制。
很多创业公司以为找到产品市场契合点就是不断加功能，但Serval的故事告诉你，真正需要的是倾听客户，甚至敢于砍掉不重要的功能。文章通过Serval的案例，展示他们如何从企业客户的实际痛点出发，同时兼顾消费级产品的易用性。
核心视角是产品市场契合不是一次性的，而是持续迭代的过程。读者可以带走一个判断：与其闭门造车，不如花时间做客户访谈，发现他们真正愿意付费解决的问题，再用最简单的方式满足它，而不是堆砌功能。
你用过淘宝、滴滴或Airbnb，这些平台之所以能成功，是因为它们解决了买卖双方之间的信任问题，同时让交易变得流畅。文章从市场平台的角度，分析为什么有些平台越用越有价值，而有些却难以起步。
核心视角是网络效应和流动性是市场平台的核心壁垒。读者可以带走一个判断：如果你在搭建市场平台，优先考虑如何让供需双方快速匹配，并建立信任机制，比如评价系统或保证金，而不是一开始就追求功能齐全。
现在很多团队急于用生成式人工智能做产品，但常常踩坑，比如模型输出不稳定、成本过高、或者用户反馈不佳。文章总结了这些常见陷阱，并给出了一些实用的建议，帮助团队少走弯路。
核心视角是生成式人工智能应用的成功不取决于模型本身，而在于工程化能力。读者可以带走一个判断：在投入资源前，先想清楚你的应用是否真的需要生成式人工智能，以及如何设计评估指标和兜底方案，而不是盲目追求技术新颖。
很多项目延期，不是因为程序员不够努力，而是因为沟通和协调成本随着团队规模上升而急剧增加。文章重新审视了经典的“人月神话”观点，讨论为什么增加人手往往不能加快进度，反而可能拖慢项目。
核心视角是软件开发的复杂性来自交互，而不是单纯的工作量。读者可以带走一个判断：如果你在管理项目，别指望靠堆人解决问题，而是要优化团队结构，减少不必要的沟通链路，比如采用小团队或模块化设计。
当一家公司发布新模型时，人们往往只关注它的跑分和演示，却很少追问它到底被设定成什么样的人。这篇文章把Claude Opus 5的系统提示词全文贴出来，相当于把模型背后的“性格说明书”摊开给你看。如果你正在用AI做产品，或者只是好奇大模型为什么有时会拒绝某些请求，这会解答你的疑惑。
作者是知名开发者Simon Willison，他长期追踪AI工具的实际使用体验。他的核心观点是：系统提示词就是模型的“宪法”，它决定了AI在边界情况下的反应。你可以从中判断这家公司对安全、隐私和用户关系的真实态度，而不是只听发布会上的漂亮话。读完你会明白，选择哪个模型，本质上是在选择一套价值观。
如果你听人说Transformer、注意力机制、GPT这些词就头大，这篇文章是为你准备的。它把从2017年到现在所有主流AI模型的结构变化梳理了一遍，就像看一部家族谱系图。作者用清晰的语言解释每个模型改进了什么，比如为什么有的模型更擅长长文章，有的更擅长对话。
作者是OpenAI的机器学习专家，她写这篇不是给研究员看，而是给产品经理、创业者等非专业人士做科普。她的核心视角是：理解这些技术差异，能帮你判断不同AI服务的成本和能力边界。比如，为什么某些模型处理长文档贵，为什么有的模型响应快。读完你至少能听懂技术讨论，做出更明智的选择。
想象一下，你每天要管理一座城市大小的区域，几十万人的出行、安全、商业都压在你肩上。这篇文章采访了一位机场CEO，让你看到这个角色真实的工作状态。它回答了一个具体问题：当同时发生航班延误、天气突变和旅客投诉时，决策者的大脑里在发生什么？
文章来自行为科学杂志，它用心理学视角拆解高层管理者的决策过程。核心观点是：机场CEO的很多决定不是基于完美数据，而是在信息不全时靠直觉和团队协作。你可以带走一个判断：在高压力环境下，所谓的“理性决策”其实充满了认知偏差，理解这点对任何团队管理都有启发。
我们每天都会做决定，但很少回头检查这些决定到底好不好。这篇文章讨论了一个看似简单的问题：当结果很容易衡量时，比如投资回报率或网站点击率，为什么很多决策依然糟糕？作者用真实案例说明，即使有数据，人们也会因为各种原因做出错误选择。
作者Dan Luu是知名技术博主，他以犀利分析著称。他的核心视角是：决策质量不等于结果质量，因为运气和外部因素会干扰。他提出一套评估决策的方法，帮助你区分“好决策坏结果”和“坏决策好结果”。读完你会学会在复盘时更客观，不再因为一次成功就盲目自信。
很多团队想创新，但每次提大方案就被否，只能做小修小补。这篇文章来自Slack首席产品官的访谈，他分享了自己如何推动公司做出更大胆的产品决策。文章用具体案例说明，为什么渐进式改进会让产品平庸，以及如何说服团队和管理层接受高风险项目。
核心视角是“大胆下注”不是盲目冒险，而是有纪律的押注。作者提出一套框架，包括如何评估机会、如何分配资源、如何设定止损点。你可以带走一个判断：真正突破性的产品往往来自那些敢于放弃小机会、集中资源打大仗的团队。读完你会知道，下次提大方案时，该用什么话术和依据来争取支持。
想象一下，你发了一条朋友圈，等点赞时心里那种微妙的感觉。这篇文章从“社交资本”这个日常概念讲起，解释为什么人们会在网上晒照片、发动态，甚至为什么有些产品能让人上瘾。它把互联网产品比作一个巨大的“地位交易所”，每个人都在用内容换取关注和认可。
作者用“IPO”作比喻，说我们每个人的社交账号就像一家小公司，发状态就是在“上市”。核心观点是：真正成功的产品，往往是在帮用户高效地积累或展示社交资本。读完你可以带走一个判断：当你评估一个新产品时，不妨问一句，它让用户获得了什么“地位”，又让谁失去了什么？
当你在设计一个产品界面时，可能会遇到这样的困惑：用户觉得某些操作方式很顺手，但这些方式并不符合设计规范。比如，一个电商应用里，用户习惯在商品列表页面直接滑动删除商品，而不是先进入详情页再找删除按钮。如果强行按规范来，用户会觉得难用；如果完全放任，又可能让整个产品显得杂乱无章。这篇文章讨论的正是这种矛盾。
文章提出一个核心观点：设计系统就像一种语言，有语法和词汇，但不同地区的人会有自己的方言。好的设计不是死守规则，而是理解规则背后的目的，然后在不破坏整体一致性的前提下，允许一些灵活的变体。读者可以带走一个判断：当团队面对规则与用户习惯冲突时，先问自己这个规则保护的是什么核心体验，然后在不伤害它的基础上，为特定场景设计出合适的变体，而不是一刀切地禁止或放纵。
一家做文档数据处理的小公司，早期产品没人用，创始团队只好一家家去敲客户的门。他们发现，真正愿意付费的不是那些看起来规模大的公司，而是有具体痛点、愿意陪着你改产品的小团队。这个过程中，他们慢慢摸清了什么样的客户值得服务，什么样的需求才是真需求，而不是自己拍脑袋想出来的功能。
文章的核心视角是：产品市场契合不是一次性的发现，而是通过大量客户访谈和销售反馈逐步逼近的过程。读者可以带走的一个判断是，早期别追求大客户，先找到一小群愿意深度参与、反馈及时的种子用户，让他们的真实问题塑造产品。判断是否接近契合的信号，不是客户说“不错”，而是他们主动续费、催你上线新功能，甚至帮你推荐给同行。
想象一下，你花了好几年精心打磨一款软件，界面简洁、操作顺手，用户也渐渐习惯了。可突然有一天，团队为了追求新功能或新设计，把原来的体验改得面目全非。老用户找不到入口，新用户觉得复杂，抱怨声一片。这篇文章讨论的就是这种“大倒退”，也就是产品在演进过程中，无意间丢掉了那些让用户感到舒适和高效的核心体验。
作者的核心视角是提醒我们，进步不等于改变，有时候克制和维持稳定反而更重要。他主张在追求创新的同时，要像保护眼睛一样保护那些已经验证过的、用户依赖的交互方式。读者可以带走的一个判断是：在规划产品迭代时，先问自己一个简单问题，这个改动是让用户更省心，还是只是让团队显得更忙碌？如果答案是后者，那可能就需要三思而后行了。产品设计不是不断堆砌，而是懂得在合适的时候说“不”。
当你想用一款新聊天软件，却发现朋友都不在上面时，你会明白网络效应：人越多，产品越有用。但有些产品的价值增长并不靠用户直接互动，比如一个在线文档工具，用户各自使用，却因为文件格式和分享习惯被牢牢绑在一起。这类隐藏的网络效应，往往比显性的社交网络更难被竞争对手复制。
文章提出，判断产品壁垒不能只看用户数量，还要看数据、工作流和生态系统中那些不显眼的连接点。它帮助你把注意力从热闹的社交圈转向安静的日常工具，理解为什么一些看似普通的软件能长期占据市场。读完你会获得一个实用视角：评估任何产品时，先问它的价值是否随使用人数自然增长，即使这些使用者彼此看不见。
训练人工智能模型时，最头疼的问题往往是数据不够。比如你想让模型学会识别某种罕见动物的叫声，但网上能找到的样本只有几十条，模型根本学不会。这篇文章讨论的就是这种情况下的应对方法：与其到处找数据，不如自己动手生成数据。作者把生成数据的方法分成几类，并讨论了各自的适用场景和风险，比如生成的数据质量不高可能会让模型学到错误的东西。
文章的核心视角是“数据生成不是万能药，但也不是禁区”。作者用清晰的框架帮你判断什么时候该用生成数据，什么时候该谨慎。读者可以带走的一个判断是：先想清楚你要解决的是数据数量问题还是数据质量问题，如果是后者，生成数据可能帮不上忙，甚至会帮倒忙。
现在很多程序员开始用人工智能工具来写代码，只要用日常语言描述需求，工具就能生成一段程序。这种开发方式被叫做“氛围编程”，听起来很方便，但很多人担心这样写出来的代码不可靠。这篇文章讨论的就是这种新编程方式到底靠不靠谱，以及它会在什么场景下取代传统编程。
作者是软件工程领域的老前辈，他并不全盘否定这种新方式，而是冷静地分析了它的适用边界。读者可以带走的一个判断是：氛围编程适合快速做原型或者写一次性脚本，但涉及核心业务逻辑时，还是需要人仔细审查和测试，不能完全放手。
夏天到了，很多人想找几本好书充实自己，但市面上的书太多，不知道选哪本。这篇文章是行为科学领域的专家们推荐的一份夏季书单，涵盖了心理学、经济学、社会学等多个领域，既有经典也有新作，适合对人和行为感兴趣的大众读者。
文章的核心价值在于这些推荐来自专业人士的视角，他们不仅列出了书名，还简要说明了推荐理由。读者可以从这份书单中挑几本自己感兴趣的，作为了解行为科学的入门读物，也可以作为和朋友聊天的谈资。
现在很多大语言模型产品会隐藏自己的“思考过程”，只给你最终答案，但最近有研究者发现，可以通过一些技巧把模型内部的推理痕迹偷出来。这篇文章讨论了这个安全问题，作者是知名开发者，他详细解释了这种攻击的原理和潜在影响。
文章的核心视角是“这不是小问题，而是整个行业需要关注的漏洞”。作者提醒开发者，如果你的产品依赖大模型的推理能力，那么这些推理痕迹可能包含用户隐私或商业机密。读者可以带走的一个判断是：在模型供应商修复这个问题之前，不要假设模型内部的思考过程是安全的。
你有没有过这样的经历：买了个新电器，结果说明书看不懂，操作界面反人类，用了没几天就坏了。这篇文章探讨的就是为什么现代产品好像越来越难用，质量也不如以前。作者从多个角度分析了这个问题，包括市场竞争、消费者偏好和生产成本。
文章的核心观点是“不是产品变差了，而是我们衡量质量的方式变了”。作者指出，很多消费者在购买时更看重价格和功能，而不是耐用性和易用性，导致厂商不愿意在这些方面投入。读者可以带走的一个判断是：如果你希望买到好用的产品，可能需要主动去关注那些注重长期口碑的小品牌，而不是只看大牌和低价。
你打开一个网页，按钮动效流畅，卡片翻转顺滑，但总觉得哪里不对，像是隔着一层玻璃在操作。这种感觉来自交互的“恐怖谷”：当数字产品模拟得足够像物理世界，却又差那么一点时，用户反而会感到不安和疏离。文章从这条曲线出发，解释为什么过度拟真会适得其反。
核心视角是：交互设计的目的是清晰传达反馈，而不是复刻现实。你可以带走一个判断：在决定动画时长、物理引擎或手势细节前，先问自己，这个交互是否让用户更明白“发生了什么”，而不是更炫目。真正的创新不是堆叠效果，而是让界面在“真实”和“抽象”之间找到那个让用户最舒服的点。
当产品团队急于追求创新时，常常会忽略那些经过时间验证的基础设计原则。比如，用户习惯点击左上角的返回按钮，或者期待表单有明确的错误提示，这些看似简单的细节，如果被随意改变，会让用户感到困惑和沮丧。文章通过具体场景说明，在资源有限的情况下，遵循成熟的设计规范不是保守，而是为真正的创新腾出空间。
核心视角是：基础原则是创新的地基，而不是束缚。读者可以带走的一个判断是，在动手设计新功能前，先检查是否已经满足了用户的基本预期。如果连基础都做不好，创新只会变成空中楼阁。文章提醒我们，把基础打牢，才能让创新有立足之地。
当设计师拿到一份用户研究资料，发现里面全是拉丁语、古英语这类没人日常使用的语言时，会立刻意识到产品定位出了问题。这篇文章讨论的正是类似困境：很多人工智能产品在训练和设计时，依赖的是过时或脱离实际的数据和规则，就像为一种已经死去的语言做界面。作者用这个比喻提醒我们，如果产品服务的对象是真实世界的活人，那么设计依据就必须来自他们当下的表达和习惯，而不是停留在教科书或旧文档里。
核心视角是把“语言死亡”当作产品设计失效的隐喻，指出技术团队容易陷入用历史数据预测未来行为的误区。读者可以带走的一个判断是：在搭建人工智能产品前，先确认数据源和交互逻辑是否还匹配目标用户的真实语境，否则再精巧的界面也会像给现代人看甲骨文一样无效。
一家新公司做出产品后，最头疼的是怎么让第一批用户愿意掏钱。很多创业者以为只要产品好就会有人买，但现实是，你往往需要亲自上门，一家一家去谈，甚至根据每个客户的需求反复修改产品。这篇文章讲的就是这样一家叫 Merge 的公司，他们早期没有走捷径，而是靠创始人和团队直接去销售，在一次次被拒绝中慢慢找到了真正愿意付费的客户。
文章的核心视角是，产品与市场的匹配不是一次性的灵感，而是一个不断试错和调整的过程。你不需要一开始就做出完美的东西，但必须从真实客户的反馈中快速学习。读完你可以带走一个判断：如果你还在早期，别急着铺开市场，先花时间把少数几个客户服务到极致，让他们成为你的口碑来源，这比任何广告都有效。
当你在使用一款软件时，是不是常常觉得有些功能明明存在，却怎么也找不到？或者找到了，又不知道该怎么用？这篇文章来自产品设计领域的资深人士，他讨论的正是这类让人头疼的体验问题。作者通过一场访谈的形式，带出用户在面对复杂产品时的真实困惑，以及设计者应该如何从用户的角度去审视自己的作品。
文章的核心视角是“设计不是把功能堆上去，而是让用户自然走完每一步”。它提醒我们，好的产品体验应该像顺畅的对话，而不是一本难懂的说明书。读者可以带走的一个判断是：下次当你觉得某个产品难用时，不妨先停下来想想，是用户不够聪明，还是设计者没有把路铺平。这个简单的反思，往往能帮你找到问题的真正根源。
当你在设计一个社交产品时，最头疼的问题可能是：用户越来越多，但为什么感觉不到产品变得更好用？或者，你花了很多钱做推广，用户来了又走，到底哪里出了问题？这篇文章就是来解决这个问题的，它提出了一套衡量网络效应的具体方法。网络效应可以简单理解为：用的人越多，每个用户得到的价值就越大，比如微信，好友越多越离不开。
文章的核心视角是把网络效应拆成获取、参与和经济三个层面，每个层面都有对应的指标，比如用新增用户成本看获取效率，用活跃度看参与深度，用营收看经济价值。读者可以带走的一个判断是：不要只盯着用户总数，而要分别监控这三个层面的指标，才能找到产品增长的真正瓶颈，并针对性地优化。
想象一下，你让AI帮你订机票，它不仅要理解你说的话，还要自己上网查航班、比较价格、完成支付，甚至处理意外情况。这篇文章讲的就是如何让AI做到这些，也就是构建自主智能体。自主智能体可以理解为能自己规划步骤、调用工具、完成复杂任务的AI系统，而不只是简单对话。
文章的核心视角是把智能体拆解为规划、记忆、工具使用三个关键模块，并讨论了每个模块的设计思路和挑战。读者可以带走的一个判断是：当前AI智能体还远不完美，主要受限于长期记忆和工具调用的可靠性，但理解这些模块是设计更好AI产品的基础。
当你在开发AI应用时，可能会纠结该用哪个大模型，因为不同的模型在性能、价格、速度上差异很大。这篇文章是关于DeepSeek V4 Pro这个新模型的使用体验，作者在OpenRouter平台上进行了测试。OpenRouter是一个可以统一调用多种AI模型的服务平台。
文章的核心视角是从实际使用出发，评估这个模型的性能、成本以及与竞争对手的对比。读者可以带走的一个判断是：DeepSeek V4 Pro在特定任务上表现出色，且价格有竞争力，但在选择时仍需根据具体场景和需求权衡。
如果你在关注AI的发展，可能会听到很多关于大语言模型（简称LLM，就是像ChatGPT那样能理解和生成文字的人工智能）的新闻，但也会困惑：这些模型还有哪些做不到的事？这篇文章就是来梳理这些问题的，它列出了当前LLM研究中尚未解决的挑战。
文章的核心视角是从研究和工程实践出发，指出包括模型评估、数据质量、安全对齐、成本控制等多个方面的难题。读者可以带走的一个判断是：尽管LLM已经很强，但离真正可靠和智能还有距离，未来的进步需要解决这些开放性问题，而这正是创业和创新的机会所在。
你可能会奇怪，为什么有些人宁愿在体验很差的平台上发内容，也不去用功能更好的新平台？比如，一个视频平台画质差、广告多，但用户还是留下来了。这篇文章就是来解答这个现象的，它探讨了人们选择平台的原因。
文章的核心视角是认为，平台的价值不仅在于功能，更在于网络效应和用户习惯，人们会选择那个“大多数朋友都在”的地方。读者可以带走的一个判断是：做增长时，与其追求完美功能，不如先聚焦于如何让早期用户获得社交价值，这样才可能形成迁移的吸引力。
当你在社交媒体上看到一个品牌因为某个争议被抵制，或是某个创作者因为旧言论被翻出而道歉，你可能会觉得这是网络暴力，但也许它更像一个市场机制。这篇文章用《疾速追杀》电影里杀手组织的运作规则来类比，说明“取消文化”不是情绪化的乱象，而是一套维护信任和声誉的经济系统。
作者把注意力当作一种稀缺资源，把声誉当作可交易的资产，解释了为什么平台和用户会主动参与“封杀”。读完你会得到一个判断：与其争论谁对谁错，不如看清声誉机制如何影响产品设计和平台治理，对做社区或内容产品的人尤其有启发。
当你想推动团队重视用户研究，却总被“没时间”“没预算”拒绝时，问题可能不在研究本身，而在你如何提问。这篇文章提出两个非常简单的问题，帮你把研究价值翻译成业务语言，让决策者无法忽视。
核心视角是：用户研究不是证明自己有用的活动，而是降低决策风险的投资。你不需要学会复杂的推销话术，只需要问对两个问题，就能让老板和同事主动来找你。读完你会带走一个判断：与其抱怨不被重视，不如改变提问方式，让研究直接对接业务目标。
当你在纸上随手画一个草图，然后想把它变成可交互的界面，通常需要重新用代码实现一遍，这个过程很麻烦。Inkbase 尝试让手绘和编程直接结合，让你在画布上写写画画就能定义逻辑，比如画一个按钮然后指定它点击后做什么。
这篇文章介绍了一种“可编程墨水”的思路，把自由书写和规则表达融合在一起。对于做创造工具或关注人机交互的人来说，这是一个值得关注的方向。读完你会得到一个判断：未来创造工具的方向不是让用户适应代码，而是让代码适应人的表达习惯，手绘可能成为新的编程入口。
当你创业做了一款产品，却不确定用户是否真的需要它，你可能陷入“自我感觉良好”的陷阱。Gusto 这家公司分享了自己找到产品市场契合（即产品正好满足真实需求）的过程，强调不是靠运气，而是靠持续的客户倾听和快速调整。
核心视角是：产品市场契合不是一次性事件，而是一个持续迭代的过程。他们用具体的例子说明如何从客户反馈中提炼需求，并调整发布节奏。读完你会带走一个判断：与其追求完美的初始版本，不如尽早发布，用真实反馈来校准方向，这才是找到契合的可靠路径。
当你发现同样的工具，有人觉得效率提升，有人觉得浪费时间，你可能以为是个体差异，但作者认为这是产品设计中的主观性问题。他讨论为什么生产力（即完成工作的效率）无法被客观衡量，因为每个人的工作方式、习惯和喜好都不同。
这篇文章从一个产品设计者的视角，反思那些追求“客观效率”的工具为何常常失败。核心判断是：好的生产力工具应该尊重用户的个人节奏，而不是强制统一流程。读完你会带走一个观点：设计产品时，与其追求普适的“最佳实践”，不如提供灵活的选项，让用户自己定义什么是对他们有效的生产力。
当你的产品用户增长放缓，或者竞争对手通过补贴抢走用户时，你可能会怀疑网络效应是不是失效了。这篇文章讨论的就是网络效应如何变化、衰减甚至反转，帮助你看清增长背后的真实动力。
文章从经典的网络效应理论出发，结合实例分析其动态性，并提出一个关键判断：网络效应不是永久的，需要持续维护和适应环境变化。读者可以带走一个观点：不要迷信网络效应，要定期评估它是否还在为你服务。
当你使用聊天机器人时，它可能会一本正经地编造事实，比如给出不存在的论文或错误的历史事件。这就是大语言模型的外在幻觉。这篇文章深入探讨了幻觉的类型、原因和检测方法。
作者从技术角度剖析幻觉产生的机制，并介绍了一些缓解策略。读者可以带走一个判断：外在幻觉难以完全消除，但可以通过检索增强生成等技术显著降低，设计产品时应优先考虑可验证的场景。
如果你想搭建一个生成式AI平台，比如做一个文本生成或图像生成的服务，你可能会困惑需要哪些组件、如何设计架构。这篇文章提供了一个从零开始的平台搭建指南。
作者基于自身经验，梳理了平台的关键模块，如模型选择、数据管理、评估和部署。读者可以带走一个观点：平台的核心不是模型本身，而是围绕模型构建的工程系统，包括数据管道和评估反馈机制。
想象一下，你把一群素不相识的男孩送到一个夏令营，让他们分成两队竞争，结果他们很快就彼此敌视，甚至放火打架。这不是电影情节，而是上世纪五十年代一个著名的心理学实验。文章就从这场实验讲起，带你理解为什么人们会轻易形成对立，以及这种对立如何被刻意制造出来。
文章的核心视角是借用这个经典实验，来反思今天人工智能产品和社会媒体如何通过推荐算法和分组机制，无意中放大了人与人之间的隔阂。你可以带走的一个判断是：很多看似自然的分歧，其实是环境设计的结果，理解这一点，有助于你在设计或使用产品时，更清醒地看待那些被激化的对立情绪。
在软件开发中，当AI工具能自动生成代码时，程序员可能会感到迷茫：我的价值在哪里？这篇文章介绍了一种新的角色，指挥开发者，他们负责编排AI和传统代码的协作。
文章描述了指挥开发者的工作方式，比如如何编写提示词、审查AI输出并整合到系统中。读者可以带走一个观点：未来的程序员需要从写每一行代码转向指挥AI，核心技能是理解和评估AI生成的内容。
当你在社交平台上看到朋友分享一首冷门歌曲，或同事转发一篇行业报告，你可能会好奇：为什么这些内容会出现在我的时间线上？这篇文章探讨的正是社交网络如何通过我们关注的人来定义我们，以及这种机制如何影响产品设计。
作者认为，社交产品的核心不是内容本身，而是人与人之间的连接和身份认同。他提出一个判断：在设计推荐或信息流时，与其追求算法精准，不如思考如何让用户通过内容表达自己是谁。读者可以带走一个视角：社交产品的成功往往取决于能否让用户感到“被看见”。
想象你正在使用一款新软件，界面功能繁多，但你只想完成一个简单任务，却找不到入口。这种挫败感正是产品过度复杂的体现。这篇文章讨论的是为什么许多产品会变得复杂，以及如何通过保持简单来提升用户体验。
作者认为，复杂性往往来自内部团队的需求，而非用户的实际需要。他们提出一个原则：每个功能都应该有明确的理由，否则就应砍掉。读者可以带走一个判断：在决策时，简单不是偷懒，而是对用户时间的尊重。
当你走进一座陌生的城市，如果街道标识清晰、公共空间舒适，你会感到放松；反之，如果处处需要猜测，你会焦虑。这篇文章从维也纳的城市设计出发，探讨如何将这种“友好”原则应用到产品设计中，让用户感到被欢迎。
作者认为，产品的“亲和力”在于减少用户的认知负担，比如提供清晰的引导和及时的反馈。她提出一个视角：设计不仅要解决问题，还要让人感到安心。读者可以带走一个观点：好的设计应该像维也纳的咖啡馆，让人一进门就想坐下。
近年来，许多公司开始追求“定制软件”，希望每个功能都完全贴合自己的需求。但作者质疑这种趋势，认为定制不仅成本高昂，而且往往带来维护难题。他用自己公司的经验说明，通用软件常常已经足够好。
作者的核心观点是：定制软件可能让你短期内感到独特，但长期会陷入复杂性和依赖的泥潭。他建议优先使用成熟的标准工具，只在必要时定制。读者可以带走一个判断：在“独特”和“可靠”之间，多数时候应该选择后者。
当你在设计一个网站时，可能只关注颜色是否好看，但有没有想过色盲用户可能无法区分红色和绿色？这篇文章来自支付公司Stripe，讨论如何构建一个既美观又对所有人可用的颜色系统。
作者介绍了他们如何通过定义颜色角色和对比度标准，让设计师在满足品牌调性的同时，确保可读性。他们强调，无障碍不是附加项，而是工程的一部分。读者可以带走一个方法：用工具检查颜色对比度，并建立一套可复用的颜色变量。
当市场团队用广告点击量衡量成功，而产品团队只看功能使用率时，两家经常吵架，用户却觉得被忽视。文章指出，问题在于大家盯着自己的指标，忘了用户真实的行为轨迹。
核心视角是建议用用户行为数据作为共同语言，把营销和产品目标对齐。读者可以带走一个判断：与其争论哪个指标重要，不如先定义哪些用户行为真正代表价值，再让两个团队一起优化它。
你在笔记软件里整理资料，想把零散想法变成表格或数据库，却发现手动输入太麻烦，自动识别又常出错。文章探讨如何用“块”这种界面元素，让用户一步步把非结构化内容转成结构化数据，而不是依赖复杂的表单。
核心视角是设计上的渐进式转化，让用户自然地从自由书写过渡到有序记录。读者可以带走一个判断：好的工具不强迫用户一开始就分类，而是提供轻量的路径，让数据整理变成顺手的事。
你关注技术博客，但发现很多文章要么太浅，要么全是术语，很难理解作者的真实思考过程。这篇文章是作者开启一个新专栏的引言，打算记录一位虚构人物“Rachel”在软件行业中的见闻和反思。
核心视角是用叙事方式探讨技术决策背后的权衡，比如成本、风险和人。读者可以带走一个判断：技术文章不一定非要讲代码，讲清楚“为什么这样选”往往更有价值，尤其当涉及人工智能这类快速变化的领域时。
你收到一堆生日祝福，却觉得没人真正懂你；产品收集了大量用户数据，却仍然推荐你不想要的东西。文章从心理学角度提出，被爱的前提是被了解，而很多互动只停留在表面。
核心视角是区分“知道”和“理解”，强调深度倾听比数据收集更重要。读者可以带走一个判断：无论是人际还是产品设计，真正的连接来自对他人独特需求的洞察，而非泛泛的关心或标签化。
你依赖某个在线工具来测试人工智能模型，突然官方宣布它要下线，你的工作流程被打断，数据也可能丢失。文章讨论了这个工具退役的影响，以及开发者如何应对平台变动。
核心视角是提醒人们不要过度依赖单一服务，尤其是快速迭代的AI领域。读者可以带走一个判断：选择工具时，要预留迁移路径，关注社区支持和开源替代品，这样才能在平台变化时保持灵活。
设计师在 Dribbble 等平台上看到大量精美界面，忍不住想把自己产品也做得一样炫酷，却忘了这些图往往只展示表面美感。文章指出这种追求视觉完美而忽视真实用户需求的倾向，会让团队陷入表面功夫的陷阱。
核心视角是区分设计作品与设计解决方案，强调设计应服务于可用性和业务目标。读者可以带走一个判断：不要被漂亮效果图迷惑，先验证问题是否真实存在，再谈视觉呈现。
想象你打开一个视频应用，首页推荐总是不合口味，你划走又点开，系统却像没记住你的偏好。这篇文章想解释的正是：为什么有些产品越用越懂你，而另一些却始终笨拙。作者从信息论的角度切入，把产品使用过程中产生的数据、算法和用户反馈看作一种不断积累的“信息”，这些信息像种子一样生长，最终塑造出更聪明的服务。
核心视角是：产品的智能不来自算法本身，而来自用户与系统互动时留下的痕迹，这些痕迹被整理、反馈、再投入，形成循环。你可以带走一个判断：如果一个产品设计得让用户更愿意留下高质量行为数据，它的长期竞争力会更强，因为数据会像复利一样增值，而对手很难复制这种积累过程。
很多团队以为建好内容模型，比如定义文章标题、正文、标签等字段，就等于有了设计系统。但实际中，内容模型只解决数据结构问题，而设计系统要解决视觉和交互一致性，两者常被混淆导致协作混乱。
核心视角是明确内容模型与设计系统的边界，强调内容策略需要与设计流程紧密配合。读者可以带走一个判断：在搭建产品时，先分清内容结构和视觉规范各自的职责，才能避免返工和团队摩擦。
你在电脑上整理想法时，常常觉得鼠标键盘操作打断思路，比如拖拽卡片、调整大小，这些动作比思考本身更耗神。文章介绍了一款名为 Capstone 的平板原型，尝试用触摸和手写笔让卡片操作更自然，减少创作过程中的认知负担。
核心视角是关注工具如何支持思考流，而不是单纯追求功能强大。读者可以带走一个判断：好的创作工具应该让交互尽量隐形，让用户专注于内容本身，而不是被操作细节干扰。
当你拿到一个创业公司的工作机会，对方可能给你股票期权而不是高现金工资，这时你会纠结：是选稳定现金还是赌未来升值？文章用具体数据和常见情况分析，指出很多人在低估期权风险、高估潜在收益，导致做出不利于财务安全的决定。
核心视角是从概率和机会成本角度比较期权与现金，强调大多数创业公司期权最终一文不值。读者可以带走一个判断：除非你对公司前景有极高确信度，否则优先考虑现金收入，避免把生活押在不确定的期权上。
当你在手机或电脑上打开一个熟悉的软件，却突然发现界面换了模样，按钮移了位置，功能藏进了新菜单，你是不是会感到一阵慌乱，甚至有点恼火？这篇文章讨论的正是这种让人头疼的“更新”。作者认为，很多产品团队热衷于推出新的界面和功能，却很少停下来想一想：这个“新”到底是为了用户好，还是只是为了显得自己有在做事？
文章的核心视角是“时机”和“必要性”。它提醒我们，好的改变应该解决真实的问题，而不是制造新的困惑。读者可以带走一个简单的判断标准：如果一次更新不能明显改善体验，反而让用户需要重新学习，那它很可能就是多余的。下次再看到软件弹窗提示“全新改版”，不妨先问问自己，这个新东西真的让我用得更顺手了吗？
创业公司发现产品没人用，或者用户用了但留不住，这时常被建议“再坚持一下”或“换个方向”。但到底该坚持还是转向，很多人凭感觉决定，结果浪费了几个月甚至更久。这篇文章就是在帮创业者回答这个难题：什么时候该调整产品，什么时候该换市场，以及怎么判断自己离“产品市场匹配”还有多远。
文章的核心视角是把转向当成一个系统的诊断过程，而不是一次赌博。它提出要先找到问题的根源，比如是需求不真实、解决方案不对，还是用户群体选错了，再决定小步调整还是彻底换方向。读者可以带走的一个判断是：转向不是失败，而是用更快更便宜的方式验证假设，关键是用数据和用户反馈来指导每一步，而不是靠直觉硬撑。
创业者在决定公司注册地时，通常只想到税收、房租和通勤，却忽略了“在哪里招聘”这个更关键的问题。文章用具体场景说明：同样一笔融资，放在硅谷和放在中部小城，能招到的人才类型、质量和速度完全不同，进而影响产品迭代和融资节奏。
核心视角是“人才网络效应”：一个地点积累的工程师、设计师和销售互相推荐，会形成滚雪球式的招聘优势。读者可以带走一个判断：选择创业地点，本质是选择人才密度的起点，而不是办公成本。早期团队宁可租金贵一点，也要选人才网络更密的地方，因为速度决定了生死。
过去几年，很多人觉得只要搭一个平台，把买家和卖家拉进来，生意就能自己转起来。但如今这套逻辑越来越不灵了：流量变贵，用户耐心变短，竞争对手也越来越多。这篇文章就是在讲这个变化，提醒那些做平台生意的人，不能再靠老办法吃老本了。
作者从自己多年做平台增长的经验出发，提出平台变难的根本原因是供给和需求两端的获取成本都在上升。他给出的核心判断是：平台必须从单纯引流转向深耕单侧体验，比如先服务好卖家，让他们主动带来买家。读者可以带走一个简单结论：别再幻想平台会自动增长，要主动选择一个侧重点，把它做到极致。
当一场野火吞噬社区，普通人的求助往往淹没在官僚流程里。这篇文章是写给加州州长纽森的一封公开信，作者以公民身份为富兰克林火灾的受害者发声，呼吁政府真正关注个体困境，而不是只盯着统计数据。
核心视角是把公共事件拉回具体的人：一个名字、一个家庭、一段被烧毁的生活。读者可以带走一个判断，灾难救助的起点不是宏大政策，而是对具体苦难的回应速度。作者用直接、诚恳的语调示范了普通公民如何向权力层表达诉求，这种表达方式本身比等待救济更有力量。
很多公司都会说，我们很重视结果，但真正做产品的人都知道，这句话说起来容易，做起来却特别难。你每天打开电脑，邮箱里塞满了各种请求，有人要加个按钮，有人要改个颜色，有人要修个 bug，还有人要开发一个全新的功能。如果每一件事都答应，团队很快就会淹没在无穷无尽的小任务里，看起来忙忙碌碌，却说不清到底给用户带来了什么改变。Intercom 这家做客服和沟通软件的公司，也遇到过同样的问题，他们干脆把“交付结果”写进了自己的产品原则里，还专门写了一篇文章来解释他们是怎么想、怎么做的。这篇文章不是教你什么神奇的方法，而是讲了一个很朴素的道理，做产品不是做任务，而是做改变，你要先想清楚，用户用了你的东西之后，生活里到底发生了什么不一样。
文章里讲了一个例子，说他们团队在讨论要不要做某个功能的时候，不会先问“这个功能技术上难不难”，而是会先问“这个功能能让用户完成什么以前完不成的事”。听起来很简单，但实际操作起来，你会发现这个问题的力量非常大。比如用户说“我想要一个导出报表的功能”，如果你只听到“导出报表”这四个字，你可能就去做一个按钮，把数据变成 Excel 文件。但如果你去想“用户为什么要导出报表”，你可能会发现，他其实是想给老板汇报工作，或者想分析一下客户流失的原因。那么你要做的可能就不是一个简单的导出按钮，而是一个能自动生成分析图表的工具，甚至是一个能定时把报告发到邮箱的功能。你看，同样一个需求，出发点不同，做出来的东西就完全不同。文章里管这种思考方式叫“从结果倒推”，就是先想结果，再想产品，而不是先想产品，再想结果。
还有一个特别有意思的点，就是他们怎么在团队里统一“结果”这个概念。因为每个人对“结果”的理解可能都不一样，销售觉得结果是签单，客服觉得结果是解决用户问题，工程师觉得结果是代码上线。为了避免大家各说各话，他们会在项目开始的时候，用一个很短的句子写下“当用户使用了这个功能之后，他会得到什么好处”。这句话必须具体到能让人一眼就看懂，比如“用户可以在三分钟内完成退款申请”，而不是“提升用户满意度”。因为“满意度”太模糊了，你没法验证，而“三分钟完成退款”是可以被测试的。文章里还强调，这个“结果”不是写完了就完了，它要像一个指南针一样，在项目进行的过程中不断拿出来对照。如果做着做着发现，某个功能做出来并不能帮助用户达成那个结果，那这个功能就应该被砍掉，哪怕它已经做了一半。这需要很大的勇气，因为砍掉一个半成品意味着前期的投入都白费了，但如果不砍，最后做出来的东西可能只是给用户添乱。
这篇文章最打动我的地方，是它没有把“交付结果”当成一个口号，而是把它落实到了非常具体的日常动作里。比如他们会在写代码之前，先写一份“结果说明书”，里面不写技术细节，只写用户会经历什么。然后让整个团队，包括设计师、工程师、产品经理，都来读这份说明书，大家想象自己就是那个用户，按照说明书的步骤走一遍，看看会不会卡住。这个过程叫“纸上原型测试”，就是不用真的做出软件，用纸和笔画一画，就能发现很多问题。这样做的好处是，在写第一行代码之前，就已经把很多错误的想法过滤掉了。文章里还有一个词叫“结果指标”，就是你用什么数字来判断自己有没有达成结果。比如你的结果是“用户能更快地找到客服”，那么你的指标可能就是“用户从打开页面到发起对话的平均时间”，如果这个时间变短了，就说明你做得对，如果没变短，那就要回头看看哪里出了问题。
读完这篇文章，我最大的感受是，做产品其实很像种树，你不能只想着今天要浇多少水，而是要想着这棵树明年会长成什么样子。如果你每天只盯着浇水这个动作，可能树没长大，你却累得半死。但如果你心里有那棵树的画面，你就会知道什么时候该浇水，什么时候该施肥，什么时候该剪枝。Intercom 说的“交付结果”，其实就是让每个做产品的人，心里始终有那棵树的画面。它不是一种技巧，而是一种思考习惯，需要反复练习。下次你看到某个软件更新了，你可以试着想一想，这个新功能到底想帮用户完成什么结果，如果你能一眼看出来，那这个产品团队大概就是在认真做结果，如果他们只是加了一堆花哨的按钮，那你可能就要怀疑，他们是不是只是在做任务了。
你有没有想过，在互联网上，你是谁这个问题，其实没有一个特别好的答案。我们通常用账号和密码来证明自己，但账号密码只能证明你控制着某个手机号或邮箱，并不能证明你是一个值得信任的人。比如你在网上买东西，卖家怎么知道你不会收到货之后说没收到，然后申请退款呢？反过来，你怎么知道卖家不会收了钱就消失呢？现在平台用评分系统来解决这个问题，比如淘宝的信用分，或者 Uber 的乘客评分。但评分系统有一个很大的问题，就是它把复杂的人际信任简化成了一个冷冰冰的数字。你可能因为一次误会就得到差评，而且这个差评会一直跟着你，让你在很多地方都寸步难行。Ink & Switch 这家研究机构，他们一直在思考数字工具和人的关系，他们提出了一种叫 Backchannel 的想法，就是一种基于关系的数字身份系统。这个想法很不一样，它不试图给每个人一个统一的分数，而是让信任像现实中一样，通过人和人之间的交往慢慢建立起来。
文章里用一个很生动的例子来解释这个想法，想象你是一个新搬来的邻居，你第一次去社区的小店买东西，店主不认识你，他可能会有点警惕，但如果你带着你朋友写的推荐信，或者你朋友亲自带你过去，店主就会放心很多。Backchannel 想做的，就是把这个“朋友推荐”的过程搬到网上。它不是让一个中央机构来给你发证，而是让和你打过交道的人来为你背书。比如你在网上租房子，房东不认识你，但你可以请求你之前的房东，或者你的同事，为你写一份担保，证明你是一个按时交租、爱惜房子的人。这些担保不是简单的“好评”，而是有具体内容和背景的，比如“我认识他三年，他从来没有拖欠过房租，而且走的时候把房子打扫得很干净”。这样的信息比一个五星好评要丰富得多，也更能帮助陌生人判断你是否值得信任。
那么这个系统是怎么在技术上实现的呢？文章里讲了一些细节，但我们可以用日常的语言来理解。它有点像你在现实世界里有一串钥匙，每把钥匙对应一个你认识的人，你可以选择在特定的场合出示某把钥匙，而不是把所有钥匙都挂在腰上给人看。Backchannel 里，你的身份不是由一个全球通用的 ID 决定的，而是由你和他人的关系构成的。你可以有很多个“身份”，比如你在工作群里是一个身份，在家庭群里是另一个身份，在游戏社区里又是一个身份。这些身份之间是有联系的，但你可以控制它们如何被展示。比如你不想让你的游戏队友知道你的真实姓名，你就可以只展示你的游戏成就和游戏好友的背书，而不必透露其他信息。这有点像我们平时用微信，你可以设置朋友圈分组，有些内容只给特定的人看。但 Backchannel 更进一步，它让“谁认识你”这件事本身也变成了一种可验证的凭证。
文章还谈到了隐私和安全的问题，这是大家最担心的。如果一个系统存储了那么多关于人际关系的信息，那万一被黑客攻击了怎么办？或者被政府监控了怎么办？Backchannel 的设计者想到了这些问题，所以他们采用了一种叫“分布式”的技术，就是信息不存放在一个中央服务器上，而是分散在每个人的设备里。就像你把照片存在自己的手机里，而不是全部传到某个云盘上。这样，即使某个人的设备被入侵，黑客也只能看到那一个人的部分信息，而看不到整个网络。另外，系统里还用了加密技术，就是让信息变成一堆乱码，只有拥有密钥的人才能解读。你可以在不泄露具体内容的情况下，向别人证明你拥有某个人的担保，就像你可以在不告诉别人你银行卡密码的情况下，证明你有足够的钱支付一笔订单。这些技术听起来很复杂，但它们的核心目的很简单，就是让你在享受信任带来的便利的同时，还能保护自己的隐私。
这篇文章让我想到，我们现在的网络世界，其实很像一个巨大的匿名市场，大家互相不认识，只能靠平台来担保，所以平台就有了巨大的权力，它可以决定谁可以进来，谁可以被踢出去。而 Backchannel 这样的系统，是想把这种权力交还给用户自己，让信任重新回到人与人之间。当然，这个想法还处在研究阶段，离真正落地还有很长的路要走，但它给了我们一个很美好的愿景，就是未来的互联网，也许可以像一个真正的社区，你认识你的邻居，你的邻居也认识你，大家互相帮助，互相信任。读完这篇文章，我最大的收获是，数字身份不是一个技术问题，而是一个关于我们如何与他人共处的问题。下次你在网上给一个陌生人点赞，或者因为一个差评而生气的时候，你可以想一想，是不是有更好的方式，让我们在网络世界里，也能像在现实世界里一样，用真诚和关系来建立信任。
你有没有过这样的感觉，打开手机想查一个东西，结果半小时后发现自己在一个完全无关的页面里，甚至忘了最初想做什么。我们每天被无数弹窗、通知、推荐和自动播放的视频包围，这些设计都在拼命争夺我们的注意力。Frank Chimero 的这篇《The Good Room》就是在谈这件事，但他没有直接骂科技公司，而是用一个很日常的比喻，让我们重新思考网络空间应该是什么样的。
他把我们上网的地方比作房间。有些网站和软件像杂乱的地下室，堆满杂物，灯光刺眼，你只想赶紧离开。有些像机场候机厅，功能齐全但冷冰冰，没有任何让你想多待一会儿的理由。而好的房间，比如你朋友家客厅，布置得舒服，灯光温暖，椅子合适，你愿意在那里放松地聊天、看书。Chimero 说，我们的数字世界太缺少这种好房间了。大多数产品设计都在追求让用户停留更久、点击更多，而不是让用户感到舒适和被尊重。
文章里提到一个很具体的例子，他喜欢的一个网站，设计非常简单，只有文字和大量留白，没有广告，没有弹窗，没有自动播放的视频。他说在那里阅读就像坐在一个安静的书房里，光线从窗户洒进来，你能专注地看完一整篇文章。而对比之下，很多新闻网站打开就是满屏的广告，甚至文章看到一半还会弹出订阅提示，你的阅读不断被打断，就像在一个嘈杂的房间里，有人不停在你耳边推销东西。Chimero 认为，这不是技术问题，而是设计者选择的问题。他们选择了用打扰换取点击率，用喧闹换取广告收入。
他进一步提出，好的数字环境应该像好的实体房间一样，有明确的功能，有让人安心的氛围，还要尊重使用者的自主性。比如，一个好的阅读应用不会强制你登录，不会在你翻页时插入视频，它会记住你上次读到哪，但不会用推送轰炸你。Chimero 强调，设计者应该问自己，用户在这个空间里是感到更焦虑还是更平静，是更容易集中还是更容易分心。他把这种设计称为一种道德选择，因为我们的注意力是我们最宝贵的资源，而好的设计应该保护它，而不是剥削它。
读完这篇文章，你会开始留意那些让你感到舒服的应用和网站，也会注意到那些让你烦躁的界面。Chimero 没有给出具体的解决方案，但他给了我们一个判断标准，就像走进一个房间，你能立刻感觉到自己是受欢迎的客人，还是被当作待宰的流量。我们或许无法改变所有产品的设计，但至少可以选择把自己的时间花在那些好房间里，并且要求更多产品像对待客人一样对待我们。这就是他说的好房间的意义，它不只是一个界面，而是一种尊重。
很多创业者都听过一个词，叫产品市场匹配（product-market fit），意思就是你的产品刚好满足了一群人的强烈需求，他们不仅愿意用，还愿意付费，甚至主动帮你宣传。这个词听起来很玄，但 Applied Intuition 这家公司把这件事做到了极致，而他们的故事对任何想做出人们真正需要的产品的人都有启发。Applied Intuition 做的是自动驾驶汽车模拟软件，听起来非常技术，但他们的成长路径其实很朴素，就是不断听客户说话，然后把听到的变成产品。
这家公司的创始人一开始就意识到，自动驾驶汽车公司需要在一个虚拟世界里反复测试他们的算法，因为真实道路测试太贵也太危险。所以他们做了模拟软件，让工程师可以在电脑上模拟各种驾驶场景，比如雨天、行人突然冲出、红灯抢行等等。但最初他们并不知道客户最需要什么，于是他们做了一个很笨但很有效的事情，他们亲自去客户那里，坐在工程师旁边，看他们怎么用软件，问他们哪里卡住了，哪里觉得烦。这种深入现场的做法，让他们发现客户真正需要的不是更多炫酷功能，而是更快的加载速度，更稳定的运行，以及能方便地导入自己的数据。
随着客户越来越多，他们面临一个选择，是继续把单一产品做好，还是扩展到其他相关工具。很多公司会贪多，但 Applied Intuition 选择了一条更稳的路，他们围绕客户的工作流程，逐步增加新的工具，比如用于管理测试数据的平台，用于分析模拟结果的可视化工具。每一个新工具都来自一个真实客户的真实痛点，而不是凭空想象。比如有个客户说，他们每天要手动整理几百份模拟报告，非常浪费时间，于是 Applied Intuition 就做了一个自动汇总报告的工具。这样，客户越来越依赖他们的产品套件，因为每个工具都解决一个具体问题。
他们的扩张策略也很有意思，他们没有一开始就瞄准所有汽车公司，而是先服务几家最前沿的自动驾驶初创公司，这些公司需求最迫切，也最愿意尝试新工具。通过这些早期客户的反馈，他们不断打磨产品，然后才向更传统的大型汽车制造商扩展。这些大公司通常很谨慎，但看到那些初创公司已经在使用，而且效果不错，他们也愿意跟进。这种从边缘到主流的路径，让 Applied Intuition 避免了在早期就陷入与大客户的漫长谈判，而是先用小客户验证产品，再逐步扩大市场。
文章里还提到一个关键点，就是他们如何衡量产品市场匹配。他们不只是看用户数量或收入，而是看客户是否真的离不开他们的产品。比如，他们注意到客户在续约时毫不犹豫，甚至主动要求增加付费功能，这就是匹配的信号。他们还发现，客户会自发地在行业会议上推荐他们的产品，这比任何广告都有效。这些信号帮助他们判断什么时候可以加大投入，什么时候应该继续倾听。
Applied Intuition 的故事告诉我们，产品市场匹配不是一个神秘的黑箱，而是一个不断倾听、迭代和验证的过程。他们成功的关键，不是因为他们有天才的远见，而是因为他们愿意像工匠一样，坐在客户旁边，把每一个细节做好。对于任何做产品的人来说，这篇文章都是一个提醒，真正的好产品不是设计出来的，而是和用户一起长出来的。当你看到用户因为你的产品而节省了时间，解决了问题，那种满足感就是产品市场匹配最好的证明。
想象一下，你刚被提拔为一家公司的产品负责人，头衔很响亮，叫首席产品官（Chief Product Officer）。你管着所有产品经理，大家等着你定方向，老板等着你出成绩。但真正坐到这个位置的第一年，你可能会发现一件事，你根本不知道这份工作到底是什么。这不是谦虚，而是这个岗位本身就很模糊。它不像销售有明确的数字，也不像工程师有明确的功能要写。它更像一个需要你自己定义形状的空盒子。Casey Winters 写这篇文章，就是想讲讲他第一年当首席产品官时，是怎么搞清楚这个盒子的。他没有直接给答案，而是先讲了一个更基本的问题，这份工作到底要我做什么。
他发现自己得先回答一个更原始的问题，我到底该把时间花在哪里。因为如果这个问题不解决，你每天都会被各种会议、邮件、突发问题淹没，一年下来好像很忙，但公司没有任何变化。他说自己第一年最大的收获，不是做了什么大事，而是学会判断什么事不该做。这听起来很反直觉，但仔细想想，一个产品负责人如果什么都想抓，团队就会失去焦点，每个人都在做自己认为重要的事，结果就是产品变得四不像。他提到一个关键动作，叫做产品组合管理（product portfolio management）。这个词听起来很专业，其实意思很简单，就像你管理一篮子投资，有的项目是高风险高回报，有的是稳定现金流，你不能把全部钱都押在一个地方。
产品也一样，有些功能是修修补补，让现有用户更满意，有些功能是冒险尝试，可能带来新用户，也可能失败。作为负责人，你得决定这个篮子里放什么，放多少，什么时候调整。他举了例子，比如他所在的公司当时有很多产品线，有的增长很快，有的已经停滞。他发现自己不能只关注增长快的那个，因为停滞的可能会拖累整体，但也不能轻易砍掉，因为可能有老用户依赖。他得一个个去了解，这些产品在用户生活里扮演什么角色，是每天必用的工具，还是偶尔想起的辅助。这个过程很花时间，但他说这是必要的，因为只有理解了每个产品的具体处境，你才能做出判断。他还讲了一个特别具体的场景，就是怎么跟其他部门打交道。
产品负责人不只是管自己团队，还要跟销售、市场、工程、数据等很多人协作。他发现很多冲突其实不是人的问题，而是目标不一致。比如销售希望快速加功能来签单，但产品希望把基础打牢。这时候你不能说谁对谁错，而是要建立一个机制，让不同部门能坐下来，把各自的顾虑摆出来，找到一个大家都能接受的节奏。他管这个叫对齐（alignment），但这个词很容易变成空话。他具体说的是，你得让每个部门的人都能回答三个问题，我们这季度最重要的目标是什么，为了这个目标我们需要产品做什么，如果产品做不到，我们有什么备选。当每个人都能回答这三个问题，冲突就会少很多。
文章里还提到一个概念，叫组织诊断（organizational diagnosis）。听起来很玄，其实就是像医生看病一样，看看团队哪里不舒服。他发现自己刚去的时候，团队士气不高，因为之前方向变来变去，大家不知道做的东西有没有用。他做的第一件事不是宣布新愿景，而是花很多时间跟每个产品经理一对一聊天，问他们最近在做什么，遇到什么困难，觉得什么最重要。这些聊天让他发现，很多问题不是能力问题，而是流程问题。比如信息不透明，决策总是从上往下压，但下面的人有很好的想法却没人听。他于是开始调整会议结构，让一线的人有机会直接汇报，而不是层层过滤。这个过程很慢，但他说这是值得的，因为信任需要时间建立。
文章里还讲到战略收缩（strategic contraction），这个词听起来很消极，但他认为是必要的。他说他第一年其实砍掉了一些项目，有些甚至是前任很看重的。这很难，因为会有人反对，但他发现，如果资源有限，你不可能同时做好所有事。他举了一个例子，有个功能做了很久，但用户使用率一直很低，团队很投入，但数据不会说谎。他决定把它停掉，把人力转到另一个更有潜力的项目上。这个决定引起了一些不满，但他用数据解释，并承诺会给团队新的机会。最后他说，第一年最重要的不是证明自己多聪明，而是学会倾听和观察。你得承认自己不知道很多东西，然后花时间去搞明白。产品负责人不是一个发号施令的角色，更像一个园丁，你得先了解土壤、水分、阳光，才能知道该种什么，不该种什么。读完这篇文章，你会带走一个判断，好的产品领导力不是从宏伟愿景开始的，而是从承认自己不知道这份工作是什么，然后愿意花一年时间去搞清楚开始的。
你有没有遇到过这种情况，身边突然好多人开始用同一个软件，比如一个聊天工具，或者一个拼车应用。你一开始没在意，后来发现不用它反而不方便了，因为你朋友都在上面，你同事也在上面。这时候你才下载，然后你发现，哇，原来这么多人都在用。这个过程其实非常神奇，它不是靠广告砸出来的，而是靠人拉人，人越多越好用，越好用人越多。Andrew Chen 的《冷启动问题》（The Cold Start Problem）这本书，就是专门研究这个现象的。他把它叫做网络效应（network effects），意思是每个新用户都会让产品对其他人更有价值。
听起来很简单，但真正难的是，一开始什么都没有的时候，怎么让第一批用户来。你不可能说，这个软件很好用，但需要一百个人同时在线才有意思。那第一个人为什么要来？这就是冷启动问题，像冬天发动一辆旧车，引擎是冷的，你得先费很大劲让它转起来。书里讲了很多真实案例，比如 Slack 这个办公聊天工具。它一开始不是面向所有公司的，而是先让几个小团队用起来。这些团队可能只有五个人，但因为他们每天都用，慢慢形成了习惯。然后这些团队里的人跳槽到别的公司，就把 Slack 带过去了。这就是一个典型的冷启动策略，先找一群小而活跃的用户，让他们成为种子，然后靠他们自然传播。
Andrew 管这个叫原子网络（atomic network），就是最小的一组用户，比如一个团队、一个班级、一个小区，他们之间联系紧密，产品对他们有明确价值。不是一开始就面向全世界的，而是先让一个原子网络转起来。这就像滚雪球，你得先捏一个小雪团，然后在地上滚，才能越滚越大。如果你直接推一大块雪，反而散架了。书里还讲了一个特别重要的概念，叫临界点（tipping point）。这个词你可能听过，就是当一个产品过了某个用户数量，增长就会变得自动起来，不需要太多推广。比如一个社交应用，当你的朋友都在上面，你不上就感觉被孤立。
但临界点不是固定的，它取决于产品类型。有些产品需要很高的密度，比如邻里社交应用，你得让一个小区里大部分人都用，才有价值。有些产品则不需要，比如一个工具类软件，你一个人用也有价值，但它的网络效应就弱一些。Andrew 说，很多产品失败，不是因为没有网络效应，而是因为没找到自己的临界点，或者一开始选错了原子网络。他举了 Tinder 的例子，这个约会应用一开始只在大学校园里推，他们去兄弟会、姐妹会，让一批学生先注册，然后因为校园里人数多，很快形成了氛围。这就是选对了原子网络，因为大学校园本身就是一个联系紧密的社区。
另一个例子是 Uber，它一开始在旧金山，先让一小批司机加入，然后保证乘客叫车能很快有车来。如果司机太少，乘客等太久就会卸载，所以 Uber 的策略是先用补贴吸引司机，确保供给充足，再吸引乘客。这就是在管理一个双向市场的冷启动，一边是司机，一边是乘客，两边都得照顾到。书里还讲了一个概念，叫防弹效果（bulletproof effect），听起来很酷，意思是当网络效应真正形成后，竞争对手很难把你拉下来。因为用户已经习惯了，而且迁移成本很高。比如你所有的聊天记录都在一个应用里，你的朋友也都在，你很难换到另一个应用，即使它功能更好。这就是网络效应的护城河。
但 Andrew 也提醒，网络效应不是永远安全的，它需要不断维护。比如产品变得臃肿，用户体验变差，或者新的技术出现，都可能让用户流失。他讲了一个例子，像 Facebook 曾经很强大，但年轻人开始觉得它不够酷，转向了 Instagram 和 Snapchat。所以网络效应也需要持续创新。整本书读下来，你会对很多产品的成败有更深的理解。为什么有些产品一夜爆红，有些却默默无闻。不是运气，而是他们是否解决了冷启动问题，是否找到了正确的原子网络，是否度过了临界点。你还会学到，当你自己想做一款有网络效应的产品时，不要一开始就想做大而全，而是找一个小的、紧密的群体，让他们先爱用，然后慢慢扩展。这就像种树，先让根扎深，才能枝繁叶茂。读完这本书，你会带着一个判断，任何有网络效应的产品，其成功都离不开对冷启动阶段的精心设计，而这个过程充满了耐心和策略，不是一蹴而就的。
我们平时用手机、用网站、用各种软件，很少会去想一个问题，为什么有些科技公司能一直做大，而有些公司就算产品做得不错，也很快就没落了。很多人第一反应是，因为产品好，或者技术厉害。但如果你去问那些做投资的人，他们会告诉你，真正让一家科技公司值钱的，往往不是它自己有多厉害，而是它能不能让用户之间互相产生联系，让用户越多，产品越好用，这就是网络效应（network effects）。
网络效应这个词听起来很专业，其实很简单。想象一下，你一个人用微信，那微信对你来说就是个发短信的工具，没什么特别。但你的朋友、家人、同事都在用微信，那微信就变成了你离不开的东西，因为你的所有社交关系都在里面。你用得越多，你的朋友越可能也来用，因为这样才能联系到你。这样一来，用的人越多，每个人得到的价值就越大，新用户也越难离开。这就是网络效应的力量。
NFX这家投资机构专门研究网络效应，他们统计了很多科技公司，发现科技公司创造的价值里，有七成是靠网络效应撑起来的。这个数字很惊人，意味着如果你创业做一家科技公司，但你的产品没有网络效应，那你可能从一开始就输在了起跑线上。为什么这么说呢？因为网络效应是一种很强大的护城河（moat），护城河这个词原本指古代城堡外面那条河，用来挡住敌人进攻的，在商业里就指一家公司用来防止竞争对手抢走自己用户的东西。有网络效应的公司，用户越多，对手就越难模仿，因为对手就算做出一样的产品，也没有那么多用户，用户过去也没意思。
举个例子，比如打车软件。你叫车的时候，希望车来得快，司机接单多。司机呢，希望乘客多，不跑空车。所以一个打车平台，如果一边的乘客少，司机就不愿意来，因为赚不到钱；如果司机少，乘客也不愿意用，因为等太久。这就是典型的双边网络效应（two-sided network effects），平台要同时吸引两种用户，让两边都满意，才能转起来。一旦转起来，用户越多，车越多，车越多，用户越多，后来者就很难追上。
但网络效应不是只有这一种。NFX还列出了很多种，比如直接网络效应，就是像微信那样，用户之间直接联系，人越多越好用；还有数据网络效应，就是用户越多，平台收集的数据越多，算法越聪明，产品越智能，比如推荐系统，你看的视频越多，它越懂你喜欢什么，别人也受益，因为整个推荐系统变得更准了。还有技术网络效应，就是大家一起用同一个标准，比如用同一个文件格式，互相之间交换资料就方便，人越多，这个标准越值钱。
不过，网络效应也不是万能的。有些公司看着有网络效应，但其实没有。比如有些社交软件，用户很多，但用户之间没有紧密联系，只是各自看内容，那这种网络效应就很弱，用户很容易就换到另一个平台。还有，网络效应也可能被技术突破打破，比如以前用固定电话的人多，电话网络效应很强，但手机出现后，移动网络取代了固定电话，因为手机更方便，大家就都换过去了。所以，网络效应不是一劳永逸的，需要不断维护和创新。
对于创业者来说，这篇文章最重要的启示是，在设计产品的时候，就要想清楚，用户之间怎么互动，怎么让用户越多产品越好用。如果一开始没有网络效应，那就要想办法创造一种，比如通过邀请机制，让老用户带新用户，或者通过分享功能，让用户的内容吸引更多人。但也要小心，有些强行设计的网络效应，比如为了拉新而给用户奖励，但用户之间没有真正联系，那奖励停了，用户就走了，这种虚假的网络效应没有用。
读完这篇文章，你会明白，为什么有些公司能垄断市场，为什么有些公司烧钱也活不下来。科技行业的游戏规则，很多时候不是看谁的技术最炫，而是看谁能建立起一个用户之间互相依赖的网络。这个网络一旦形成，就像滚雪球一样，越滚越大，别人很难插进来。所以，下次你再看到一个新产品，不妨问问自己，这个产品用的人越多，是不是真的对每个人越好？如果是，那它可能就有机会成为下一个巨头；如果不是，那它可能只是昙花一现。
如果你开一家健身房，你最头疼的事情是什么？大概就是，有些会员办了卡，但一年也不来几次，而有些会员想来，但健身房位置不够，或者课程时间不合适。这种供需不匹配，是很多实体服务行业的通病。有一家公司叫ClassPass，它想解决这个问题，它的做法是，让用户按月付费，然后可以去很多不同的健身房上课，就像一张通用的健身卡。这个想法听起来很美，但做起来却差点把公司搞垮。
ClassPass的创始人叫帕亚尔·卡达基亚（Payal Kadakia），她原本是个舞蹈爱好者，想找个地方跳舞，但发现找课特别麻烦，于是她想到做一个平台，把各种健身课程都列出来，用户可以在上面搜索、预订。一开始，她做的其实不是一个健身房通行证，而是一个课程搜索引擎，就像谷歌搜网页一样，搜健身课。但很快她发现，光搜索没用，用户搜到了课，但没法直接预订，还得去健身房自己的网站，体验很割裂。于是她转变思路，干脆让用户通过ClassPass直接预订课程，并且按月付费，可以随便去合作健身房上课。
这个模式一出来，用户增长很快，因为对用户来说，一张卡能去好多地方，很划算。但对健身房来说，却有点不舒服。因为ClassPass给健身房的费用很低，而且来的都是新用户，这些用户可能只是来尝个鲜，不会成为长期会员。健身房觉得，自己花了心思和场地，却赚不到钱，还抢走了自己的潜在客户。所以很多健身房开始抵制ClassPass，有的甚至直接取消合作。
这时候，ClassPass面临一个生死攸关的问题，两边用户都不满意，健身房觉得不赚钱，用户觉得好课程越来越少。创始人开始反思，他们最初以为，只要用户多，健身房就会愿意合作，但现实是，健身房要的是稳定的收入，而不是一堆来体验一次的散客。于是，他们调整了策略，不再盲目追求用户数量，而是开始关注用户质量。他们分析数据，发现有些用户经常来，而且会去很多不同的健身房，这些用户对健身房来说更有价值，因为他们可能会被转化成长期会员。于是，ClassPass开始给这些高价值用户更多优惠，同时提高对健身房的回报，比如增加分成比例，或者提供一些长期合作的保障。
这个转变，其实就是在寻找产品市场匹配（product-market fit）。这个词听起来很玄，其实就是你的产品正好满足了一群人的真实需求，他们愿意持续使用，并且愿意为此付费。对于ClassPass来说，它最初以为需求是“让用户方便地找到课程”，但后来发现，真正的需求是“让用户方便地尝试各种健身方式，同时让健身房获得稳定的新客户来源”。当它找到这个匹配点后，公司才开始走上正轨。
这个故事告诉我们，创业公司在早期，很容易被表面的用户增长迷惑，以为用户多就是好事。但如果你没有找到真正愿意为你付费、且能持续使用的用户群体，那增长越快，可能死得越快。ClassPass的创始人后来总结说，他们犯的最大错误，就是太早扩张，没有先在一个小市场里验证模式是否真的能让两边都满意。他们后来花了很多精力去调整，才慢慢找到了平衡。
现在，ClassPass已经成了一个很大的平台，在很多城市都有合作健身房。但它的经历提醒我们，尤其是做平台型创业的人，要时刻关注两边的需求，不能只讨好一边，否则另一边就会离开。产品市场匹配不是一个静态的点，而是需要不断调整的动态过程。你可能会经历很多次失败，但只要你能从失败中学习，不断靠近那个匹配点，就有可能成功。对于任何想创业的人来说，这个故事都值得仔细琢磨，因为它讲的不是一夜暴富的神话，而是现实的挣扎和智慧的取舍。
我们大多数人每天用电脑，但很少有人真的在指挥电脑。我们是在别人画好的格子里点来点去，比如在表格里填数字，在聊天框里发消息，在日历上安排会议。这些格子是程序员替我们想好的，他们猜我们会做什么，然后提前把路修好。可是生活里总有那么一些时刻，你需要的路没有人修过。比如你想把公司通讯录和工资表对起来，看看哪些人该涨薪，但这两个系统根本不说话。或者你想让每天下午三点的提醒，跳过节假日，只发给某个小组的人。你打开软件，翻遍菜单，找不到这个功能。你只能去求懂技术的人，或者干脆放弃。这种无力感，就是文章想解决的问题。它讲的是普通人能不能自己创造软件，而不是永远等着别人施舍功能。
文章来自一个叫墨水和开关（Ink & Switch）的研究实验室，他们专门研究人们怎么和电脑相处，这次他们把目光投向了一个老话题，叫终端用户编程（end-user programming），意思是让最终使用软件的人，而不是专业程序员，自己动手改变软件的行为。文章没有把它当成一个技术难题，而是当成一种关于自由的追求，就像一个人从租客变成房主，开始能决定自己住的地方长什么样。文章举了很多生动的例子。有一个是做数据分析的人，她每天要处理几百份报表，每份格式都略有不同。她花了好几个小时写了一个脚本，让电脑自动整理这些文件。这个脚本不是用专业编程语言写的，而是用她熟悉的表格软件里的公式和宏，像录音机一样把她的操作录下来，然后批量重放。她不是程序员，但她创造了一个属于自己的工具。
还有一个例子，是一位教师，她想给每个学生发个性化的反馈邮件，但邮件系统只允许群发同一封。她花了一个下午，用邮件软件里的模板和变量，拼出了一个能自动填入学生名字和成绩的邮件。她觉得自己像变了个魔术。这些人的共同点，是他们没有写一行传统意义上的代码，但他们确实在编程，只不过用的是更贴近自己生活的工具。文章把这些工具叫做高上限（high ceiling）的工具，意思是它们不只能做简单的事，也能支撑复杂的创造，就像一把瑞士军刀，既能开瓶盖，也能拧螺丝。但文章也坦诚地讲了为什么这条路很难走。难点不在于教人学语法，而在于让工具理解人的意图。当你在表格里写下一个公式，计算机其实不知道你想表达什么，它只是在机械地执行。如果你写错了，它不会提醒你，只会给你一个错误结果。
文章讲了一个案例，有人用表格软件算错了财务数据，因为公式里少了一个括号，结果公司损失了一笔钱。这不是工具的错，是人和机器之间的鸿沟。为了跨越这道鸿沟，文章介绍了一些有趣的尝试。比如有一种方式叫示范编程（programming by example），你直接给电脑演示你想做什么，比如把两列数据合并成一列，电脑会观察你的动作，然后猜出规则，自动帮你做剩下的。还有一种方式叫活代码（live coding），你写的每一行指令，旁边立刻显示出结果，就像你在调音量，每拧一下就能听到声音变化，这样你马上知道对不对，不用等到最后才看到错误。
文章还提到一个概念叫可重组的界面（recomposable interface），意思是软件界面本身可以像乐高积木一样拆开重拼，而不是死死焊在一起。比如你常用的那个邮件客户端，如果它的每个按钮都能拖出来，换成你想要的顺序，甚至加上别的软件的按钮，那你就拥有了一个你自己设计的工具。这些想法听起来很美好，但文章也提醒我们，它们现在还只是实验，离普通人每天用上还有距离。不过文章的乐观之处在于，它认为我们不该把编程看成少数人的特权。就像写作，不是只有作家才能写字，每个人都能写便条、写日记、写情书。编程也应该这样，它是一种表达方式，是让电脑做你想做的事的一种语言。
当普通人也能编程，他们就不再是软件的被动的用户，而是主动的创造者。这种转变的意义，不亚于当年个人电脑把计算能力从机房带到了每个人的桌上。读到这里，你会明白，文章真正关心的不是技术细节，而是权力分配。谁有权力决定软件做什么，谁就掌握了数字世界的规则。终端用户编程，就是想把这份权力还给每一个人。它不一定意味着每个人都要学会写代码，而是意味着，当我们遇到软件做不到的事，我们至少知道有路可走，而不是只能等别人来救。这或许就是文章说的计算自主权（computing autonomy），它像一种新的读写能力，在未来，不会自己调整工具的人，可能就像今天不识字的人一样，处处碰壁。
你有没有想过，你手机里那些好用的应用，是怎么被设计出来的？很多人以为，就是几个聪明人关在房间里，凭灵感画几张图，然后程序员把它们变成现实。但真正做产品的人都知道，事情远没有那么浪漫。这篇文章来自一家叫Intercom的公司，他们做的是帮助企业和客户聊天的软件，就是那种网页右下角弹出的对话窗。他们把自己怎么设计产品的过程写了出来，不是为了炫耀，而是想分享一套朴素的方法。
文章一开头就讲了一个反直觉的观点，设计不是从画图开始的，而是从理解问题开始的。他们说的理解问题，不是坐在办公室里猜，而是真的去和用户聊天，看用户怎么用他们的产品。比如他们发现，很多客户服务人员每天要同时应付好几个对话窗口，手忙脚乱，经常回错人。这个观察听起来很简单，但很多公司根本不会花时间去做。他们更愿意直接问用户，你想要什么新功能？但用户往往说不清楚，或者说的都是表面需求。Intercom的做法是，先搞清楚用户的生活是什么样的，他们在什么时间、什么地点、为什么需要这个工具。
文章里有一个例子，他们想改进一个功能，让客服人员能更快地查看客户的历史信息。他们没有直接改界面，而是先做了一堆用户访谈，发现客服人员其实最怕的是在对话中冷场，因为他们在翻资料，客户在等。这个发现让他们意识到，问题的关键不是资料好不好找，而是能不能让等待变得不那么尴尬。于是他们设计了一个小功能，让客服人员在查看资料时，可以自动发一条消息给客户，说请稍等，我正在看您之前的问题。就这么一个小小的改动，客户满意度提升了不少。你看，好的设计不是凭空想出来的，而是从人的尴尬、人的焦虑、人的不方便里长出来的。
文章还讲了一个很重要的概念，叫设计过程（design process），听起来很枯燥，但其实就是一套怎么把想法变成可靠产品的步骤。他们强调，设计不是一步到位的，而是反复迭代的。他们先画很粗糙的草图，叫线框图（wireframe），就是只有方框和线条的页面，用来测试布局，不纠结颜色和字体。然后做成可以点击的模型，叫原型（prototype），让真实用户来试用，看他们会不会迷路。他们甚至会故意做一些半成品，叫最低可行产品（minimum viable product），就是只有核心功能、其他都砍掉的东西，先放给一小部分用户用，收集反馈，再慢慢完善。这种做法的好处是，你不用等到产品做完了才发现方向错了，而是每一步都在验证。
文章里有个比喻，说设计就像在雾里开车，你只能看到前面几米的路，但只要你一直开，不断根据路况调整方向，你总能到达目的地。如果你非要等雾散了再走，可能永远也走不了。这让外行也能明白，为什么有些公司能不断推出好用的产品，而有些公司却总是做出没人要的东西，区别往往不在于谁更聪明，而在于谁更愿意放下身段，去倾听那些微小的、真实的声音。文章也提到，他们怎么组织团队来保证这种设计文化。他们让设计师、工程师和产品经理坐在一起，不是像流水线一样，设计师画完图扔给工程师，而是大家从一开始就一起讨论，工程师会提出技术上的限制，产品经理会提醒商业上的目标，设计师则负责站在用户这边。这种跨角色的合作，听起来有点理想化，但他们确实在这么做。
他们甚至鼓励设计师去写代码，虽然写得不好也没关系，目的是让设计师更理解实现的难度，避免画出工程师做不出来的东西。这让我想到，我们日常用的软件，背后其实是一群人不停地在对话、妥协、尝试。Intercom这篇文章的价值，不只是给做产品的人看的，它也让普通用户明白，一个按钮的位置、一段文案的措辞，背后都有它的道理。下次当你打开一个应用，觉得它用起来很顺手时，你可以想想，可能有一个人曾经坐在某个用户旁边，看着他皱眉头，然后回去改了一行代码。设计不是魔法，而是一种有方法的同理心。读完这篇文章，你会带走这样一个想法，任何好用的东西，都不是一次成形的，而是无数次倾听、试错和调整的结果。这大概就是Intercom想告诉我们的，设计不是画图，而是理解人。
很多团队在开产品会的时候，最常问的问题是“我们这周做了什么”。大家围在桌前，挨个报进度，说上线了哪个按钮，改了什么页面，发了哪封邮件。这些听起来都很有成果，因为事情确实发生了，东西确实做出来了。但如果你退一步想，会发现一个奇怪的地方，我们做了这么多，却很少问“这些东西到底改变了什么”。文章想说的就是这件事，我们太容易把“做了”当成“成了”，把“上线”当成“有效”。
文章里有个很关键的区分，一个是产出（output），一个是结果（outcome）。产出是你做出来的东西，比如一个功能、一个页面、一次推送。结果是你做完之后，用户身上发生的真实变化，比如更多人愿意每天打开你的应用，或者新用户注册后更愿意留下来。产出是手段，结果才是目的。但现实里，很多团队把手段当成了目的，因为产出容易衡量，结果很难衡量。你可以在看板上贴满任务卡，可以说我们发布了三个新功能，但你说不清这些功能有没有让人更愿意用你的产品。
文章举了一个很具体的例子，让我一下子明白了这个区别。假设你的产品是一个在线学习平台，你的团队花了很多时间做了一个新的课程推荐功能，推荐算法很聪明，页面也好看。如果只看产出，你完成了，很成功。但如果你问结果，你要看的是，这个功能上线后，有没有更多人完成课程，有没有更多人愿意付费。如果数字没变，那这个功能做得再好，也只是自嗨。文章提醒我们，要习惯性地问“然后呢”，每做完一件事，就追问它对用户行为产生了什么影响。
这个转变听起来简单，做起来很难，因为公司里的很多机制都在奖励产出。你的绩效可能看你上线了多少功能，你的领导可能问你进度怎么样了，你的团队可能习惯了“做完就散”。文章建议，要从一开始就定义好你想改变的用户行为，比如“让新用户在一周内添加五个好友”，然后围绕这个行为去设计、去衡量。当你把注意力从“我们做什么”转到“用户因此有什么不同”时，很多决策都会变。你会砍掉那些看起来光鲜但没人用的功能，你会花更多时间研究用户为什么离开，你会愿意调整方向，哪怕这意味着推翻已经做完的东西。
读完这篇文章，我最大的感受是，它其实在讲一种工作习惯，就是永远追问“所以呢”。下次你做完一个东西，别急着庆祝，先问问自己，它让谁的生活变好了，让谁的行为改变了。如果答不上来，那你可能只是在制造产出，而不是创造结果。
很多人以为产品设计师（product designer）的工作就是把界面画得好看，选对颜色，排好按钮。但在一家真正做产品的公司里，设计师的日常远不止这些。Intercom 是一家做客户沟通软件的公司，他们的设计师写过一篇文章，讲怎样才算有影响力的设计师。文章开头就点出一个扎心的现象，很多设计师勤勤恳恳做了一堆漂亮方案，最后却发现自己只是被当成画图的工具人。老板说需要什么就画什么，画完交出去，后面的事跟自己无关了。这样的设计师很努力，但影响力很小。
那什么叫有影响力呢。文章里举了一个很具体的场景。设计师参与一个功能的设计，不只是把界面画出来，而是要想清楚这个功能到底解决谁的什么问题。比如 Intercom 的产品里有一个收件箱，客服人员在这里处理用户消息。设计师如果只是把收件箱的列表改得好看一点，那影响有限。但如果设计师发现客服每天要花很多时间把同一条消息复制到不同地方，于是设计了一个自动关联功能，让消息自动归类到对应的用户档案里，那这个设计就直接改变了客服的工作效率。这种设计不是画图，而是解决问题。
文章强调，设计师要主动去理解业务目标（business goals），也就是公司为什么要做这个功能，赚钱还是留客，还是减少投诉。设计师不能只等产品经理（product manager）告诉自己需求，而要自己去问用户，去看数据，去参加客服的日常轮班，亲身体会那些使用产品的人有多痛。Intercom 的设计师甚至说，他们会让设计师去接听客服电话，因为只有听到真实用户的声音，才知道自己设计的界面在真实世界里是什么样。这种贴近现实的做法，让设计师做出的决定有根据，而不是拍脑袋。
有影响力的设计师还有一个特点，就是他们不满足于只做自己那一小块。文章里说，设计师要关注整个产品流程，从用户第一次听说这个产品，到注册，到使用，到付费，到遇到问题找客服，再到推荐给朋友。每一个环节都有设计的机会。如果一个设计师只盯着自己负责的那个页面，而对前后环节的问题视而不见，那他的影响力就局限在一个小格子里。反过来，如果设计师能跳出自己的格子，提出跨环节的改进建议，那他就成了团队里不可或缺的人。
文章还讲了一个很关键的转变，从输出（output）转向结果（outcome）。输出就是设计师交付了多少张设计图，多少个原型（prototype），这些是看得见摸得着的东西。但结果是指这些设计图上线后，用户行为发生了什么变化，比如用户完成注册的比例提高了，或者客服处理一条消息的时间缩短了。有影响力的设计师会用结果来证明自己的价值，而不是用工作量。他们会问自己，我做的这个设计，到底让什么指标变好了。如果回答不上来，那说明设计可能只是自嗨。
为了做到这一点，设计师需要学会沟通。文章里说，设计师不能只把设计稿丢给工程师（engineer）就完事。他们要解释为什么这样设计，背后的逻辑是什么，甚至要参与代码实现的过程，确保设计真正落地。Intercom 的设计师会和工程师坐在一起，随时讨论技术上的限制，比如这个动画效果能不能实现，那个数据能不能拿到。这种紧密合作让设计不是空中楼阁，而是能真实运行的功能。
文章里还提到一个常见的误区，就是设计师喜欢追求完美。但现实是，产品永远在迭代，不可能一步到位。有影响力的设计师懂得小步快跑，先推出一个能用的版本，收集反馈，再改进。他们不害怕犯错，因为他们知道，只要方向正确，小错误可以快速修正。这种心态让设计师敢于尝试，而不是缩在舒适区里画着永远不会上线的完美稿。
最后，文章总结说，设计师的影响力来自他们对结果的执着，对业务的洞察，以及跨团队的合作能力。一个设计师如果只把自己当画家，那他就只能被雇佣来画画。但如果他把自己当成产品的主人，那他就能影响产品的方向，甚至影响公司的战略。Intercom 的这篇文章给所有设计师提了个醒，也给了非设计师一个视角，让我们看到，在一个软件公司里，设计不是装饰，而是解决问题的核心手段。读完这篇文章，你会明白，真正有影响力的设计师，不是画得最好的人，而是最能让产品变好的人。
很多公司都遇到过这样的场景，设计师辛辛苦苦做了一版新的界面，开发同事看了却说这个功能实现不了，或者产品经理觉得方向不对，大家只好重新来。问题往往不在谁的能力，而在设计工作从一开始就只被当成画图，没有人先搞清楚要解决什么问题，也没有人让相关的人早点参与进来。Linear 这家做项目管理工具的公司，把自己的设计流程写了出来，核心是想说设计项目不能只交给设计师，它应该是一个团队共同推进的过程。
文章把设计项目分成几个阶段，第一步是探索和定义问题，也就是在动手画任何界面之前，先弄清楚用户真正卡在哪里，产品要达成什么目标。这就像你要装修房子，不能直接挑墙纸颜色，得先想清楚这间房是给谁住，平时怎么用，有哪些东西必须放进去。Linear 的做法是让设计师、产品经理和工程师坐在一起，通过用户访谈、数据分析、竞品研究这些方式来收集信息。这里的用户访谈就是找真实用户聊天，问他们怎么用产品，哪里觉得别扭，数据分析就是看用户实际点击了什么、停留了多久，竞品研究就是看看别的类似产品是怎么做的，有什么值得借鉴。这些动作听起来很平常，但很多团队会跳过，直接进入画图，结果画出来的东西没人需要。
第二阶段是设计探索，也就是在问题定义清楚之后，设计师开始画各种可能的方案。Linear 强调这时候要画很多草稿，不要只画一个就急着做出来。因为早期想法往往不成熟，多画几个才能对比哪个更合理。同时，这些草图要尽早拿给团队看，尤其是工程师，因为他们最清楚技术上能不能实现，成本有多高。比如一个动画效果，设计师觉得好看，但工程师可能说这需要额外的工作量，而且会拖慢性能，那就要考虑简化。这种跨职能协作，意思是不同岗位的人一起工作，而不是各干各的。Linear 建议每周都有同步会议，大家对着草图讨论，而不是等设计稿完美了才丢给开发。这样能避免后期大改，因为早期修改成本低，后期改代码就贵了。
第三个阶段是细化和交付。当方案确定后，设计师要开始做高保真设计稿，就是把颜色、字体、间距、交互细节都确定下来，像最终产品一样。这时要写清楚设计规范，比如按钮在不同状态下的样子，这样开发照着做不会走样。Linear 还提到要用设计系统，就是一套预先定义好的组件库，像乐高积木一样，设计师和开发都能用，保证一致性。交付时，设计师要把设计稿和说明文档一起给开发，说明文档里写清楚每个元素的行为，比如点击后发生什么，加载时显示什么。这能减少来回沟通，因为开发不用猜设计师的意图。
最后是验证和迭代，也就是产品上线后，要观察用户怎么用，是不是达到了预期。Linear 用数据来验证，比如看某个新功能的点击率是否上升，用户是否完成了想做的动作。如果效果不好，就要回到前面的阶段重新调整。这整个流程看起来像一条直线，但实际上会有很多来回。Linear 强调要有一个清晰的项目计划，用他们自己的工具来追踪任务，比如把设计任务拆成小卡片，分配给不同人，设定截止日期，这样大家都能看到进度。
这篇文章对普通读者的启发是，设计不只是美化，它是解决问题的手段。无论你在哪个行业，只要涉及创造新东西，都可以借鉴这种先理解问题再动手、让相关人员早期参与、不断验证的做法。它能让工作更顺畅，减少返工，最终做出真正有用的产品。
我们每天用的软件，比如文档编辑器、表格工具、笔记应用，通常都是别人做好的一套固定功能。你想在文档里加一个按钮，或者让数据自动更新，往往做不到，只能等软件公司更新。但有一群人，包括程序员和设计师，他们希望自己用的工具能像活的一样，随时可以改造成自己需要的样子。Ink & Switch 这个研究实验室，一直在探索个人软件的可能性，他们做了一个叫 Potluck 的项目，核心是动态文档，也就是文档不只是静态的文字和图片，里面可以嵌入小程序、实时数据，甚至能让你自己编写逻辑。
举个例子，你写一份周报，里面有一个表格，显示本周的销售数据。普通文档里，这个表格是死的，你只能手动更新。但在动态文档里，你可以让表格自动从数据库拉取最新数字，甚至加一个按钮，点击就能生成图表。Potluck 想实现的就是这种体验，让每个人都能像搭积木一样，在文档里添加各种小部件，并且这些小部件之间可以互相通信。
这篇文章提出了一个概念叫渐进式创造，意思是用户可以从简单的操作开始，比如拖动一个现成组件，然后慢慢学习如何修改它的参数，最后甚至能写一小段代码来定制功能。这就像玩拼图，你可以先拼好边缘，再慢慢填充内部，每一步都有成就感，而且不用一开始就掌握全部技能。Potluck 的设计目标是让这种渐进过程变得自然，让非程序员也能享受到编程的乐趣，因为他们可以通过点击和拖拽而不是写代码来创建功能。
文章还讨论了动态文档背后的技术挑战，比如如何让文档里的数据实时同步，如何让多个用户同时编辑而不冲突，以及如何保证安全，因为文档里的代码可能被恶意利用。这些听起来很专业，但可以想象成你在一个共享文档里工作，别人添加的脚本可能会读取你的数据，所以需要沙箱机制，也就是把代码限制在一个隔离环境里，不能随意访问你的电脑。
Potluck 的实验还涉及个人软件的理念，也就是软件应该服务于个人的独特需求，而不是强迫用户适应软件的功能。作者认为，未来的软件会越来越像原材料，用户可以自由组合，而不是买一个成品。这就像乐高，你买的是积木块，而不是固定的模型。文章里提到一些具体的原型，比如一个待办事项列表，可以自动根据日期排序，或者一个笔记面板，可以嵌入天气信息。这些例子都展示了动态文档的潜力。
对于普通读者来说，这篇文章的意义在于让你看到软件的另一面，它不只是工具，也可以是创作对象。当你学会在文档里添加一个小功能，你可能会觉得软件不再那么神秘，而是可以掌控的。虽然 Potluck 只是一个研究项目，不会立刻成为商业产品，但它指出的方向，即更灵活、更个人化的软件，可能会影响未来你使用的每一个应用。
我们常常以为，一个东西做得不好，是因为做的人不够聪明，或者技术不够先进。但很多时候，真正的问题更简单，也更难回答，就是有谁真的在乎。Frank Chimero 在这篇文章里，从设计系统的角度谈这个问题，但他说的事情，远远超出设计师的圈子。设计系统，你可以理解成一套积木和说明书，公司里很多人用同一套零件搭出不同的产品页面，这样看起来整齐，做起来也快。但问题是，当这套系统越做越大，越来越复杂，维护它的人往往会迷失在规则和流程里，忘了最初是为了让真实的人用起来舒服。作者说，当你在维护一个系统时，你关心的是系统本身，而不是使用系统的人。你开始关心颜色是否统一，按钮是否对齐，却忘了问问自己，这个按钮按下去，用户心里是什么感觉。这种关心的对象从人转移到系统，就是很多产品变得冷冰冰的根源。
文章里有一个很形象的比喻，说设计系统就像一片花园。园丁不是种下种子就完事了，他需要每天浇水、除草、观察每一株植物的状态。但很多维护系统的人，把自己当成了管理员，而不是园丁。管理员关心的是规则有没有被执行，园丁关心的是植物有没有好好生长。这中间的差别，就是你在乎的是制度，还是在乎的是生命。作者提醒我们，任何系统，无论是设计系统、公司制度，还是软件工具，都只是服务人的手段，而不是目的本身。当你把手段当成了目的，你就会开始用系统去约束人，而不是用系统去帮助人。
文章里还提到一个很实际的现象，就是当系统太复杂时，新人根本不敢碰，怕弄坏了什么。于是系统就变成一小部分专家的领地，其他人只能被动接受。这就像一个小区的公共花园，本来应该大家一起维护，但后来因为管理规则太繁琐，普通居民都不敢进去了，只有几个管理员在打理。这样一来，花园就失去了它作为公共空间的意义。作者说，好的设计系统应该让更多人能参与进来，而不是把人挡在外面。这需要维护者有一种照料的心态，愿意花时间去解释、去引导，而不是用规则去控制。
读这篇文章，最打动我的是作者把“在乎”这件事说得如此具体。他说的不是抽象的爱心，而是每天做决定时，你优先考虑的是系统的整洁，还是人的便利。比如，当你要加一个新功能时，你是先查设计规范，还是先问用户会遇到什么困难。当系统出现一个小瑕疵时，你是觉得无所谓，反正没人会发现，还是立刻去修，因为你知道有人会因此感到困扰。这些细小的选择，积累起来，就决定了一个产品是有温度的，还是冷冰冰的。作者让我们看到，维护一个系统，本质上是一种照料他人的工作，而不是一项技术工作。
所以，这篇文章虽然谈的是设计系统，但它的核心信息适用于所有需要与人打交道的领域。无论是管理一个团队，还是经营一家公司，还是维护一个社区，你都要问自己，我到底在乎什么。如果你在乎的是规则和流程，那么你的组织会越来越僵硬，人会越来越疏远。如果你在乎的是人的体验和感受，那么即使系统不完美，人们也会愿意留下来，帮你一起改进。最后，作者说，真正让一个系统活起来的，不是完美的设计，而是有人愿意持续地、耐心地照料它。这个道理，放之四海而皆准。读完这篇文章，你会开始审视自己每天的工作，到底是在照料什么，还是在控制什么。
你可能听过很多管理建议，比如要授权给下属，要信任团队，不要事必躬亲。这些建议听起来很有道理，而且是从很多成功公司里总结出来的。但 Casey Winters 在这篇文章里指出，这些建议对大多数创始人来说，其实并不适用，甚至可能有害。原因是，创始人和职业经理人面对的局面完全不同。经理人通常接管一个已经运转起来的组织，有明确的职责分工，有现成的流程，他们的任务是优化和改进。而创始人面对的是从零开始，什么都没有，一切都得自己摸索。在这种情况下，你没法简单地授权，因为没有人可以授权，你也没法信任团队，因为团队可能只有几个人，而且大家都不知道方向在哪里。
文章里有一个关键概念叫结果责任，意思是你要对最终结果负责，而不仅仅是完成自己的任务。经理人可以对某个环节负责，比如市场部经理对广告投放效果负责，但创始人要对整个公司的生死负责。这种责任差异，导致创始人不能像经理人那样，把任务分出去就撒手不管。创始人必须深入每一个细节，因为任何一个环节出了问题，都可能让公司完蛋。比如，你是一个初创公司的创始人，你请了一个工程师来写代码，但你不能完全放手，因为如果代码写得不好，用户会流失，公司会倒闭。你必须在早期深度参与产品设计、技术选型，甚至亲自写代码，因为这时候没有别人能替你承担这个责任。
作者还提到，随着公司的发展，创始人需要不断调整自己的角色。在早期，你可能是个全能选手，什么都要干。但到了中期，你需要学会招聘和培养管理者，把你的做事方法传递下去。这个过程很痛苦，因为你习惯了亲自做，而且你觉得别人做得不如你好。但如果你不转变，公司就会卡在你一个人的能力上限上。文章说，很多创始人失败，不是因为产品不好，而是因为他们没法完成从做事的人到管理者的转变。这种转变不是简单的授权，而是要学会建立机制，让团队在没有你的情况下也能做出正确的决定。
文章里还讨论了一个常见的误区，就是很多创始人会模仿大公司的管理方法，比如开很多会，写很多文档，设立复杂的考核指标。但作者说，这些方法在大公司里可能有效，因为大公司有足够的资源和冗余，但在初创公司，这些只会拖慢速度，扼杀灵活性。初创公司需要的是快速试错，而不是完美规划。作者建议，创始人应该根据自己的阶段，选择适合的管理方式，而不是盲目照搬。比如，早期可以每天开短会，快速对齐，而不是花几个小时写报告。
最后，作者总结说，管理建议不是放之四海而皆准的真理，而是有适用条件的。创始人需要理解自己的独特处境，不要被那些给经理人的建议所迷惑。你要清楚自己的责任是什么，然后找到适合自己的管理方式。这篇文章的价值在于，它提醒我们，当你听到一个建议时，先想想它是不是适合你的情况，而不是直接照做。对于创始人来说，最重要的不是学会管理，而是学会在不确定的环境中做决定，并承担后果。读完这篇文章，你会对创业者的困境有更深的理解，也会对管理这件事有更清醒的认识。
想象你开了一家新餐厅，菜单很精美，装修很漂亮，但第一天开门，一个客人都没有。你会想，问题出在哪里？是菜不好吃吗？不是，因为还没人尝过。是价格太贵吗？也不是，因为还没人看过菜单。真正的问题是，一家空荡荡的餐厅，很难吸引第一个客人进来。这就是网络产品常说的冷启动问题（cold start problem），意思是新产品刚上线时，用户很少，内容很少，彼此都找不到对方，所以谁也留不下来。Andrew Chen 这篇文章讨论的就是这个难题，而且他提出了一个反直觉的观点，要解决冷启动，不能只靠拉新用户，而要先去解决一个更难的问题。
他举的例子很生动，比如早期的 Uber，它面对的不是乘客太少，而是司机太少。如果一个乘客打开应用，发现周围没有车，他马上就会关掉，再也不回来。所以 Uber 的早期团队没有把精力花在打广告吸引乘客上，而是花了很多力气去说服司机加入，甚至亲自去机场、酒吧门口跟司机聊天，帮他们装应用，教他们怎么用。这就是在解决关键供给（key supply）的问题，供给就是平台上提供服务的那些人，比如司机、房东、外卖员。没有他们，需求方也就是乘客、房客、食客，来了也会走。所以文章说，要解决冷启动，先要找到一个最难但最关键的环节，把它打通，而不是平均用力。
另一个例子是 Airbnb，它早期最大的障碍不是没人租房子，而是房东不愿意把自家房间挂到网上，因为怕陌生人住进来不安全，也怕麻烦。Airbnb 的创始团队就挨家挨户去敲房东的门，帮他们拍照，把房间照片拍得好看一点，甚至帮他们写房源描述。他们做的这些事，看起来又累又琐碎，但正是这些事让第一批房东愿意尝试，才有了后来的房源量。文章把这个思路概括为，要解决一个困难问题（solve a hard problem），这个困难问题往往是别人不愿意做、做起来很费劲，但却是整个产品能否转起来的关键。
为什么说这是反直觉的？因为很多创业者遇到冷启动，第一反应是去搞增长黑客（growth hacking），也就是用各种技巧快速拉用户，比如发优惠券、做分享奖励。但文章提醒说，如果基础供给不存在，拉来的用户只会看一眼就走，优惠券花完就没了，增长是虚的。相反，如果你先花几个月甚至一年去解决那个困难问题，比如把第一批司机服务做到极致，或者把第一批房东的体验做到完美，那么用户来了自然就会留下，口碑也会慢慢传开。这就像先挖好井，再请人来喝水，而不是先喊人来看一个干涸的坑。
文章还提到，困难问题往往不是技术上的，而是运营上的，比如要跟真实的人打交道，要处理很多琐碎的细节。很多工程师背景的创业者会觉得这不酷，宁愿去写代码也不愿意去跟司机聊天。但恰恰是这些不酷的事，构成了产品的护城河，也就是别人难以模仿的竞争优势。因为你可以复制代码，但你很难复制一个团队愿意趴在地上把脏活累活干好的心态。当然，这里说的脏活不是指不道德的事，而是指那些费力不讨好、但必须有人做的具体工作。
读这篇文章，你会明白一个道理，做产品不是先有用户再有价值，而是先有价值再有用户。那个价值往往藏在一个很难解决的问题里，你把它解决了，用户自然会来。就像你开餐厅，与其在门口拉客，不如先把那道招牌菜做到极致，让第一个客人吃完后忍不住告诉朋友。冷启动的答案，不在营销预算里，而在你愿意为第一个用户付出多少心血里。
很多团队做产品规划，喜欢列一个长长的功能清单，比如下个季度要做搜索、要做推荐、要做支付，然后按优先级排一排，就开始开发了。但 Reforge 这篇文章指出，这样的路线图（roadmap）往往只是把要做的事列出来，却没有回答一个更重要的问题，这些事到底是为了什么？就像一个旅行者，手里有一张列满了地名的清单，却不知道自己的目的地是哪里，那他很可能走很多弯路，甚至南辕北辙。文章提出了一个叫 4D 产品路线图的方法，这里的 4D 不是指三维加时间，而是四个维度，分别是问题（problem）、用户（user）、解决方案（solution）和指标（metric）。
我们先看一个常见的场景，一个团队想做增长，于是他们决定做一个分享功能，让用户可以把内容发给朋友。这个决定看起来合理，但如果你问他们，这个功能要解决什么问题？他们可能会说，让更多人知道我们。再问，是为哪个用户群体做的？他们会说，所有用户。再问，怎么知道这个功能有没有用？他们会说，看分享次数。这样听起来好像没什么问题，但文章认为，这恰恰是问题所在，因为这些问题都太宽泛了，宽泛到无法指导具体的设计和决策。
4D 方法要求团队把每个维度都说得非常具体。比如问题，不是“用户留存不好”，而是“新用户注册后第一天就离开，因为他们找不到感兴趣的内容”。用户，不是“所有用户”，而是“刚注册、还没有关注任何话题的新手用户”。解决方案，不是“做一个推荐系统”，而是“在新用户注册时，让他们选择至少三个感兴趣的话题，然后立即在首页展示相关的内容”。指标，不是“提高留存”，而是“新用户注册后 7 天内，每天回访的比例从 20% 提升到 35%”。这样一改，整个路线图就变得非常清晰，团队知道该做什么，也知道做完后怎么判断有没有成功。
文章还强调，这四个维度不是孤立的，而是层层递进的。先定义问题，然后明确为谁解决，再想解决方案，最后定指标。如果跳过前面直接想解决方案，很容易做出一个自嗨的功能。比如你直接想做一个“每日签到”功能，但你没有定义问题，也许真正的问题是用户没有动力回来，而不是缺少一个签到按钮。签到可能是一个解决方案，但也许更好的方案是让用户每次打开都能看到新的有趣内容。所以，路线图应该从问题出发，而不是从解决方案出发。
另外，文章也提醒，路线图不是一成不变的，它应该是一个持续调整的假设。你提出一个问题和解决方案，然后通过实验去验证，如果指标没有改善，就说明你的假设错了，需要回到问题重新思考。这就像科学实验，假设不是结论，而是待验证的猜想。所以，4D 路线图更像一个学习工具，而不是一个施工图纸。
读完这篇文章，你会意识到，产品规划的本质不是排期，而是思考。思考你为谁解决什么问题，以及怎么证明你解决了。当你下次看到一份路线图，你可以试着用这四个维度去审视，如果某个维度是模糊的，那这个路线图可能还需要再打磨。真正有效的路线图，不是一长串功能列表，而是一连串有逻辑的假设，每个假设都指向一个具体的用户痛点和一个可衡量的结果。这样，团队才能把力气花在刀刃上，而不是盲目地做一堆没人用的功能。
想象你花了好几个月做出一个工具，它能让销售团队自动整理客户资料，省去大量手工录入的麻烦。你兴冲冲地把它推给市场，结果发现愿意掏钱的客户寥寥无几。问题出在哪里？是产品不够好吗？还是你找错了人？这篇文章讲的正是这样一家公司，Clay，它走过的弯路和最终找到方向的过程。Clay 做的是一款帮助销售团队从海量信息里挖掘潜在客户的工具，有点像给销售配了一个超级助理，能自动在网上搜索、整理、更新客户名单。但一开始，Clay 并不知道谁最需要它，于是他们尝试了各种客户，从大企业到小创业公司，从销售团队到市场团队，结果都不太理想。
文章里最关键的转折，是他们决定把目标客户收窄到一个非常具体的群体，只服务那些销售周期长、客单价高、客户名单需要精细维护的公司，比如做企业软件的公司。这个决定听起来简单，但执行起来需要极大的纪律，因为每次想扩大范围，都会把产品拉回平庸。Clay 的创始人分享了一个很实在的经验，他们每两周就会问自己一次，我们到底在为谁解决什么问题，如果答案不清晰，就宁愿砍掉功能，也不去讨好所有人。这种聚焦带来的好处是，产品可以做得非常深，客户会真正依赖它，而不是可有可无的锦上添花。
文章里还提到，Clay 在早期刻意放慢融资和扩张的节奏，把时间花在跟客户反复试用、调整产品细节上，比如客户说某个字段总是抓错，他们就专门优化那个字段的抓取逻辑，直到客户觉得离不开这个工具。读这篇文章，你会看到产品市场匹配（product-market fit）不是一个玄学，而是一连串痛苦的取舍和耐心的试错。它提醒我们，找到一群愿意为你尖叫的客户，比让一百个人觉得还不错要重要得多。看完你可能会想，自己手头的事情，是不是也该砍掉一半，只留最核心的那一块。
你有没有发现，微信、淘宝、抖音这些平台，用的人越多，它们就越强大，而你作为用户，虽然享受了便利，却也越来越难离开，甚至要忍受广告、算法推送、隐私被收集这些代价。这篇文章从网络效应（network effects）讲起，解释了一个平台如何因为用户彼此连接而变得更有价值，比如你发一条消息，只有对方也在用这个应用才能收到，所以朋友越多，你越离不开它。
但文章的重点不是夸网络效应有多厉害，而是追问，当少数平台掌控了连接、数据和规则，普通用户和内容创作者会失去什么。作者把这种局面比作一种新的社会契约，过去我们说努力工作就能有回报，但在网络平台上，你的劳动、你的数据、你的注意力，都在为平台创造价值，而平台却很少跟你分享这些收益。比如一个视频创作者辛辛苦苦做内容，吸引来大量流量，平台靠这些流量卖广告赚得盆满钵满，但创作者拿到的分成可能微乎其微，而且一旦平台改变算法，他的收入可能一夜之间归零。
文章里还提到，平台不仅控制着经济收益，还控制着声望和权力，比如谁能被推荐、谁会被封禁，这些决定权都掌握在平台手里，而用户几乎没有议价能力。这让人想到，我们是不是该重新思考，网络平台应该承担怎样的责任，用户和创作者又该如何保护自己的权益。作者提出了一些设想，比如平台应该更透明地解释算法，或者用某种方式让用户共享平台增长的红利，但这些想法都还只是讨论，真正落地很难。这篇文章的价值，是让你在看任何网络平台时，多一层思考，它真的在为你服务，还是你其实在为它打工。它不会给你一个简单的答案，但会让你对免费应用背后的代价有更清醒的感知。
很多人以为战略是那种高高在上的东西，是CEO在会议室里对着PPT讲的大词。但罗杰·马丁（Roger Martin）在《玩着赢》（Playing to Win）这本书里，把战略拉回到了地上。他讲得很直接，战略不是一堆漂亮的愿景，而是一连串非常具体的、甚至有点痛苦的选择。你选了这个，就不能选那个，你不可能什么都占。这种思维方式，对任何想认真做事的人都有用，不管你是开一家小餐馆，还是在公司里负责一个新产品。
马丁提出了一个很有名的框架，叫“战略选择级联”（strategic choice cascade）。听起来复杂，其实就是一连串五个问题，一环扣一环。第一个问题是，我们的愿望是什么，也就是你想赢下哪场比赛。第二个问题是，我们在哪里比赛，也就是你要在哪个市场、哪个领域跟别人竞争。第三个问题是，我们怎么赢，也就是靠什么本事、什么打法胜过别人。第四个问题是，我们需要什么能力，也就是公司内部得有什么样的本事才能支撑前面的打法。最后一个问题是，我们需要什么管理体系，也就是用什么样的制度、流程和文化把这些能力固定下来。这五个问题从大到小，从外部到内部，像瀑布一样一层层往下落。如果你每一个问题都能想清楚，并且前后一致，那你就有了一套完整的战略。
马丁还讲了一个特别重要的观点，就是要赢，你得选一个独特的有利位置（winning aspiration），然后在这个位置上建立一套环环相扣的活动。他喜欢用宜家（IKEA）举例子。宜家选的位置是提供价格实惠、设计好看、需要顾客自己组装的家居。为了这个位置，宜家做了很多配套的事情，比如把家具设计成平板包装，这样运输便宜，顾客也能自己拉回家。比如店里没有很多销售人员，而是让顾客自己逛，自己看标签。比如店里还开餐厅，卖瑞典肉丸，让顾客能待得更久。这些事情单独看没什么，但合在一起，就形成了一个很难被模仿的系统。如果你只学宜家的某一点，比如也卖肉丸，但其他所有环节都不配套，那一点用都没有。这就是战略的威力，它不是一个孤立的决定，而是一整套互相配合的选择。
马丁还特别强调，战略里最难的部分不是分析，而是放弃。他说，战略的本质就是选择不做什么。因为资源有限，你不可能同时服务所有客户，不可能在所有市场都领先。你必须做出取舍。比如你是一个高端品牌，你就得接受那些只想要便宜货的客户不是你的目标。你是一个效率型公司，你就得接受那些追求极致个性化的客户会去别家。这种放弃很痛苦，但正是这种痛苦让战略变得有意义。如果你什么都想做，最后往往什么都做不好。
读完这本书，你会明白，战略不是写在墙上的标语，而是你每天做的每一个选择。你选择把时间花在哪个客户上，你选择把预算投在哪个项目上，你选择招什么样的人，这些都是战略的体现。马丁的书让这些选择变得清晰，也让你敢于做出艰难的决定。
想象你在一座别人拥有的土地上盖了一栋房子，房子很漂亮，住着也很舒服，但土地是租来的。哪天地主说，这块地我要收回了，或者租金要涨十倍，你一点办法都没有。这就是平台风险（platform risk）最形象的比喻。尤金·韦（Eugene Wei）在2015年写的这篇文章，讲的就是这种风险，尤其是对创业公司来说，这种风险有多么致命。
文章里举了一个很典型的例子，就是Zynga。可能很多年轻人不知道这家公司，但在Facebook游戏最火的那几年，Zynga可是风光无限。它做出了《开心农场》（FarmVille）、《黑帮战争》（Mafia Wars）这些爆款游戏，用户量一度达到几亿。但问题是，这些游戏完全依赖Facebook的平台，用户是通过Facebook的好友列表和消息推送来传播游戏的，Zynga自己手里几乎没有用户的直接联系方式。Facebook说改一下算法，Zynga的流量可能就掉一大截。Facebook说分成比例要提高，Zynga也只能接受。后来Facebook确实调整了政策，Zynga的业绩就一落千丈，股价暴跌，再也没缓过来。这就是平台风险，你把命运交给了别人，别人稍微动一动，你就可能粉身碎骨。
尤金·韦在文章里分析，平台对你通常有三种态度。第一种是合作，平台和你一起赚钱，这时候你好我好。第二种是竞争，平台看到你的生意很赚钱，它自己也开始做同样的业务，这时候你就麻烦了。第三种是控制，平台直接限制你的发展，比如限制你触达用户的方式，或者提高抽成。Zynga就经历了从合作到控制的过程。Facebook一开始很欢迎Zynga，因为Zynga的游戏能吸引用户，让用户留在Facebook上。但后来Facebook自己也想做游戏，或者觉得Zynga太依赖它，就开始调整政策，限制Zynga的传播渠道。Zynga没有别的办法，只能接受，因为它没有自己的用户渠道。
为什么平台风险这么难防范？尤金·韦说，因为创业公司往往别无选择。你在早期为了快速获取用户，必须借助大平台的流量，比如微信、苹果App Store、抖音，这些平台能让你一夜之间触达海量用户。但你一旦依赖上它们，就很难再独立。你不可能自己再造一个社交网络，也不可能自己做一个操作系统。所以创业公司常常陷入两难，用平台，风险大，不用平台，可能根本活不下来。
那怎么办呢？尤金·韦给出了一些建议。他说，你要尽量建立自己的用户关系，把用户从平台引导到你自己的渠道，比如自己的网站、自己的邮件列表、自己的App。你要让用户真正属于你，而不是属于平台。你还要尽量让你的产品有独特的价值，让平台觉得你是合作伙伴而不是威胁。当然，这些都不是万能的，平台的风险永远存在，你只能尽量降低它，不能完全消除。
这篇文章虽然写于2015年，但今天读来依然非常有启发。因为现在的大平台比那时更强大，苹果、谷歌、Facebook、微信、抖音，每一个都掌握着巨大的流量入口。创业公司在这片土地上盖房子，永远要记得，地是别人的，你得时刻准备着，万一地主变脸，你至少还有一块可以搬走的砖。读完这篇文章，你会对“依赖”这个词有全新的理解，也会更加警惕那些看似免费的流量。
想象你走进一家餐厅，菜单上有一百道菜，每道菜都做得不错，但你没有头绪该点什么。你可能会随便一指，结果端上来的菜不合口味，或者干脆放弃点菜，转身离开。产品设计里也有类似的情况。当软件功能太多、界面太复杂时，用户会感到迷茫，不知道从哪里开始，也不知道每个按钮是干什么用的。Intercom 这家公司做的是帮助企业和客户沟通的软件，他们的设计师发现，与其给用户提供无数种选择，不如在合适的时候只提供少数几个清晰、明确的选项。这就是他们说的“设计模式”，也就是在特定场景下，大家约定俗成的交互方式。比如，一个对话框里，是放一个“确定”按钮，还是放“确定”和“取消”两个按钮，这就是一种模式。选对了模式，用户不用思考就知道怎么操作，选错了，用户就会卡住。
文章里讲了一个例子，让我印象很深。他们设计一个让用户设置自动回复的功能。一开始，他们想做一个功能强大的界面，用户可以设置各种复杂条件，比如“如果客户在周末发消息，就回复……如果是新客户，就回复……如果客户提到退款，就回复……”结果测试时，用户完全懵了，他们不知道这些条件怎么组合，也不知道会不会出错。后来设计师改变思路，只提供一个简单的开关，用户只需要决定“开”或“关”，然后再填一句自动回复的话。这样一来，用户一下子就明白了。这个例子说明，设计模式的选择不是追求功能最多，而是追求让用户最容易理解。有时候，限制选择反而能帮助用户做出决定。
另一个关键点在于，设计模式要符合用户的预期。比如，网页上的链接通常是蓝色的、带下划线，用户看到就知道可以点击。如果设计师为了美观，把链接改成黑色、不带下划线，用户就可能不知道那是链接，从而错过重要信息。Intercom 的设计师强调，要使用那些已经被用户熟悉的模式，而不是为了创新而创新。当然，这并不意味着不能有新的设计，但新设计必须让用户能够快速学会。比如，他们提到“渐进式披露”，意思是把复杂的功能藏起来，先让用户看到最简单的界面，等用户需要时再一步步展开更多选项。这就像一本教科书，先讲基础概念，再讲进阶内容，而不是第一页就扔出所有公式。
读这篇文章，我最大的感受是，设计产品就像是在帮用户指路。好的设计师不会把地图塞给用户，而是站在路口，告诉用户“往左走，然后直行”。他们通过选择合适的设计模式，减少用户的思考负担，让用户能顺利到达目的地。而选择模式的关键，不是看哪个模式更酷，而是看哪个模式能让用户在这个具体场景下少犯错误、少花时间。这让我想到，我们平时用到的很多软件，那些让我们觉得“好用”的功能，背后其实都是设计师精心挑选模式的结果。所以，下次当你打开一个应用，觉得某个按钮放得恰到好处时，不妨想一想，这背后可能隐藏着设计师对用户行为的深刻洞察。
你有没有过这样的经历，你和朋友计划一次旅行，你们在聊天软件里发消息，在备忘录里记想法，又打开一个文档列清单，最后可能还要用表格算预算。信息散落在好几个地方，来回切换很麻烦，而且计划总在变，改起来也很费劲。Ink & Switch 实验室的“Embark”项目，就是想解决这个问题。他们想做一个“动态文档”，这种文档不是静态的文字堆砌，而是可以像活的东西一样，随着你的想法和行动而改变。想象一下，你打开一个文档，里面不只有文字，还有可以点击的按钮、可以拖动的滑块，甚至能直接跟其他工具连接。你可以在里面做计划，然后直接执行，而不是把计划写在纸上，再去另一个软件里实现。
Embark 的核心是“可塑界面”，意思是这个界面的形状可以随着你的需要而变化。比如，你一开始只是随便记几个想法，界面就像一张白纸。当你开始列计划时，白纸上就出现了待办事项的列表，每一项前面有个小方框，你可以勾选。当你需要安排时间时，列表就变成了日历视图，你可以把事项拖到具体的时间段。这种变化不是固定的，而是根据你正在做的事情自动调整。这就像一块橡皮泥，你可以把它捏成球，也可以拉成长条，但始终是同一块泥。
文章里举了一个例子，让我觉得特别生动。假设你要组织一个聚会，你在 Embark 文档里写“邀请小明、小红、小刚”，然后这三个名字就变成了可以点击的标签。你点击“小明”，旁边弹出一个菜单，你可以选择“给小明发消息”，于是文档直接调出你的消息应用，你发完消息，文档里就自动记录“已邀请小明”。如果小明回复“会来”，你就在文档里标记一下，然后文档会自动更新聚会的预计人数。整个过程都在同一个文档里完成，不需要切换应用，也不需要手动更新信息。这听起来很神奇，但它的原理是，文档里的每一个元素都是“活”的，它们知道自己的状态，也能触发动作。
这个项目还处于研究阶段，但它指向了一个未来的可能性，文档不再只是记录结果的工具，而是可以成为行动的平台。就像人们常说的“文档即应用”，你不需要专门打开一个日程软件，日程功能就在你的文档里。这让我想到，我们平时用的很多软件，其实都是把数据锁在各自的“箱子”里，比如聊天记录在聊天软件里，待办事项在待办软件里，它们之间很少交流。而 Embark 想做的，是把这些箱子打开，让数据自由流动，同时保持一个统一的界面。当然，要实现这个愿景，还有很多技术难题，比如数据格式要统一，不同应用之间要能互相通信，还要保证安全。但至少，它让我们看到了一个更流畅、更自然的数字工作空间。
读完这篇文章，我不禁思考，我们是不是已经被工具绑架了，为了用工具而用工具，而不是让工具为我们服务。Embark 提醒我们，好的工具应该像一张聪明的纸，你写下去，它就懂你的意思，并且帮你把事情推进下去。也许未来的某一天，我们不再需要学习各种复杂的软件，只需要一个能理解我们意图的“动态文档”，就能完成大部分工作。这听起来有点科幻，但 Embark 正在把它变成现实。
我们每天把照片、文档、聊天记录都交给“云”，觉得它轻飘飘的，像一朵棉花糖，随时能飘走，也随时能拿回来。但写这篇文章的人想提醒我们，云一点都不轻，它重得很。这重不只是物理上的重，更是责任上的重。你按下保存键，数据并不是飞到了天上，而是落进了某个巨大的、耗电的、需要人日夜维护的机房。这篇文章写于2013年，但今天读起来，它说的道理反而更明显了。你手机里的照片，其实躺在某个国家的某个仓库里，那里有成千上万台机器嗡嗡作响，有空调在拼命降温，有电费账单在累积。你睡觉的时候，有值班的人盯着屏幕，怕机器过热，怕硬盘坏掉，怕某个线路断了。这就是云的真实样子，它是一堆实实在在的钢铁、电线和人力，而不是你想象中那个无形无质的东西。
文章里还提到一个更让人不安的点，设计不是看不见的。我们总说好的设计是隐形的，你用起来顺畅，感觉不到设计的存在。但作者说，这种想法太天真了。设计其实一直在那里，它决定了你看到什么，按什么按钮，你的数据怎么流动，你的隐私怎么被处理。你感觉不到它，不是因为它消失了，而是因为它太成功了，成功到让你忘了它的存在。就像你走路时不会意识到地心引力，但地心引力一直在拉扯你。设计也是，它塑造了你的每一个动作，而你却以为那是你自己的选择。
作者用了很多具体的比喻来说明云的重量。比如他说，云其实是一个巨大的、沉重的物体，它需要被固定在地面上，需要被锁在机房里，需要被小心翼翼地对待。你上传一张照片，这个动作背后是无数个微小的操作，它们像蚂蚁搬家一样，把你的数据一点点搬进服务器。这些服务器放在哪里，放在哪个国家，那个国家的法律允许谁看你的数据，这些都不是小事。你按下“上传”的时候，你其实是在做一次信任的委托，你把你的记忆、你的工作、你的秘密，交给了一群你永远见不到的人。
这篇文章最打动我的地方，是它提醒我们，技术不是中立的。云服务商设计他们的界面，让你觉得一切都那么顺滑，那么方便，但顺滑和方便的背后，是他们希望你忽略的那些问题。比如，你的数据可能被用来训练什么模型，可能被卖给什么广告公司，可能在你不知道的情况下被读取。设计让这些问题变得看不见，不是因为它们不存在，而是因为设计让你没有机会去问这些问题。所以，设计不是看不见的，它只是把某些东西藏起来了，藏在你觉得理所当然的体验里。
读这篇文章，你会开始用一种新的眼光看自己手机里的那些App。你会想，那个“同步”按钮背后是什么？那个“免费”的云盘，它靠什么赚钱？你的数据，在那些机器的硬盘里，到底经历了什么？这些问题可能没有简单的答案，但至少，我们不应该假装它们不存在。云是重的，设计是看得见的，一旦你意识到这一点，你就不再是一个被动接受技术的用户，而是一个开始思考技术背后代价的人。这种思考，就是这篇文章能带给你的最宝贵的东西。
如果你用过打车软件、订过民宿、或者在网上叫过外卖，你其实已经在使用一种叫做市场平台（marketplace）的产品了。这种产品的特点，是它自己不生产东西，而是把卖东西的人和买东西的人拉到一起，然后从中间抽成。听起来很简单，但真正难的地方在于，你得像一个媒人，既要让来相亲的双方都满意，还得让他们愿意一次又一次地来。这篇文章来自硅谷著名投资机构a16z，他们投资过很多这样的平台，所以他们对这个问题的观察，不是纸上谈兵，而是见过无数创业公司起起落落之后总结出来的经验。
文章的核心，是告诉你一个市场平台要想活得好，不能只看用户总数，要看一些更细的指标。比如，你得知道你的市场是不是够“厚”。什么叫厚呢？就是同一个时间，你这个平台上得有足够多的卖家在卖，也得有足够多的买家在买。如果卖家很多但买家很少，那卖家就会觉得没生意可做，慢慢就走光了。反过来，如果买家很多但卖家很少，买家就会觉得选择太少，也会流失。这个平衡非常微妙，就像一条小船，两边都得有人坐，船才不会翻。
文章里提到了13个指标，但其中最重要的几个，我觉得特别值得展开讲讲。一个是“流动性”（liquidity），这个词听起来很专业，但你可以把它理解成“买卖双方能不能很快地碰上头”。比如你打开打车软件，三秒钟就有人接单，这就是流动性好。如果等了三分钟还没人接，那就是流动性差。流动性差的时候，用户会觉得很挫败，下次可能就不用了。所以平台要做的第一件事，就是让每一次搜索都能很快有结果，哪怕结果不完美，也比空着强。
另一个重要的指标是“供需质量”。意思是说，你平台上来的卖家是不是靠谱的，买家是不是真的想买东西的人。如果一个平台上全是骗子卖家，或者全是只看不买的逛客，那这个平台就没什么价值。文章里说，很多平台一开始为了吸引人，会降低门槛，让什么人都能进来，结果平台上鱼龙混杂，好用户反而被吓跑了。所以平台得像一个严格的管家，既要让门开着，又要防止坏人进来。
还有一个指标叫“网络效应”（network effects），这个词你可能听过，但未必清楚它具体是什么意思。简单说，就是人越多，每个人得到的价值就越大。比如你用微信，是因为你的朋友都在用。如果只有你一个人用，那微信就没什么用。市场平台也一样，买家越多，卖家越愿意来，因为能卖出去东西；卖家越多，买家越愿意来，因为选择多。这个循环一旦转起来，平台就像滚雪球一样越滚越大。但问题是，怎么让这个雪球开始滚？文章里说，很多平台在早期会采用“补贴”的办法，也就是给买家或卖家钱，让他们来使用。但这就像用柴火点燃一堆湿木头，柴火烧完了，木头还没干，平台就死了。所以补贴不是长久之计，关键是要让用户因为真实的价值而留下来。
这篇文章最让我印象深刻的地方，是它提醒我们，市场平台不是一蹴而就的，它需要精心维护。就像打理一个花园，你不能只把种子撒下去就不管了，你得浇水、施肥、除草，还要防止虫子来咬。平台运营者要时刻关注那些指标，就像园丁要看天气和土壤一样。有时候某个指标突然变差了，比如买家的投诉变多了，那可能是卖家的质量出了问题，需要赶紧处理。有时候卖家突然变少了，那可能是你的抽成太高了，他们觉得不划算，你得调整策略。
读完这篇文章，你会明白，为什么有些平台能成功，有些平台却悄无声息地消失了。成功的平台，不是因为它名字好听，或者界面好看，而是因为它真的让买卖双方都感到满意。它像一座桥，连接了两岸的人，桥要稳，要宽，要能承受住来来往往的脚步。而那些失败的平台，往往是桥还没建好，就想让人跑起来，结果桥塌了。所以，如果你将来想做一个市场平台，或者你只是想理解你每天用的那些App为什么好用或难用，这篇文章会给你一个很好的框架。它让你看到，那些光鲜的界面背后，其实是一堆数字在跳舞，而这些数字，才是决定一个平台生死的关键。
很多公司做第一个产品的时候，方向很清楚，就是解决一个具体问题。比如一个工具软件，帮人把图片压缩得小一点，或者一个记账应用，帮人记录每天的支出。用户需要什么，团队就做什么，产品慢慢长大，用户越来越多。但有一天，团队会开始想，我们是不是该做第二个产品了？这个问题听起来很自然，好像公司长大了就该多生孩子。但真正做过产品的人都知道，第二个产品往往是最容易让公司栽跟头的地方。这篇文章讲的不是怎么发明一个新点子，而是当公司已经有了一款成熟产品，什么时候应该做第二款，什么时候不应该，以及做了之后怎么分配力气。
作者是 Casey Winters，他做过 Pinterest 和 Grubhub 的增长负责人，见过很多产品从零到一，也见过很多公司因为乱开新战线而浪费资源。他提出一个很实际的观点，公司做第二个产品之前，先要问自己，第一款产品是不是真的到了天花板。很多公司其实没有到天花板，只是增长变慢了，就以为市场饱和了，其实可能是还有大量用户没被触达，或者产品还有没覆盖的场景。比如一个记账应用，可能只覆盖了个人用户，但小商家也有记账需求，这算不算第二个产品？还是只是第一个产品的延伸？作者认为，这中间的界线很重要，因为延伸和真正的第二产品，需要的资源和方法完全不同。
那什么时候才应该做第二个产品呢？作者给了一个很具体的判断标准，就是当第一个产品已经建立了某种优势，比如用户群、数据、品牌或者渠道，而第二个产品能借用这个优势，并且能解决一个独立的问题。比如一个做图片编辑工具的公司，积累了上亿用户，这些用户经常需要把图片分享到社交平台，那公司做一个简单的图片分享功能，可能不是第二产品，而是功能的延伸。但如果公司发现用户还需要把图片做成实体相册，那这可能是一个新的产品，因为制作和物流是完全不同的能力。作者强调，第二产品不是从零开始，而是要从第一产品已经有的资产里长出来，这样才省力。
但即使条件合适，做第二个产品也面临一个很实际的难题，就是资源分配。很多公司会把最优秀的人留在第一个产品，因为那是现金牛，然后派一批新人去做第二产品。结果第二产品缺乏经验，做出来的东西不接地气，而第一产品又因为缺少人才而开始停滞。作者的建议是，如果决定做第二产品，一定要让最资深的团队参与，甚至要让创始人亲自带队，因为新产品的早期方向太关键，容错率很低。他还提到，很多公司失败不是因为第二产品本身不好，而是因为同时开了太多战线，每个都投入不足。他举了一些例子，比如有些公司做了五六个产品，每个都只有一两个人维护，最后没有一个做起来。
这篇文章最值得记住的一点，是它把“做第二产品”从一个听起来很酷的战略决定，变成了一个需要冷静计算的资源问题。它提醒我们，公司不是产品越多越好，而是要看自己的优势能不能被复用，资源能不能撑得住。对于没有产品背景的读者来说，这篇文章可以帮你理解，为什么你喜欢的某个应用突然多了一个奇怪的新功能，那可能不是他们想创新，而是他们在试探第二产品的边界。下次看到一家公司发布新产品，你可以想一想，它是不是从老产品的用户、数据或渠道里长出来的，还是纯粹拍脑袋想出来的。这个判断，往往就能看出这家公司是不是真的想清楚了。
你有没有想过，为什么我们用手机叫车、点外卖、订酒店，总是习惯打开同一个应用，而不是直接去联系司机、餐厅或者酒店？比如你饿了，你打开外卖平台，而不是挨个给餐厅打电话。你出差，你打开订房网站，而不是直接给某个酒店发邮件。这些平台看起来只是把供应商的信息放在一起，但为什么它们能变得这么强大，甚至让供应商不得不听它们的话？这篇文章讲的就是这个现象，它给这类平台起了一个名字，叫聚合器（aggregator）。
文章的作者是 Ben Thompson，他经营着一个叫 Stratechery 的科技分析网站，经常写一些关于互联网公司战略的文章。他提出一个很清晰的框架，说聚合器有三个特点。第一，它直接连接用户和供应商，中间没有其他环节。比如外卖平台直接连接你和餐厅，你不用通过任何中间人。第二，它把供应商变成标准化的商品，意思就是，供应商之间的差别变得不那么重要了。比如在订房网站上，所有酒店看起来都差不多，都有照片、价格、评分，你选哪家主要看价格和评分，而不是因为你和某家酒店有特殊关系。第三，它靠用户数据不断改进自己的服务，让用户体验越来越好，从而吸引更多用户，更多用户又吸引更多供应商，形成一个良性循环。
这三个特点里，最关键的是第二个，把供应商商品化。因为当供应商变得可以互相替代时，平台就拥有了谈判权。比如以前出租车司机可以自己决定去哪里拉客，但现在他们依赖叫车平台，因为平台带来了大部分订单。如果司机不听话，平台可以处罚他，甚至不给他派单。而用户呢，因为平台上的选择很多，也不太在乎是哪位司机来服务。这样一来，权力就从供应商转移到了平台手里。作者用谷歌和 Facebook 举例，说它们也是聚合器，因为它们聚合了网页和社交内容，而内容创作者为了流量不得不依赖它们。
但聚合器不是凭空出现的，它需要满足一些条件。文章说，聚合器的出现是因为互联网降低了交易成本，让用户和供应商可以直接连接。在互联网之前，像旅行社这样的中介也存在，但它们没有成为聚合器，因为它们的服务是人工的，不能规模化。而互联网公司可以写代码，让服务自动运行，边际成本几乎为零。比如外卖平台开发一个应用，可以服务千万用户，而旅行社需要雇很多人来接电话。所以聚合器的本质是，用技术替代了人工中介，并且在这个过程中，把供应商变成了可替换的零件。
这篇文章的价值在于，它解释了我们生活中很多看似平常的现象，比如为什么平台总是免费给我们用，为什么平台对商家越来越苛刻，为什么新的竞争者很难挑战这些平台。它让我们看到，聚合器的力量来自于网络效应和数据的积累，一旦形成规模，后来者就很难打破。对于没有商业背景的读者来说，这篇文章可以帮你理解，为什么你经常使用的那些应用，会变得越来越强大，而它们底下的那些商家和司机，却越来越没有话语权。下次你打开外卖平台，看到满减活动，你可以想一想，这些优惠是谁在买单，是平台，还是餐厅？而餐厅为什么愿意参加，因为它们不参加就会被别的餐厅抢走生意。这就是聚合器带来的现实。
想象你是一家手机应用公司的负责人。过去半年，每个月的下载量都在涨，团队士气很高，投资人也很满意。可是这个月的数据出来，新增用户数和上个月几乎一样，甚至少了一点点。你告诉自己，可能是季节波动，下个月就好了。结果下个月还是没涨，再下个月甚至开始往下走。这时候你心里会冒出一个问题，我们是不是已经到顶了。Andrew Chen 的这篇文章，就是专门写给此刻的你。他见过太多产品在经历一段漂亮增长后突然停住，团队从兴奋变成焦虑，然后开始乱抓方向，有人怪市场，有人怪竞争对手，有人觉得是产品老了。但他想说的是，增长停滞往往不是产品不行了，而是你一直在用同一种方式拉新，而这条路已经走到头了。
他先帮你想清楚一个关键区分，增长停滞和用户流失是两回事。流失是用户来了之后留不住，产品本身有问题。而增长停滞，说的是你获取新用户的能力变弱了。比如你一直靠某一种渠道拉人，可能是搜索引擎广告，可能是应用商店推荐，也可能是某个大网红带货。这个渠道一开始很有效，因为它便宜，竞争少，你的广告一放出去就能被看到。但时间一长，同类的产品都涌进来，广告价格被抬高，平台算法也变了，你的获客成本越来越高，最终高到每拉来一个新用户，赚的钱还不够付广告费。这时候增长自然就停了。文章里有个比喻我记得很清楚，他说增长就像往杯子里倒水，一开始杯子空，倒多少都能接住，但杯子快满的时候，再倒就溢出来了。你需要的不是继续倒水，而是换一个更大的杯子，或者换一种倒法。
那具体该怎么做呢。Andrew 给了几个方向，但核心思路是，不要只盯着拉新，要回头看看你已经拥有的用户。他说很多产品在增长顺利的时候，会把所有精力都放在怎么让更多人进来，却忘了检查进来的这些人到底有没有真正用起来。他提到一个概念叫激活（activation），意思是用户第一次使用产品时，有没有在短时间内体验到产品的价值。比如你做一个健身应用，用户下载后如果只是浏览了一下界面就关掉了，那他就不会再来。但如果他在第一天就完成了一次训练，哪怕只有十分钟，他留下来的概率就会大很多。所以当增长停滞时，你可以试着优化这个首次体验，让新用户更快地感受到产品的好处。这听起来不像什么大动作，但往往能带来意想不到的效果。他还提到另一个思路，就是重新审视你的核心用户群。你可能一直以为你的用户是年轻人，但数据可能告诉你，真正留下来的是三十多岁的人。这时候你要做的不是继续去拉年轻人，而是围绕这些真正喜欢你的用户做文章，让他们用得更多，甚至帮你传播。
文章里还有一个特别重要的提醒，就是不要被总量迷惑。他说有时候总用户数还在涨，但新用户的质量在下降，比如他们来了之后很少使用，或者很快就卸载。这种增长是虚的，就像往一个漏水的桶里倒水，倒得快漏得也快。真正健康的增长，是每个新用户都能留下来，并且持续使用。所以当增长停滞时，你可以把目标从拉新数量改成留存率，也就是一段时间后还剩下多少用户。这个指标比单纯的新增数更能反映产品的真实健康度。他建议团队把精力放在改善留存上，比如通过邮件提醒、推送通知、或者产品内的激励，让用户养成使用习惯。一旦留存上去了，即使拉新速度不变，总用户数也会稳步上升。
最后，Andrew 想让你明白，增长停滞不是终点，而是一个信号，提醒你该换一种方式思考了。他举了一些例子，比如有的产品在原有渠道失效后，转而做内容营销，通过写文章、做视频吸引用户；有的产品则开发了新功能，让老用户能邀请新用户，形成口碑传播。这些都不是什么惊天动地的创新，而是把注意力从外部拉回内部，从数量转向质量。读完这篇文章，你会觉得增长停滞并不可怕，可怕的是你慌了神，然后乱花钱去砸广告，或者干脆放弃。真正该做的，是冷静下来，看看数据，找出那个被你忽略的环节，可能是激活，可能是留存，也可能是你从未注意到的核心用户群。然后从那里开始，一点一点把增长重新拉起来。
你是一家创业公司的创始人，你的产品是一个给数据分析师用的工具，帮助他们把数据整理成可以分析的表格。一开始你发现，很多公司的数据散落在不同的地方，有的在数据库里，有的在 Excel 里，有的在云服务里，分析师每次都要花大量时间手动合并。你的工具就是把这些数据统一起来，让分析师可以直接查询。你做了几个月，上线了，但用户很少，只有几个技术爱好者偶尔用一下。你开始怀疑，是不是这个需求根本不存在。dbt Labs 的故事，就是从这个困境开始的。这家公司最初的产品是一个开源工具，意思是任何人都可以免费下载使用，代码也是公开的。他们发现，虽然用户不多，但每个用过的分析师都很喜欢，会在社交媒体上分享，甚至主动帮他们改进代码。这让他们意识到，自己可能找到了一个真实的需求，只是还没有找到正确的商业模式。
文章里详细讲述了他们如何一步步走向产品市场匹配（product-market fit），也就是你的产品正好满足了一群人的强烈需求，他们不仅愿意用，还愿意付钱。这个过程不是一次就完成的。他们最早以为用户是数据分析师个人，后来发现真正愿意付钱的是团队，因为个人用户可以用免费版，但团队需要协作功能，比如共享数据模型、统一管理权限。于是他们开始推出付费的企业版。但这时候又遇到一个问题，企业客户虽然感兴趣，但他们的数据基础设施很复杂，你的工具要接入他们的系统，需要处理各种不同的数据库、数据格式，还要保证安全。很多企业客户在试用后说，这个工具很好，但我们目前还不敢把核心数据交给你。这让他们明白，光有好的产品还不够，还需要解决信任和集成的问题。
接下来他们做了一个关键决定，就是专注于一个特定的用户群体，也就是那些已经在使用云数据仓库的公司。数据仓库（data warehouse）你可以理解成一个专门存放公司所有数据的巨型仓库，方便分析。这类公司通常比较现代，愿意接受新技术。dbt 就把自己的工具打造成这个仓库的标配，让分析师可以直接在仓库里进行数据转换。这样一来，他们的产品就变得不可或缺，因为一旦你的数据都在仓库里，而 dbt 又是唯一好用的转换工具，那你就离不开它了。他们还建立了社区，让用户互相帮助，分享使用技巧，甚至贡献代码。这个社区成了他们最大的护城河，因为别的公司很难复制这种由用户驱动的生态。
文章里还提到一个很有意思的细节，就是他们如何定义自己的客户。他们不把自己当成一个卖软件的公司，而是当成一个帮助分析师提升工作效率的伙伴。他们甚至免费提供很多教育内容，教分析师怎么更好地处理数据。这样一来，他们不仅获得了用户的信任，还培养了一批忠实粉丝。当这些分析师升职或者换工作，他们会把 dbt 带到新的公司，从而带来更多客户。这种增长方式很慢，但非常扎实。最终，他们找到了那个让产品真正起飞的市场，并且建立了一套完整的商业模式，从开源免费版到付费的企业版，再到提供咨询和培训服务。
读完这篇文章，你会发现产品市场匹配不是一个静态的目标，而是一个不断调整的过程。你可能会经历多次尝试，一开始以为找到了，后来发现不对，然后继续摸索。dbt Labs 的成功，不是因为他们一开始就设计好了完美的产品，而是因为他们愿意倾听用户，不断迭代，并且找到了一个足够大的市场。他们的故事告诉我们，当你的产品增长停滞时，不要急着加新功能，而是回头看看，你真正服务的是谁，他们为什么离不开你。有时候，答案就在那些最热情的用户身上。
很多人以为产品经理（product manager）就是开会、催进度、传话的人，但真正做过这份工作的人知道，产品经理的核心职责是把一个模糊的想法变成一群人能用的东西。这篇文章讲的是产品经理最重要的交付物（deliverables），也就是他们必须产出的那些文档、图表和决策记录。你可以把产品经理想象成一个翻译，把用户的需求翻译成工程师能写的代码，把商业目标翻译成设计能画的原型，把老板的愿景翻译成团队能执行的计划。没有这些交付物，团队就会像没有地图的探险队，每个人都在走，但方向不同。
文章把交付物分成几类，从愿景到战略，再到具体的执行计划。愿景（vision）是产品最终想成为的样子，比如“让每个人都能轻松管理自己的财务”。战略（strategy）是选择做什么和不做什么，比如“先服务年轻用户，不服务企业”。洞察（insight）是对用户和市场的深刻理解，比如“用户不是缺记账工具，而是缺坚持的动力”。执行（execution）是把计划变成实际功能，比如“下个季度上线自动分类功能”。这些词听起来抽象，但每个都对应着具体的工作。比如愿景不是一句口号，而是一个文档，里面描述了未来三到五年产品会解决什么问题，用户会怎么使用它。战略不是空谈，而是一个决策清单，写清楚我们为什么做这个而不做那个。洞察不是感觉，而是来自用户访谈、数据分析、市场调研的证据。执行不是“赶紧做”，而是拆解成任务、排期、责任人的计划。
文章里特别强调，产品经理的交付物不是给自己看的，而是给团队、给上级、给跨部门同事看的。比如一份好的产品需求文档（PRD，product requirements document）要写清楚功能的目标、用户场景、验收标准，让工程师不用反复追问“这个按钮点了之后发生什么”。一份好的路线图（roadmap）要展示未来几个季度的优先级，让销售知道什么时候能承诺客户，让市场知道什么时候能开始宣传。如果这些交付物写得含糊，团队就会浪费大量时间在会议上争论“用户到底想要什么”或者“这个功能做出来有什么用”。所以产品经理的写作能力，其实比很多人以为的重要得多。
这篇文章的价值在于，它把产品经理的工作从“感觉”变成了“可检查的产出”。如果你不是产品经理，读这篇文章也能理解为什么很多公司产品做得差，往往不是工程师不行，而是产品经理没有产出清晰的交付物，导致团队各自为政。如果你正在考虑进入产品行业，这篇文章会告诉你，你需要修炼的不是“点子多”，而是把点子变成文档、把文档变成计划、把计划变成现实的能力。读完你带走的判断是，产品经理的交付物就是他们的作品，就像画家的画、作家的书，质量高低决定了产品的命运。
你有没有注意过，朋友圈里转得最多的，往往不是最准确的消息，而是最让人惊讶、最让人想立刻转给别人的消息。一条新闻说某个明星离婚了，你可能会随手转发，但一篇分析某个政策对经济影响的深度文章，哪怕写得再好，你也多半只是自己看完，很少会特意分享到群里。这不是因为你不在乎真相，而是因为人的分享冲动，和信息的真假、深浅，其实关系不大。这篇文章讨论的正是这个现象，它想弄明白一件事，为什么事实（facts）传播起来总是又慢又少，而那些情绪化、标签化、甚至不准确的内容，却像长了翅膀一样到处飞。
作者提出了一个很直观的框架，他把信息分成两类。一类是“高成本”的，意思是你要理解它、消化它，得花很多时间和脑力，比如一篇关于经济周期的分析，你得先弄懂什么是利率，什么是通货膨胀，还得跟着作者的逻辑走，读完可能还要想一会儿。另一类是“低成本”的，比如一张搞笑的图片，一句口号式的判断，或者一个耸人听闻的标题，你几乎不用动脑就能看懂，而且它自带情绪，让你立刻觉得“对，就是这样”，于是你顺手就转发了。事实恰恰属于高成本那一类，它往往需要铺垫背景，需要承认复杂性，甚至可能推翻你原本相信的东西，所以它天然不讨喜。
文章里还用了一个很形象的比喻，说传播就像一种社交货币（social currency），你转发一条内容，其实是在向别人展示你是什么样的人。你转一篇深度分析，是想显得自己有思想，但这有风险，万一别人觉得你枯燥、说教，甚至看不懂，那这笔社交投资就亏了。而转一条有趣的段子，成本很低，大家都能笑，你显得随和、有趣，回报却很确定。所以事实在社交货币的市场上，是一种面值很高但很难找零的货币，别人不一定愿意收。
作者还提到了一个关键概念，叫“可传播性”（virality），它不取决于内容本身的价值，而取决于它能不能在几秒钟内抓住人的注意力，并且让人产生一种“我必须马上告诉别人”的冲动。事实往往做不到这一点，因为它需要解释，而解释会拖慢节奏。比如你看到一条数据说“过去十年全球肥胖率上升了30%”，你可能会觉得有道理，但不会立刻转发，因为你需要想一想这数据从哪来的，是不是有误导性。但如果有人发一张对比图，左边是十年前的食物，右边是现在的食物，配上一句“我们吃的东西变了”，你反而可能马上转发，因为那种视觉冲击和情绪共鸣，瞬间就完成了。
这篇文章并不是说事实不重要，而是在提醒我们，如果你想让重要的、准确的信息被更多人看到，就不能只靠内容本身，你得想办法降低它的传播成本，比如把它包装成更容易消化的形式，或者搭上情绪的快车。但作者也承认，这很难，因为事实的复杂性本身，就是它可信的根源，你把它简化了，可能就失真了。所以这是一个两难，追求真相，可能就要接受它传播得慢；追求传播，可能就要牺牲一些准确性。
读完之后你会明白，我们每天看到的信息洪流，其实是一场关于注意力的竞赛，而事实往往在这场竞赛中跑得很吃力。这不是某个平台或某个人的错，而是人类社交心理的必然结果。下次当你看到一条让你热血沸腾的消息时，不妨停下来想一想，它是不是太容易让你相信了，而真正值得你花时间去理解和传播的，可能是那些让你觉得有点累、有点复杂、甚至有点不舒服的内容。那才是事实常待的地方。
很多做产品的人，尤其是做技术产品的人，都遇到过这样一种情况。他们心里有一张很清楚的路线图，知道自己的软件要解决什么问题，也知道该按什么顺序把功能做出来。他们甚至花了很多时间跟客户聊，把客户的反馈一条条记下来，然后回去加班加点开发。等到产品终于上线，他们却发现客户并没有像预期那样高兴，甚至有些客户干脆不用了。问题出在哪里呢？这篇文章想说的就是，产品策略在真实世界里常常会失效，而失效的原因往往不是技术不够好，也不是团队不够努力，而是策略本身建立在一些错误的假设上。
文章里讲了一个很典型的例子，是关于一个做高度技术性产品的公司。这类产品的特点是，客户自己往往也不是特别清楚他们到底需要什么，因为他们对技术的理解有限。比如一个做数据存储的公司，客户说他们想要更快的数据读取速度，但真实的需求可能是他们不想花太多精力去管理存储系统。如果产品团队只听表面的话，就会拼命去优化读取速度，结果做出来的东西虽然技术上很厉害，却没能解决客户真正头疼的问题。这就是产品策略在现实中的第一个陷阱，把客户说的话当成他们真实的需求。
另一个陷阱是，产品团队常常会为了满足一个客户的特殊要求，而偏离了原本的方向。文章里提到，一个客户可能会提出一个很具体的功能，说这个功能对他们至关重要。团队为了拿下这个客户，就投入大量资源去做这个功能，结果这个功能只对这一个客户有用，其他客户根本用不上。这样一来，产品变得越来越复杂，越来越难用，而真正核心的价值却被稀释了。这就像一个人本来要开一家家常菜馆，结果为了留住一个爱吃西餐的客人，专门学了一堆西餐做法，最后菜单变得不伦不类，回头客反而少了。
还有一个问题是，技术产品团队常常高估了客户对技术的接受度。他们自己每天跟代码打交道，觉得某些功能很直观，但客户打开软件时可能完全不知道该怎么操作。文章里举了一个例子，一个产品为了让用户能自定义界面，提供了很多选项，结果大多数用户根本不去碰那些选项，因为他们觉得太复杂了。团队以为自己在给用户自由，实际上是在给用户增加负担。产品策略在真实世界里要面对的，不是理想中的用户，而是那些忙碌、不耐烦、只想赶紧干完活的普通人。
那该怎么办呢？文章给出的建议是，产品团队需要更早地、更频繁地把产品拿到真实用户面前，而不是等到功能都做完了才测试。而且要注意观察用户实际怎么用，而不是听他们怎么说。比如一个用户说想要一个按钮，但实际使用中他可能根本不会去点那个按钮，而是用别的方式完成了任务。这时候团队就该思考，是不是那个按钮本来就不该做。产品策略不是一次性的规划，而是一个不断根据现实反馈调整的过程。
读完这篇文章，我最大的感受是，做产品就像在雾里开车，你只能看清前面一小段路，但你必须不断根据路况调整方向盘。那些一开始就定死的策略，往往会在第一公里就撞上护栏。真正能让产品活下来的，不是完美的计划，而是愿意放下自己的假设，去倾听现实里那些微小的、不完美的声音。
很多人都有过这样的时刻，脑子里同时转着好几个念头，想写点东西，想理清一个想法，可一打开电脑里的文档软件，看到空白的页面，那些念头反而缩回去了。我们常用的工具，不管是写字的还是画图的，都像一张纸，只能平铺着放东西。你写了一段，画了个草图，想把它挪到旁边对比一下，想把它转个方向再看，都特别费劲。这篇文章讲的是一款叫 Muse 的软件，它想解决的就是这个问题，让想法能在一个更像真实桌面的空间里被摆弄、被翻看、被连接起来。文章来自一个叫 Ink & Switch 的研究机构，他们不急着做商业产品，而是先研究人怎么思考，再设计工具。
你可以想象一下，平时我们在纸上画思维导图，或者用便利贴贴满一面墙，那种感觉是自由的，因为你可以随手把一张纸条拿起来，放到另一个地方，可以斜着贴，可以叠着放。但电脑上的工具，大多还是按着文档的逻辑来，一行一行，一页一页，像写作文一样。Muse 想做的是把便利贴墙搬到屏幕上，而且做得更灵活。它用了一种叫空间化界面（spatial interface）的设计，意思是信息不再按顺序排列，而是放在一个二维甚至三维的空间里，你可以自由移动它们，就像在房间里走动一样。
文章中讲了一个很具体的例子，是作者在构思一篇文章或一个演讲时的过程。他先在 Muse 里放了一张卡片，写下一个核心观点，然后又在旁边放了几张卡片，记下相关的例子、数据、甚至一些零碎的感想。这些卡片可以随意拖动，可以放大缩小，还可以用线条把它们连起来，表示它们之间的关系。最妙的是，当你把一张卡片翻过来，背面还能写东西，就像真实的卡片一样。这种设计让思考不再是线性的，你可以从任何一个点开始，然后慢慢把碎片拼起来。
Muse 还有一个特别的设计，叫无限画布（infinite canvas）。你不用担心空间不够，可以一直往下扩展，往旁边扩展。这听起来好像只是技术上的方便，但其实对思考方式有很深的影响。因为当你不用担心空间限制时，你就更愿意把脑子里那些模糊的、不完整的想法先放上去，哪怕它们看起来乱糟糟的。这就像整理房间，如果柜子很大，你就愿意把东西先摊出来看看，再慢慢归类。如果柜子很小，你只能把东西硬塞进去，反而找不到。
但 Muse 不只是让你把想法摆出来，它还想帮你把想法变成更成熟的东西。文章里提到，Muse 有一个功能叫生成式重排（generative reordering），听起来很玄，其实就是软件能根据你卡片上的内容，自动帮你把相关的卡片聚在一起，或者帮你找到可能遗漏的联系。这背后用到了人工智能（AI），但作者强调，AI 在这里不是代替你思考，而是像一个聪明的助手，帮你整理桌面，提醒你“这两张卡片好像都在讲同一件事”。这种设计很谨慎，它不想让 AI 抢走你的主导权，而是让你感觉自己在控制一切。
文章里还讲了一个关于“思考工具”的历史，从早期的纸笔，到后来的电脑文档，再到现在的各种笔记软件。作者指出，很多工具只是把纸上的东西数字化，却没有真正利用电脑的能力，比如动态调整、即时反馈、多维度连接。Muse 想做的，是重新思考“思考”这个动作本身。当你写作时，你是在把想法变成文字，但当你在 Muse 里移动卡片时，你是在用身体感知想法的结构，这种身体参与会让记忆更深刻，理解也更透彻。这让我想到，有时候我们整理房间，其实也是在整理思绪，把东西放到合适的位置，心里就清爽了。
这篇文章的读者可能不是程序员或设计师，而是任何一个需要和想法打交道的人，比如写方案的白领、做研究的学者、甚至准备演讲的人。它讲的不是技术细节，而是我们每天都会遇到的困境，想法太多理不清，工具太死板不好用。Muse 给出的答案，不是让你更努力地去组织，而是让你更自由地去探索。它像一间专门为想法设计的房间，你走进去，可以随意摆放家具，可以重新装修墙壁，而不用担心弄坏什么。这种自由，恰恰是创造力的土壤。读完之后，你会开始留意自己平时用什么工具想事情，是不是被工具限制住了，也许你会想，如果我的桌面也能像 Muse 那样，我是不是就能想出更好的点子。
先想一个很普通的场景。你在一家小公司上班，每天要处理一堆报销单。以前你得打开一个专门的财务软件，点开一个个表单，手动填上日期、金额、事由，再上传发票照片。这个软件是公司花钱买的，按人头收费，一年下来不少钱。但你觉得它挺好用，因为流程清楚，不会出错。现在假设有一家新公司推出一个工具，它不要求你填表，你只要把发票照片发过去，它自动帮你生成报销单，甚至帮你检查有没有超预算。你可能会想，这不就是把原来那个软件的活给干了吗，而且干得更轻松。那原来的财务软件公司靠什么赚钱呢，它们卖的就是那个填表的流程，那个需要人学习、需要公司维护的界面。如果新工具把这些都省了，原来的软件就变得不那么值钱了。这就是这篇文章想说的核心，人工智能正在把原来藏在软件里的那些操作步骤给吃掉，而软件公司赖以生存的收费方式，可能也要跟着变。
文章来自一家叫安德森霍洛维茨（a16z）的风险投资公司，这家公司专门投资科技创业公司，也经常发表对行业趋势的看法。文章标题是“人工智能会吃掉应用软件”，这里的“吃”不是把软件消灭，而是把软件里最值钱的那部分功能，也就是帮人完成具体任务的工作流，给接管过去。过去几十年，软件公司卖的是“工具”，你用工具来干活，工具本身要钱。比如文字处理软件、表格软件、项目管理软件，你买的是那个界面，那个功能列表。但人工智能不一样，它更像一个“员工”，你告诉它目标，它自己想办法完成。比如你让它整理会议记录，它不只是给你一个空白的记事本，而是直接听录音、提炼要点、生成待办事项，甚至帮你把邮件发出去。这样一来，你需要的就不再是那个记事本软件，而是一个能替你完成整个任务的服务。
文章里提到一个关键概念，叫“软件吞噬世界”，这是很多年前流行的一句话，意思是各行各业都在被软件改造，比如出租车被打车软件改造，酒店被订房软件改造。现在文章说，人工智能要吞噬的是软件本身。原来软件公司靠卖许可证或者订阅赚钱，现在人工智能公司可以按结果收费，比如你每处理一个报销单收一点钱，或者按节省的时间收费。这对创业公司来说是个好消息，因为它们不用再像以前那样，花好几年时间打磨一个功能齐全的软件，再慢慢卖给企业。它们可以一开始就只做一个小功能，用人工智能把它做到极致，然后直接收钱。比如一个专门帮律师写合同摘要的工具，或者一个帮医生整理病历的工具，这些工具不需要复杂的界面，只需要一个对话框，背后是强大的人工智能模型。
但这也带来一个问题，就是那些老牌的软件公司怎么办。它们花了十几年建立的用户习惯和销售渠道，可能在一夜之间变得不重要。就像当年数码相机取代胶卷，柯达公司明明发明了数码相机，却因为舍不得放弃胶卷的利润，最后被市场抛弃。现在那些靠卖软件功能赚钱的公司，也面临类似的选择，要么自己用人工智能改造产品，要么看着新公司用人工智能把客户抢走。文章里有一个比喻，说应用软件就像一层皮，人工智能是下面的肌肉，以前肌肉要适应皮，以后皮要适应肌肉。也就是说，软件公司不能再想着先做一套软件，再让人工智能来配合，而是应该让人工智能决定软件长什么样，甚至软件本身都不需要了，只要有人工智能服务就够了。
这篇文章读下来的感觉，不是预言世界末日，而是提醒我们，科技行业的价值正在从“工具”转向“服务”。对于普通人来说，这意味着以后我们使用电脑和手机的方式会越来越像跟人说话，而不是点按钮。对于创业者来说，这意味着机会更多，因为不需要很大的团队就能做出有价值的产品。对于老牌公司来说，这意味着必须快速改变，否则就会被淘汰。最后你可能会想，那我自己用的软件会怎样，其实你已经能感觉到，比如手机里的语音助手越来越聪明，它不只是帮你设闹钟，还能帮你订外卖，这就是人工智能在吃掉应用软件的例子。未来，我们可能不再需要安装那么多应用，只要有一个超级智能助手，它就能替我们完成所有事。这听起来很方便，但也让我们思考，如果软件都被吃掉了，那谁在背后控制这些人工智能呢，这可能才是真正重要的问题。
设想你开了一家小餐馆，做的是附近街坊的生意。你花了很多心思研究菜谱，装修店面，还请了服务员。刚开始，来的客人不多，你不知道是菜不好吃，还是位置太偏，或者价格定高了。你试了几次调整菜单，有时候换招牌菜，有时候降价，但生意还是不见起色。直到有一天，你发现一个奇怪的现象，有些客人一周来三四次，而且每次都点同一道菜。你开始琢磨，也许这道菜就是你的招牌，也许这些回头客才是你真正该服务的对象。你不再想着讨好所有人，而是把这道菜做得更好，让这些老客人更满意。慢慢地，他们开始带朋友来，朋友又带朋友，你的餐馆终于稳定下来。这个过程，就是这篇文章讲的“产品市场匹配”（product-market fit）。简单说，就是你做的产品，正好满足了一群人的强烈需求，他们不仅自己用，还愿意推荐给别人。
这篇文章的作者叫凯西·温特斯（Casey Winters），他是一位很有经验的产品增长专家，曾经在多家知名互联网公司工作，比如拼趣（Pinterest）和爱彼迎（Airbnb）。他写这篇指南，是想分享自己多年来寻找产品市场匹配的方法。文章里强调，产品市场匹配不是一个模糊的感觉，而是可以用数据来测量的，最重要的指标就是“留存”（retention），也就是用户用了一次之后，还会不会继续用。比如你的餐馆，如果客人来了一次就再也不来，那说明你的菜或者服务有问题。如果客人每周都来，那说明你找到了匹配。留存曲线是衡量匹配的关键工具，它画的是用户使用频率随时间的变化。如果你画出的曲线是平的，甚至往上升，说明用户留下来；如果曲线一直往下掉，说明用户流失了。凯西说，很多创业公司过早地开始花钱做推广，拉来很多新用户，但留存很差，最后昙花一现。正确的做法是先打磨产品，直到留存曲线变平，再考虑增长。
文章里还讲了怎么找到那些“回头客”的特征。凯西建议，不要只看所有用户的平均数据，而是要区分“核心用户”和“边缘用户”。核心用户是那些使用频率高、从产品中获得价值最大的人。比如一个社区软件，核心用户可能是那些每天发帖、回复、交朋友的人，而边缘用户可能只是偶尔来看看。你要想办法让更多新用户变成核心用户，而不是试图满足所有人的需求。他举了一个例子，比如一个社交应用，刚开始可能吸引了很多好奇的游客，但真正留下来的是那些能在这里找到归属感的人。你要观察这些核心用户在做什么，然后强化那些功能。他还提到一个概念叫“增长机制”（growth loop），就是说产品本身要能带来新用户，比如用户邀请朋友、内容被分享，这样不用花太多广告费就能持续增长。但前提是，产品已经让现有用户足够满意，他们才愿意分享。
这篇文章不是那种一夜成名的秘籍，而是像一本实操手册，告诉你一步步怎么分析数据、做实验、调整产品。凯西特别强调，产品市场匹配不是一次性的，而是动态的，因为市场和用户需求会变。比如你的餐馆，可能过几年街坊搬走了，你需要重新调整菜单来吸引新的人群。同样，互联网产品也需要不断迭代，才能保持匹配。他还提醒创业者，不要只盯着功能数量，而是要关注用户是否真的完成了某个核心任务。比如一个记账软件，如果用户记了一笔账就再也不用，那功能再多也没用。你要找到那个让用户“啊哈”的时刻，也就是用户第一次感受到产品价值的那一刻。对于记账软件，可能是用户看到自动生成的图表，突然觉得自己的财务状况一目了然。你的工作就是让更多用户尽快体验到那个时刻。
读完这篇文章，你会明白，创业不是赌博，而是有方法可循的。你不需要一开始就做出完美的产品，但你需要尽早验证是否有人真正需要它。最好的验证方式不是问用户“你觉得怎么样”，而是看他们是否真的在用，用了之后是否留下来。留存曲线就是你的成绩单。如果你发现留存不好，不要急着推广，而是回去研究用户行为，找到问题所在。有时候，问题不在产品功能，而在你选错了目标用户。比如你本来想服务所有人，结果发现只有一类人特别喜欢你，那你就应该调整方向，专门服务他们。文章最后给人的感觉是，产品市场匹配是一个持续探索的过程，就像在黑暗中摸索，但你有地图和工具，只要坚持用数据说话，就能找到那扇门。对于任何想创业或者做产品的人来说，这篇文章值得反复读，因为它是过来人用血泪总结出来的经验。
很多做产品的人都会遇到一个特别让人沮丧的场景。你花了很多力气做推广，用户也来了，看起来下载量、注册量都在涨，但没过多久，这些人就悄悄消失了。你再去拉新，成本却越来越高，就像往一个漏水的桶里倒水，怎么倒都装不满。这篇文章想讨论的正是这个现象，它来自一位长期观察科技公司增长的作者，他提出了一个和直觉相反的观点，留住用户才是让产品自己传播起来的真正引擎。
我们先看一个日常生活中的例子。假设你开了一家小餐厅，每天都有新顾客来尝鲜，但大部分人来一次就不再来了，只有少数几个熟客。你会怎么做？你可能会觉得，得继续打广告、搞优惠，把新顾客吸引进来。但作者说，你更应该做的是让那些熟客更满意，让他们每周都想来，甚至想带朋友来。因为一个满意的熟客，不只是自己来，他还会在朋友圈晒照片，会跟同事推荐，这种由真实体验带来的口碑，比任何广告都管用。
在产品世界里，这个道理同样成立。文章里讲到了留存（retention），就是用户用了你的产品之后，还会不会继续用。如果你只关注拉新，忽略留存，就好比餐厅只招揽新客，却不管菜品和服务，那么无论花多少钱，用户都会流失。而传播（virality）看起来是用户帮你带来新用户，但它的源头其实是用户对你的产品有足够深的喜爱和习惯。一个用户如果每天都用你的产品，他自然会在聊天时提到它，会在需要时推荐给别人，这种由内而外的分享，比任何强制分享的机制都更持久。
作者用了一个很形象的比喻，把留存和传播比作一个飞轮。当你的产品让用户感到满意，他们就会留下来，并且因为用得频繁，他们就会在社交场合中自然提及，从而带来新用户。新用户如果也觉得好，又会留下来，继续传播，这样飞轮就越转越快。反过来，如果你只盯着拉新，却不管用户是否真的喜欢，那么飞轮就转不起来，你只能一直用钱去推，一旦停止投入，增长就停了。
文章里还提到了一个关键概念，叫参与度（engagement），也就是用户和产品互动的深度和频率。比如一个社交软件，如果用户只是注册了但从不发消息，那参与度就很低，他很快就会忘记这个软件。而如果用户每天都来发消息、看动态，那参与度就很高，他不仅自己离不开，还会邀请朋友来一起玩。所以，与其设计各种花哨的邀请奖励，不如把精力放在让用户更投入上。
这篇文章的启发是，如果你在做产品，或者哪怕只是开个小店，都应该先问问自己，用户为什么愿意留下来，而不是只想着怎么把人拉进来。真正的增长不是靠技巧，而是靠你为用户创造了多少实实在在的价值。当用户觉得你的产品好用、有用、有趣，他们就会成为你的传播者，这种增长才是可持续的。读完这篇文章，你会明白，与其到处找增长秘籍，不如静下心来，把产品做到让用户离不开。
你有没有想过，为什么现在很多行业里，赚钱的越来越集中在少数几个大公司手里，而其他小公司却很难生存？比如，以前我们买书要去书店，书店有进货渠道，有店面，它们靠卖书赚钱。但现在，我们买书大多在亚马逊上，亚马逊不仅卖书，还把其他书店的生意都抢走了。这背后有一个很厉害的理论，叫做聚合理论（Aggregation Theory），它解释了一种强大的商业力量是如何改变整个行业的。
这篇文章来自一个叫做Stratechery的科技分析网站，作者用这个理论来解释互联网时代巨头崛起的原因。他说的聚合，指的是那些平台公司，比如谷歌、亚马逊、优步，它们做的事情是把供给端和需求端连接起来。供给端就是提供产品或服务的人，比如卖书的商家、开车的司机；需求端就是消费者，比如我们这些想买书、想打车的人。以前，这些平台是不存在的，我们得自己去找书店、在路边拦出租车。现在，我们只需要打开一个应用，就能得到所有选择。
这个理论的关键在于，这些聚合平台控制了用户关系。它们不是直接生产产品，而是让用户通过它们来接触产品。一旦用户习惯了用谷歌搜索，用亚马逊购物，用优步叫车，这些平台就成了用户和世界之间的一个必经之门。它们手里握着海量的用户数据，知道你喜欢什么，你的地址在哪，你经常去哪，这些信息让它们能提供更个性化的服务，也让其他公司更难进入这个市场。
文章里举了一个很生动的例子，关于新闻行业。以前，我们看新闻是买报纸，报纸上有各种记者的文章，报纸通过发行赚钱，广告商通过报纸投放广告。但后来，像谷歌和Facebook这样的平台出现了，它们把新闻内容聚合起来，用户不再需要访问每个报纸的网站，而是在平台上就能看到所有新闻。这样一来，报纸失去了和读者的直接联系，它们变成了内容的供应商，而平台成了分发渠道。广告收入也大量流向了平台，因为广告商知道用户都聚集在平台上。
这个理论还解释了为什么很多传统企业会感到恐惧。比如，汽车制造商以前是行业的主导者，但现在它们担心谷歌和苹果会进入汽车领域，因为那些科技公司更懂用户，更懂如何聚合服务。如果未来我们叫车都不需要自己开车，而是用自动驾驶汽车，那汽车制造商可能就变成了给这些平台提供车辆的供应商，利润自然就变薄了。
聚合理论的核心是，谁掌握了用户，谁就掌握了话语权。而掌握用户的方式，不是靠制造产品，而是靠提供一种便捷的、一站式的服务，让用户离不开。这听起来有点残酷，但这就是现实。对于普通消费者来说，我们享受到了前所未有的便利，但对于那些不掌握用户关系的企业来说，生存变得越来越难。读完这篇文章，你会对身边那些巨头公司的运作方式有更深的理解，也会明白为什么它们如此强大，以及为什么创新越来越难。
想象你住在一个小镇上，镇中心是热闹的广场，所有商店、学校和政府大楼都集中在那里。但你的家在镇子的边缘，再往外走就是田野和树林。每天你要去广场办事，都要穿过一段没有铺好的路，那里没有路灯，也没有路牌，走起来磕磕绊绊，但你很清楚，那里才是你生活真正开始的地方。Frank Chimero 这篇文章说的“边境地带”（borderlands），就是这样一个地方，它指的是那些没有被主流设计规则完全覆盖的区域，比如网页从电脑屏幕跳到手机屏幕的过渡地带，或者一个产品从桌面版变成移动版时产生的空白。他提醒我们，设计工作往往不是发生在规则的中央，而是发生在这种模糊、不稳定的边缘，而恰恰是这些地方，最能考验一个设计师的直觉和判断力。
文章开头，Chimero 讲了一个他自己遇到的例子。他给一个客户做网站，客户坚持要一个非常宽的设计，宽到在普通电脑屏幕上需要横向滚动才能看全。这在当时的设计界几乎是个禁忌，因为大家都默认网页应该适应屏幕宽度，不应该让用户滚动。但客户有他的理由，他想要一个像海报一样的展示效果，让内容像一幅画一样铺开。Chimero 没有直接拒绝，而是开始思考，为什么我们会有“网页必须适应屏幕”这种默认规则？这个规则是从哪里来的？他意识到，这些规则其实是从印刷媒介继承过来的，因为印刷品有固定的页面尺寸，所以设计者习惯了在固定的框架里工作。但网页是一个流动的媒介，它没有固定的尺寸，它可以在任何大小的屏幕上显示，从手表到电视。所以，当媒介本身在变化时，那些从旧媒介借来的规则就开始失效，而失效的地方就是边境地带。
他进一步解释，边境地带并不是一个需要被填平的坑，而是一个充满可能性的空间。比如，一个网站既要在手机上看，又要在电脑上看，设计师不能简单地把同一个布局缩小或放大，因为那样会破坏内容的可读性。他提出了一个概念叫“响应式设计”（responsive design），这个词现在很常见，但当时还比较新。响应式设计的意思不是做两个网站，而是让同一个网站根据屏幕大小自动调整布局，就像水倒进不同形状的杯子里，会自然地改变形状。但 Chimero 强调，响应式设计不只是技术问题，它更是一种设计态度，它要求设计师放弃对完美尺寸的控制，转而接受不确定性，接受内容会在不同环境中以不同方式呈现。这就像在边境地带生活的人，他们必须学会适应不稳定的环境，而不是试图把环境改造成自己熟悉的样子。
这篇文章写于 2014 年，当时移动互联网刚刚兴起，很多设计师还在为“移动优先”（mobile-first）还是“桌面优先”争论不休。Chimero 的观点是，与其纠结于哪个优先，不如承认我们正处在一个多设备并存的时代，而设计的目标应该是让内容在任何设备上都能被舒适地阅读和使用。他用了很多比喻，比如“设计是给内容做衣服”，衣服要合身，但也要让穿衣服的人活动自如。他还提到，设计师的工作不是画漂亮的界面，而是建立一种关系，让内容、用户和环境之间能够和谐相处。这种关系在边境地带尤其重要，因为那里没有现成的规则，只能靠设计师的临场发挥。
读这篇文章，你会感受到一种对设计本质的思考，它超越了具体的工具和技术，关乎我们如何理解变化，如何在不稳定的世界中找到平衡。Chimero 没有给出一个简单的答案，而是邀请读者一起进入那个模糊地带，去观察、去感受、去试错。对于没有设计背景的人来说，这篇文章的价值在于，它让你看到设计不只是美化外观，更是一种解决问题的思维方式。当你下次打开一个网站，发现它在手机上比在电脑上更好用，或者反过来，你会明白那不是偶然，而是设计师在边境地带做出的选择。最终，你带走的判断是，真正的设计能力，不在于掌握多少规则，而在于当规则失效时，你能否依然做出让人感到舒适和自然的东西。
你有没有想过，为什么微信在中国几乎人人都在用，而国外的脸书（Facebook）虽然用户量巨大，却总被批评说增长乏力？这篇文章来自投资机构 NFX，他们专门研究一种叫“网络效应”（network effects）的现象，简单说，就是一个产品或服务的价值，会随着使用它的人增多而变大。比如电话，只有一个人有电话时，它毫无用处，但两个人、三个人、成千上万的人有了电话，它就越有用。社交网络就是这样，人越多，你越可能在里面找到朋友、家人、同事，你的内容越可能被看到，所以你就越离不开它。NFX 用这个框架来分析脸书，试图解释为什么它曾经如此强大，而现在又面临着什么挑战。
文章的核心观点是，脸书之所以能统治社交网络这么多年，是因为它建立了一个强大的“社交图谱”（social graph），这个图谱就是你和你所有朋友、家人、同事之间的关系网络。脸书让你把现实中的关系搬到线上，然后通过这个网络来分发内容，比如你朋友的动态、照片、新闻。这个图谱一旦建立，就很难被复制，因为你需要重新添加所有朋友，这太麻烦了。所以，脸书的护城河（moat，指防止竞争对手抢走用户的优势）就是你的社交关系本身。但 NFX 指出，这种优势正在被侵蚀。他们提到一个关键概念叫“兴趣图谱”（interest graph），就是基于你感兴趣的话题、爱好、内容来连接人，而不是基于你认识谁。比如，你在抖音上关注一个做菜的视频，是因为你喜欢做菜，而不是因为你认识那个博主。这种兴趣图谱建立起来更快，也更灵活，而且它不受地域和现实关系的限制。
NFX 用了一个比喻，说脸书就像一个巨大的城市广场，你可以在那里遇到熟人，但如果你想去一个专门的兴趣小组，比如养兰花或者玩滑板，你可能更愿意去一个专门的小社群，而不是在广场上大喊。这就是为什么像 TikTok（抖音国际版）这样的平台能迅速崛起，因为它们不是让你连接朋友，而是让你发现有趣的内容和陌生人，这种体验在脸书上很难实现，因为脸书的设计初衷是围绕你的社交关系，而不是你的兴趣。文章还提到了一个叫“冷启动”（cold start）的问题，就是新用户刚加入一个平台时，如果他的朋友都不在，他很难留下来。脸书当年通过校园推广解决了这个问题，让每个学校的学生都能找到同学，但今天的新平台，比如一些新兴的社交应用，往往需要靠内容推荐算法来留住用户，而不是靠社交关系。
另一个重要观点是，网络效应并不是一成不变的，它有不同类型，而且强度不同。NFX 把网络效应分为很多种，比如直接网络效应（direct network effects，指用户越多，产品对每个用户越有用）、间接网络效应（indirect network effects，指用户越多，第三方开发者越愿意为平台开发功能，从而吸引更多用户）、数据网络效应（data network effects，指用户越多，平台收集的数据越多，算法越聪明，产品越好用）等等。脸书最初拥有的是强大的直接和间接网络效应，因为人越多，越多人愿意在上面开发应用，比如游戏。但随着时间推移，这些效应开始减弱，因为社交关系已经饱和，而数据网络效应反而在别的平台（比如搜索引擎和推荐算法）上体现得更明显。脸书虽然也拥有大量数据，但它的数据主要用于广告定向，而不是改善用户的核心体验，所以数据网络效应没有充分发挥。
文章还讨论了脸书面临的另一个问题，就是“多归属”（multi-homing），指用户同时使用多个类似的平台。比如，你可能同时用脸书、Instagram（照片分享应用）和 WhatsApp（聊天工具），它们都是脸书公司的产品，但用户也可能同时用脸书和 TikTok。当用户可以在不同平台间自由切换时，脸书的竞争优势就被稀释了。NFX 认为，脸书的未来取决于它能否在兴趣图谱上发力，或者找到新的方式来强化它的社交图谱优势，比如在虚拟现实（VR）或增强现实（AR）领域，让社交体验更加沉浸和不可替代。但这些都是不确定的，因为技术变化太快。
读完这篇文章，你会明白，社交网络的竞争不是简单的功能比拼，而是结构性的。脸书的用户量虽然庞大，但它的核心资产是社交关系，而社交关系的价值正在被兴趣连接和算法推荐所挑战。对于普通人来说，这篇文章的意义在于，它让你理解为什么你会在不同的应用之间切换，为什么有些应用让你欲罢不能，而有些应用你装了就删。网络效应是一个隐藏的规则，它决定了哪些产品能赢，哪些产品会输。而脸书的例子告诉我们，即使曾经不可一世的巨头，也可能因为网络效应的变化而失去优势。你带走的判断是，一个平台的长期价值，不在于它有多少用户，而在于它能否持续创造一种让用户离不开的独特连接方式。
你开了一家小餐馆，生意不错，每天中午都坐满。你觉得自己找到了秘诀，于是开始加桌子、扩店面、延长营业时间。但你慢慢发现，不管怎么努力，每天卖出的饭数量好像卡在了一个数字上，再怎么加桌子也上不去。你以为是厨房不够快，是服务员不够多，但真正的原因可能是，你所在的街区中午出来吃饭的人就那么多，你的餐馆已经吃下了这个街区所有能来的客人。这就是这篇文章想讲的，一个看不见的天花板，作者把它叫做“隐形渐近线”（invisible asymptotes）。渐近线是数学里的词，意思是曲线无限靠近但永远碰不到的那条线，这里用来比喻一个产品用户数量的上限，这个上限不是你努力不够造成的，而是你选择的市场本身决定的。
作者 Eugene Wei 是硅谷的资深产品人，他写这篇文章是在 2018 年，但他讲的道理到现在依然成立。他举了很多例子，其中一个特别容易懂，就是社交产品的冷启动问题。想象你做了一个新的聊天软件，功能比微信好十倍，但你身边的朋友都在用微信，你一个人换过去没有任何意义，因为聊天需要对方也在。这种产品要增长，必须让一群人同时换过来，但现实中人们很难集体行动，所以这类产品往往卡在早期用户数上，这就是一个隐形渐近线。作者还提到，有些产品看起来用户很多，但每个用户只使用很浅的功能，比如一个拍照软件，用户只是偶尔打开拍一张，然后就走，这种使用深度也会形成一种渐近线，你很难让这些用户变成每天深度使用的核心用户。
文章里特别有意思的部分是把用户分层来看。作者说，每个产品都有不同类型的用户，有极少数的核心粉丝，他们会帮你宣传、提建议、忍受你的不完美；有大量的普通用户，他们只是偶尔用一下；还有中间层，他们比较活跃但不是狂热。隐形渐近线往往不是针对所有用户，而是针对某一层用户。比如一个专业工具软件，它的核心用户是专业人士，他们愿意付费、愿意学习复杂功能，但这类人全世界可能只有几万人，这就是这个产品的渐近线。如果你想让产品增长到几百万用户，你就必须吸引那些非专业人士，但一旦你为了他们简化功能，专业人士又会觉得不好用而离开，这就变成了一个两难。作者用“产品市场匹配”（product-market fit）这个概念来解释，匹配是指你的产品正好满足了一群人的强烈需求，匹配越好，增长越猛，但匹配也意味着你被限定在这群人里，你不可能同时匹配所有人群。
这篇文章最打动我的地方是它让你接受一个现实，不是所有产品都能无限增长，很多优秀的产品只是在一个小市场里做到了极致。作者说，创业者往往不愿意承认自己的市场很小，他们会不断加功能、改定位，试图扩大用户群，结果反而失去了原本喜欢他们的那批人。这就像那家小餐馆，如果你非要改成火锅店来吸引更多人，原来喜欢你的炒菜的客人可能就不来了。所以，识别你的隐形渐近线，反而是一种清醒，知道自己在哪里，能做什么，不能做什么，然后在这个范围内做到最好。读完之后你会明白，增长不是唯一的目标，找到属于你的那条渐近线，并安心地待在它下面，也是一种成功。
我们每天都在用各种软件，但很少去想，一个软件界面上为什么会有那么多按钮、颜色、线条和空白。有些软件打开就让人头疼，信息堆得像超市大甩卖，而有些软件虽然功能复杂，却让人感觉安静、顺手。Linear 是一家做项目协作工具的公司，很多科技团队用它的产品来安排任务、追踪进度。最近他们做了一次界面更新，想解决的问题就是，一个功能很多的产品，怎么才能让用户不觉得乱，反而觉得舒服。这篇文章讲的就是他们背后的思考，不涉及代码，只关乎我们每个人每天都会遇到的那种感受，当我们面对一个拥挤的屏幕时，心里那股烦躁从哪来，又怎么被安抚。
想象一下你是一个团队的项目经理，每天要盯着几十个任务，每个任务有状态、负责人、截止日期、评论、标签。如果界面把所有信息都平等地展示，每个任务都像一个装满东西的抽屉，你会觉得每个任务都重要，但每个都看不清。Linear 的做法是，先确定什么是当前最重要的。他们用了一个词叫“视觉层级”，意思是界面上不同元素的重要程度要有差别，重要的显眼，次要的退后。比如，一个任务的标题应该比它的评论更醒目，一个即将到期的任务应该比一个下周才做的任务更突出。这就像你在书桌上工作，如果所有文件都堆在一起，你没法专注；如果你把正在做的文件放在正中间，其他文件放在旁边，你就能集中精力。界面也是这样，它要帮你把注意力放在该放的地方。
但他们还发现，仅仅区分重要和次要还不够，关键是让这种区分变得“平静”。很多软件为了强调重要信息，会用刺眼的红色、闪烁的动画或者弹窗，结果用户反而更焦虑。Linear 的设计师说，他们要的不是强烈的刺激，而是“平静的界面”。什么意思呢？比如，一个任务快到期了，不是用红色感叹号吓你，而是用柔和的橙色和一个小进度条，让你心里有数但不恐慌。再比如，界面的背景色、线条粗细、间距大小，都经过调整，让整体看起来干净、均匀，像一间整理过的房间，而不是堆满杂物的仓库。他们甚至调整了字体的粗细和对比度，让文字容易读但不过分扎眼。这些细节你可能不会特别注意，但它们合在一起，决定了一个软件是让你待得下去，还是让你想关掉。
这篇文章的标题叫“为运动中的产品打造更平静的界面”，这里的“运动”指的是产品在不断变化，功能在增加，用户在成长，数据在流动。Linear 的挑战在于，他们的产品功能很多，但又要保持简单感。他们举了一个例子，关于任务列表。以前，每个任务行上可能有十几个图标，比如评论、附件、标签、操作菜单，虽然每个都有用，但看起来像地铁线路图，密密麻麻。他们决定把一些不常用的操作藏起来，只在你把鼠标悬停到那一行时才显示，或者放进一个统一的菜单里。这样，默认状态下，列表很干净，只有标题、状态和负责人，就像你只看到每个任务的“脸”，而不是它身上所有的口袋。当你需要操作时，你再靠近它，那些工具才出现。这就像在厨房，你只把常用的锅和铲子挂在墙上，其他调料和工具收进柜子里，要用时再拿。这样厨房看起来清爽，做饭时也不会手忙脚乱。
另一个有趣的点是，他们怎么处理“颜色”。很多项目管理工具会用不同颜色来标记不同项目或优先级，但颜色一多，就像霓虹灯，让人眼花。Linear 决定限制颜色的使用，把颜色留给真正需要区分的地方，比如某个任务的状态或标签，其他地方用黑、白、灰和一种主色调。这样，颜色就有了意义，而不是装饰。他们还说，他们刻意减少了“边框”的使用。以前，界面上每个区块都有线框，像画了格子，现在他们用间距和背景色来区分区块，让视觉更轻盈。这就像现代室内设计，不用墙隔断，而是用家具摆放和地毯来划分区域，空间显得更大，也更安静。
读完整篇文章，我最大的感受是，设计一个界面，其实是在设计人的注意力。我们每天被各种信息轰炸，软件应该帮助我们过滤噪音，而不是制造更多噪音。Linear 的这次更新，没有增加新功能，而是重新思考了如何把已有的功能呈现出来。他们追求的不是炫酷，而是“平静”，这听起来有点反直觉，但恰恰是复杂产品最需要的。因为真正好用的工具，应该让你感觉不到工具的存在，就像一把好用的刀，你只想到切菜，而不会注意刀柄上的花纹。对于用户来说，一个平静的界面意味着，你可以专注于自己的工作，而不是和软件本身搏斗。这篇文章值得任何一个用过复杂软件的人读，它会让你重新审视你每天面对的屏幕，也许你会开始注意那些微妙的间距和颜色，并理解它们为什么在那里。
很多团队在做一个新产品或者新功能的时候，最常见的做法是老板拍一个想法，或者产品经理根据直觉提一个方案，然后大家就埋头做。做出来以后发现用户不买账，或者用起来很别扭，再回头改，改来改去时间就浪费了。问题出在哪里呢？出在大家一开始就没有想清楚，我们到底要解决用户的什么问题，以及除了眼前这个方案，还有没有别的路可以走。
这篇文章介绍了一个叫“机会解决方案树”（Opportunity Solution Tree）的工具，专门用来把产品发现（product discovery）这个过程变得可视化。产品发现听起来很玄，其实就是指在动手做东西之前，先搞清楚用户真正需要什么，以及怎么满足这个需求。这个工具长得很像一棵树，最上面是你要达成的结果，比如提高用户留存率，也就是让用户用了你的产品以后愿意一直用下去。中间一层是机会，也就是用户遇到的麻烦或者想要实现但还没实现的事情。最下面是解决方案，也就是针对这些机会你想出来的具体办法。
为什么这棵树有用呢？因为平时我们想问题都是散的，脑子里冒出很多点子，但彼此之间没有联系。这棵树强迫你把思路摆出来，让大家都能看见。比如你的目标是让更多新用户在一周内完成第一次购买，那么机会可能包括用户不知道买什么好，用户担心买错了，用户觉得付款太麻烦。针对每一个机会，你又可以想出好几个解决方案，比如针对“不知道买什么好”，可以做推荐清单，可以做新手教程，也可以让老用户分享经验。
有了这棵树，团队开会的时候就不会再争论哪个方案好，而是先看哪个机会更值得解决。文章里举了一个例子，说一个团队原本想做一个很酷的新功能，但用这棵树一分析，发现用户最头疼的其实是另一个小问题，于是他们转而解决那个小问题，结果用户满意度大幅提升。这就是这棵树的价值，它让你把精力花在刀刃上，而不是自嗨。
对于没有产品背景的读者来说，你可以把这棵树想象成一张地图。以前你出门只知道自己要去某个地方，但不知道有哪几条路可以走，哪条路更顺畅。这棵树就是把所有可能的路都画出来，并且标出每条路通向哪个目标。这样你和团队讨论的时候，就不会因为某条路看起来漂亮就选它，而是会想这条路是不是真的能带我们到达想去的地方。
最后，文章强调这棵树不是画完就完了，它要一直更新。因为用户的需求会变，你的解决方案也可能被验证为无效，这时候就要剪掉一些树枝，长出新的树枝。所以它更像一个活的东西，而不是一张挂在墙上的死图表。读完这篇文章，你带走的一个判断就是，做产品最怕的不是做不出来，而是做了一堆没人要的东西。在动手之前，花点时间把问题和机会想清楚，比什么都重要。
我们平时思考问题，很多时候是在脑子里想的。想一些简单的事情，比如明天要买什么菜，脑子里列个清单就够了。但如果你要理解一个复杂的系统，比如整个城市的交通怎么运转，或者气候变化会带来哪些连锁反应，光靠脑子想就远远不够了。因为变量太多，彼此之间还有各种关系，你根本记不住，也推演不出来。这篇文章讲的就是，我们能不能发明一些新的媒介，让人可以“思考那些原本无法思考的事情”。
文章的作者是布雷特·维克多（Bret Victor），他是一位很有名的交互设计师。他在这篇文章里举了很多例子，来说明传统的媒介，比如文字和静态图表，在帮助我们理解复杂系统方面有很大的局限。文字是线性的，你只能一句一句读，但复杂系统是网状的，一个东西影响另一个东西，另一个东西又反过来影响第一个。静态图表虽然能看到全貌，但它是死的，你没法让它动起来，没法改变参数看结果。
维克多举了一个例子，关于一个电路。电路里有电阻、电容这些元件，电流通过的时候会有各种行为。如果你只是看电路图，很难想象电流是怎么变化的。但如果有一个交互式的工具，你可以拖动滑块改变电阻值，然后立刻看到电流波形怎么变，你就能很快理解每个元件的作用。这个例子虽然有点技术，但核心思想很简单，就是让抽象的东西变得可以动手操作，让你能看见自己的操作带来的后果。
再举一个更贴近生活的例子，想象你在设计一个公园。你关心的是公园的游客容量，以及不同区域的拥挤程度。如果用传统方法，你可能要画很多图纸，算很多数据，但很难直观感受。如果有一个模拟工具，你可以在地图上放置不同的设施，然后模拟游客在公园里走，看看哪里会堵人，哪里太冷清。你甚至能调整天气、时间，看看不同情况下公园的表现。这样你就能在设计阶段就发现问题，而不是等建好了再去改。
这篇文章的核心主张是，我们的思考能力受限于我们使用的工具。就像如果你只有锤子，你看什么都像钉子。如果我们能造出更强大的思考工具，让复杂系统的行为变得直观可见，我们就能解决更多以前解决不了的问题。维克多把这种工具叫做“动态媒介”（dynamic medium），它不像书本那样固定内容，而是能根据你的输入实时变化。
对于没有技术背景的读者，你可以把这种媒介想象成一种“会说话的模型”。你给它一个条件，它就告诉你结果，你改变条件，它又告诉你新的结果。这样你就能像一个科学家做实验一样，不断尝试，不断观察，慢慢就摸清了系统的脾气。这比死记硬背公式有用多了，因为你真正理解了背后的逻辑。
读完这篇文章，你可能会觉得有点震撼，因为原来我们习以为常的思考方式其实有很大的局限。我们以为脑子很厉害，但面对复杂系统，脑子就像一台内存不够的电脑，会卡壳。而维克多提出的方向，就是给这台电脑加一个外接屏幕，把那些想不清楚的东西都画出来、动起来。这让我想到，以后我们学习知识的方式可能会彻底改变，不再是看书听讲，而是亲手去操作一个活的系统，在操作中理解它。这也许是教育和技术结合的一个美好未来。
你每天盯着手机和电脑屏幕，可能很少想过一个问题，屏幕到底想要什么。这不是一句拟人化的玩笑，而是设计师弗兰克·奇梅罗在多年前写下的观察。他提醒我们，屏幕不是一块中立的玻璃，它有自己的脾气和偏好。你滑动手指时，页面会跟着动，你点按图标时，应用会打开，这些看似自然的反应，背后其实是一整套设计逻辑。屏幕想要的是流畅、直接、即时的反馈，它讨厌等待，讨厌模糊，讨厌让用户思考。你可能会说，这不是理所当然的吗，但奇梅罗想说的是，这种“理所当然”正在悄悄改变我们与世界的相处方式。
想象一下，你在一个实体书店里找一本书，你会沿着书架走，手指划过书脊，偶尔抽出一本翻看目录，再放回去。这个过程是缓慢的、偶然的，甚至有些低效，但正是这种低效，让你有机会发现一本你原本没打算买的书。而屏幕上的书店不是这样，它会把所有书排列成整齐的网格，每本书的封面、价格、评分都清清楚楚，你点击一本书，详情页立刻弹出来，再点一下，就加入了购物车。整个过程几乎没有停顿，没有犹豫的空间。奇梅罗说，屏幕的设计就是为了消除摩擦，让动作变成条件反射。这当然有好处，购物变得方便了，阅读变得快捷了，但代价是我们失去了那种徘徊和迟疑的体验。
奇梅罗进一步指出，屏幕的这种特性源于它的物理本质。屏幕是一个发光的平面，它只能显示二维的图像，无法像纸张那样承载触感和重量。为了弥补这种缺失，设计师们发明了各种隐喻，比如按钮、滑动条、文件夹，这些都是在模拟现实世界，但模拟得越像，我们就越依赖屏幕的规则。你可能会发现，在屏幕上，一切都必须有一个明确的“下一步”，否则用户就会迷路。于是，界面设计变成了一种说服术，它引导你点击这里，滚动那里，让你在不知不觉中按照设计者的意图行动。奇梅罗用了一个很妙的比喻，他说屏幕就像一扇窗户，我们透过它看世界，但窗户的框架决定了我们能看到什么，看不到什么。
这篇文章写于2013年，那时智能手机刚刚普及不久，但奇梅罗的观察在今天依然适用，甚至更加深刻。如今，屏幕不仅想要你的点击，还想要你的时间、你的注意力，甚至你的情感。社交媒体的信息流是无限滚动的，视频应用会自动播放下一个，这些设计都在利用屏幕的偏好，让你停不下来。奇梅罗并没有给出一个简单的答案，他只是在提醒我们，屏幕是一种工具，但它正在变成一种环境。我们生活在这个环境里，不知不觉地接受它的规则。读完这篇文章，你可能会开始留意，自己在屏幕上做的每一个动作，有多少是出于本意，又有多少是屏幕“想要”你做的。这或许就是奇梅罗留给我们的问题，我们该如何在享受屏幕带来的便利的同时，不失去自己作为人的节奏和选择。
你有没有想过，为什么微信越用越离不开，而很多新出的社交应用却很快就没人用了？为什么滴滴的司机越多，乘客等车的时间就越短，而乘客越多，司机接单的机会也越多？这些现象背后，都有一个共同的力量在起作用，那就是网络效应（network effects）。简单来说，网络效应就是，一个产品的价值，会随着使用它的人数增加而增加。电话就是一个最经典的例子，如果全世界只有你一个人有电话，那这部电话毫无用处，但如果你的朋友、家人、同事都有电话，那这部电话的价值就大了。NFX的这篇文章，把网络效应拆解成了16种不同的类型，就像一本手册，帮你识别和理解这些看不见的力量。
文章首先区分了直接网络效应和间接网络效应。直接网络效应，就像电话网络，用户越多，每个用户直接受益，因为你能联系的人更多了。间接网络效应，通常出现在平台型产品里，比如电商平台，买家越多，卖家越愿意入驻，因为能卖出去的东西更多，而卖家越多，买家选择也越多，这又吸引了更多买家，形成一个正向循环。但文章不只是停留在这些基础概念上，它深入到了更微妙的层面。比如，它提到了数据网络效应（data network effects），这是一种随着用户使用，产品会积累更多数据，从而变得更聪明，进而吸引更多用户的效应。比如导航应用，用的人越多，它收集的实时路况数据就越丰富，导航的路线就越准确，这就吸引了更多人使用，而更多人使用又让数据更完善。
文章还提到了很多你可能没听说过的网络效应类型，比如技术网络效应（technology network effects），它指的是，当一项技术被越来越多的人采用时，围绕它的配套技术和服务也会越来越丰富，从而让这项技术本身更有价值。这就像安卓系统，用的人多了，开发者就愿意为它开发应用，应用多了，用户就更愿意用安卓。还有一种叫“品牌网络效应”（brand network effects），听起来有点抽象，但你可以想象一下，当一个品牌被很多人认可时，它本身就成了一种信任的象征，这种信任会让更多人愿意使用它，从而进一步强化品牌。
但网络效应并不是万能的，文章也指出了它的边界和陷阱。比如，有些网络效应只在小范围内有效，一旦用户规模超过某个点，价值反而会下降，这被称为“拥塞效应”（congestion effects），就像一条高速公路，车太多就会堵车。另外，网络效应也会让后来者很难进入市场，因为现有玩家已经有了庞大的用户基础，这被称为“竞争壁垒”（competitive moats）。但文章提醒我们，壁垒不是永恒的，技术变革或新的商业模式可能会打破旧的网络效应。比如，基于区块链的去中心化网络，可能会改变传统平台的规则。
读完这篇文章，你可能会开始用新的眼光看待你每天使用的产品。为什么有些应用能迅速崛起，有些却昙花一现？为什么有些平台能持续增长，有些却陷入停滞？网络效应提供了一种解释框架。它让我们看到，产品的成功不仅仅取决于功能或设计，还取决于它如何利用用户之间的连接和互动。当然，网络效应不是万能的，它需要与产品本身的质量、用户体验和市场时机相结合。但理解这16种网络效应，就像拥有了一副透视镜，能让你看清商业世界背后的结构。
你有没有过这样的经历，心里明明装着一件重要的事，比如明天要交的报告，或者一个想了很久的创业点子，可你偏偏在刷手机、整理书架、甚至擦桌子，就是不肯坐下来做那件事。你可能会说这是拖延，但保罗·格雷厄姆（Paul Graham）在这篇文章里想说的，不是拖延，而是一个更隐蔽的现象，你的脑子里同时装着好几件事，而其中最占地方的那件，会悄悄决定你其他所有事情的质量。
保罗·格雷厄姆是硅谷很有名的创业孵化器Y Combinator的创始人，他长期观察程序员和创业者，发现一个规律，如果一个人脑子里一直盘旋着一个大问题，比如公司下一步该怎么走，或者一个技术难题怎么突破，那他做其他小事的效率会明显下降，甚至连和人聊天都心不在焉。这不是因为他懒，而是因为人的大脑就像一块有限的桌面，那个大问题像一摞永远堆在那里的文件，把其他东西都挤得没地方放。
文章里有个很生动的说法，他说脑子里最上面的那个想法，会像一条背景程序一样一直运行，消耗你的计算力。比如你明明在陪孩子玩，可脑子里还在想那个没解决的代码问题，结果孩子跟你说话你都没听见。这不是你不爱孩子，而是那个“最顶上的想法”太强了，它把别的信号都盖住了。保罗说，如果你想认真做创造性的工作，比如写文章、写代码、设计产品，你就得学会管理这个“最顶上的想法”，要么把最大的问题解决掉，要么把它暂时放下来，否则你做什么都做不好。
他给的建议听起来有点反直觉，他说有时候故意分心反而有用。比如你卡在一个难题上，与其死磕，不如去散步、洗澡、做点机械的事，让那个“最顶上的想法”在后台自己慢慢转，说不定就转出答案了。这就像电脑卡住了，你把它放到后台，它自己慢慢算，你去做别的，过一会儿回来它就好了。但前提是，你得先把它“装”进去，也就是你得先认真思考过那个问题，让它在脑子里留下痕迹，否则它不会自己在后台转。
这篇文章写于2009年，当时保罗自己也在经营公司，他常常被各种杂事打断，比如回邮件、开会、处理行政事务。他发现这些杂事之所以让他烦躁，不是因为它们本身难，而是因为它们占用了“最顶上的想法”的位置，让他没法专心思考真正重要的事。所以他提出，一个人要像管理电脑内存一样管理自己的注意力，把最重要的那件事放在最上面，其他事都排到后面去。
读这篇文章，你会觉得他说的不是时间管理，而是注意力管理。时间管理是说你每天有多少小时，注意力管理是说你这几个小时里，脑子里真正在转什么。对普通人来说，这个道理也适用，比如你想学一门新技能，可每天脑子里都是工作上的琐事，那学习效果肯定不好。你得学会给重要的事留出“脑内空间”，哪怕只是每天早起半小时，先想那件重要的事，再开始处理杂事。
最后你会带走一个很实在的判断，那就是，你脑子里最常想的那件事，就是你人生的方向。如果你发现自己整天在纠结无关紧要的小事，那可能不是因为你忙，而是因为你逃避真正重要的事。所以，偶尔停下来问问自己，我现在脑子里最上面那个想法是什么，它值得占这个位置吗，如果值得，就好好做，如果不值得，就把它清掉。这个判断，比任何效率技巧都管用。
想象一下，你第一次学做饭，面前有一本菜谱，上面写着“加盐适量，翻炒至变色”，但你看不到锅里的菜到底变成什么颜色了，也尝不到味道，只能凭感觉猜，那你会觉得做饭很难学。现在，如果你面前有一个透明的锅，每加一勺盐，你都能看到菜的颜色变化，尝一小口，立刻知道咸淡，那你学起来是不是快多了？布雷特·维克多（Bret Victor）的这篇文章，讲的就是编程这件事为什么这么难学，以及如果编程工具能像那个透明锅一样，让人实时看到每一步的效果，学习编程会不会变得容易很多。
布雷特·维克多是一个界面设计师，他长期思考人和电脑怎么更好地交流。他这篇文章写于2012年，当时很多人觉得编程难是因为数学不好或者逻辑不行，但他说不是，难就难在编程这个活动本身，它让你在脑子里运行一个虚拟的世界，你看不到代码运行时的样子，只能看到最终结果。比如你写一行代码，让屏幕上出现一个圆圈，你得先运行整个程序，才能看到圆圈在哪，大小多少，颜色对不对。如果不对，你得回到代码里，猜是哪一行出了问题，改一下，再运行，再看。这个过程就像蒙着眼睛画画，画完再睁开眼，发现画歪了，再回去改，效率极低。
布雷特举了一个例子，他说现在很多编程工具，就像一台没有屏幕的电脑，你输入指令，但看不到中间过程。他设想了一种“可学习的编程”环境，在这个环境里，你写的每一行代码，旁边都会立刻显示出它产生的效果。比如你写一个让球移动的代码，球就会在屏幕上动起来，你改一个数字，球的速度立刻变快或变慢，你不需要运行整个程序，就能看到这个数字的作用。这就好比做菜时，你加一勺盐，立刻尝一口，而不是等整盘菜炒完才尝。
他还提到，编程不只是一门技术，更是一种表达方式，就像写作一样。如果你写文章时，每写一个词，都要等整篇文章写完才能看到，那你很难写出好文章。编程也是，如果你写代码时，每写一个函数，都要等整个程序跑起来才能看到效果，那你很难做出好的作品。所以，工具的设计很重要，好的工具应该让创造者随时看到自己创造的东西，这样他才能不断调整，就像雕塑家看着手里的泥巴，一边捏一边看。
这篇文章里，布雷特还批评了当时的编程教学方式，很多教程只教语法，比如“如果你要定义变量，就要这么写”，但从来不告诉你这个变量在程序里到底起什么作用，就像教人做饭，只教“盐是咸的”，却不教“你炒青菜时加盐，菜会出水，颜色变深”。他觉得，学编程应该像学一门手艺，师傅带着你做，你看着每一步的效果，慢慢就懂了。而不是先背一堆规则，再上锅操作。
读这篇文章，你不需要懂编程，也能感受到他想说的核心，那就是，任何创造性活动，如果工具能让你实时看到自己动作的后果，你学起来就会更快，做得也会更好。这不仅仅适用于编程，也适用于写作、画画、做音乐，甚至做菜。你想想，如果写作工具能实时显示你的文章在读者眼里是什么感觉，那你改起来是不是更有方向？如果画画工具能实时显示你调的颜色在画布上的效果，你是不是更容易调出想要的颜色？
最后你会带走一个判断，那就是，工具的好坏，很大程度上决定了你学习的速度和创造的质量。如果你觉得学一样东西很难，可能不是你的问题，而是工具太笨，让你看不到自己的每一步。所以，好的工具应该像一面镜子，让你随时看到自己在做什么，而不是一块黑布，让你摸索半天。这个道理，对做产品的人、做教育的人，甚至对每一个想学新东西的人，都值得想一想。
你大概有过这样的经历，一个朋友发来一条链接，说这个应用太好玩了，你也试试。你点开，注册，用了一下，觉得还不错，又分享给了别人。这种一个人拉一个人，像滚雪球一样越滚越大的过程，很多人会觉得这就是网络效应。但有一家叫 NFX 的投资机构专门研究这类现象，他们提醒说，这种靠用户拉新用户带来的增长，其实只是病毒效应，和真正的网络效应是两码事。搞混这两者，可能会让创业者做出错误的判断，甚至误以为自己的产品已经建立了护城河，结果竞争对手一来就垮了。
先说说病毒效应是什么。它指的是产品本身带有一种传播机制，用户使用产品的过程中，会自然地把产品推荐给其他人，而且这种推荐几乎不需要额外成本。比如你玩一个拼图游戏，通关后它自动生成一张炫耀成绩的卡片，你分享到朋友圈，朋友看到也来玩。这个动作是产品设计好的，是你顺手做的，不是因为你多喜欢这个产品，而是因为分享这个动作本身有奖励，可能是积分，可能是面子。病毒效应的核心是用户增长的速度，它像病毒一样传播，但问题是，它传播得快，消失得也快。一旦新鲜感过去，或者奖励停止，传播就停了。
而网络效应是另一回事。它说的是，产品对每个用户的价值，随着使用这个产品的其他用户增多而增加。最经典的例子是电话。你一个人有电话，它一点用都没有。当你的朋友、家人、同事都有了电话，你才能用它联系他们，电话对你才有价值。用户越多，每个用户得到的好处越大，而且这种好处是实实在在的，不是靠奖励或设计出来的。另一个例子是社交平台，你之所以留在上面，是因为你的朋友都在那里，你离开就等于失去联系。网络效应的特点是，它一旦建立，就很难被打破，因为用户之间的连接本身就是壁垒。
为什么区分这两者这么重要？因为很多创业者在向投资人讲自己的产品时，会把用户增长快说成是网络效应，觉得只要用户多了，别人就追不上。但 NFX 指出，病毒效应带来的增长是脆弱的。它依赖于产品内部的传播机制，比如邀请奖励、分享功能，这些竞争对手很容易模仿。你做一个游戏，别人也能做一个，甚至奖励更多，用户就跑了。而网络效应则不同，它依赖于用户之间的真实关系和数据积累，比如一个电商平台，买家越多，卖家越愿意来，商品越丰富，买家越愿意来，这种循环是竞争对手很难复制的，因为你需要同时吸引两边的人，而且先发者已经有了规模优势。
NFX 还进一步区分了网络效应的不同类型，比如直接网络效应、间接网络效应、双边网络效应等。直接网络效应就是上面说的电话例子，用户越多，产品对每个用户的价值越大。间接网络效应是指，用户增多导致互补产品的出现，从而提升原有产品的价值，比如游戏主机用户多了，游戏开发商才愿意开发更多游戏，游戏多了，主机对用户更有吸引力。双边网络效应则出现在平台型产品中，比如打车软件，司机多了，乘客等车时间短，乘客多了，司机接单多，两边互相吸引。这些网络效应都需要精心设计和长期积累，不是靠一个分享按钮就能实现的。
文章里还举了一些例子来帮助理解。比如一些增长很快的应用，像早期的即时通讯工具，它们确实有网络效应，因为你需要和朋友用同一个工具才能聊天。但另一些应用，比如一些休闲游戏，它们靠病毒传播获得大量用户，但用户之间并没有太多互动，每个用户的价值不依赖于其他用户，所以它们没有网络效应，一旦热度过去，用户就流失了。NFX 提醒创业者，要诚实地评估自己的产品，是真正的网络效应，还是只是病毒效应，因为前者能带来持久的竞争优势，后者只是暂时的增长浪潮。
读完这篇文章，你会明白，一个产品能不能长久地留住用户，关键不在于它增长多快，而在于用户之间有没有形成互相依赖的关系。如果你只是靠病毒传播拉新，那就像是在沙滩上盖楼，潮水一来就冲走了。而网络效应，就像是在岩石上打桩，虽然慢，但一旦扎根，就很难动摇。下次再看到一个应用疯狂增长，你可以想一想，它是病毒效应还是网络效应，这决定了它到底是昙花一现，还是能成为下一个巨头。
在软件公司里，产品团队经常要记录要做什么事情，比如开发一个新功能，或者修复一个错误。传统的方法是用用户故事，就是站在用户的角度，描述用户想要什么，比如作为一个用户，我想在登录后看到我的头像，这样我能确认自己登录成功了。这种写法听起来很合理，但有一家叫 Linear 的公司，他们专门做项目管理工具，他们写了一篇文章，提出一个反直觉的观点，说不要写用户故事，而要写问题。他们觉得用户故事听起来很友好，但实际上可能让团队忽略了真正重要的事情。
为什么这么说呢？因为用户故事有一个隐含的假设，就是我们已经知道用户想要什么，而且这个需求是固定的。但现实是，用户经常说不清楚自己需要什么，或者需求会随着时间变化。比如用户说想要一个更快的登录页面，但真正的问题可能是登录流程太复杂，或者服务器响应太慢。如果团队只是照着用户故事去实现，可能费力不讨好，解决不了根本问题。而写问题就不一样，问题描述的是现状中哪里不对劲，比如用户登录时经常忘记密码，导致登录失败。这样团队就可以去分析，到底是密码找回流程太繁琐，还是验证码太难识别，然后针对性地解决。
Linear 的文章里强调，写问题有很多好处。首先，它迫使团队去思考问题的本质，而不是急于给出解决方案。其次，问题描述更开放，可以让团队发挥创造力，想出多种可能的解决方案。第三，问题更容易衡量，因为你可以定义什么是成功，比如登录失败率降低到多少。而用户故事往往预设了解决方案，比如用户想要一个头像，你就去加头像，但也许用户真正需要的是更明显的登录状态提示。
文章里还提到，用户故事常常变成一种形式主义，团队为了写而写，没有人真正去理解用户。而写问题，则让团队更贴近用户，因为你需要去观察、去倾听、去挖掘用户背后的痛处。比如一个用户抱怨加载太慢，你如果只记下用户故事，就会去优化加载速度，但如果你记下问题，你可能会发现，用户抱怨的其实不是速度，而是他等了很久却没有任何提示，他不知道页面是不是卡住了。所以问题可能是缺少加载进度条，而不是速度本身。
Linear 还给出了一些具体的建议，比如如何写一个好的问题。问题要具体，不要泛泛而谈，比如不要写性能不好，而要写当用户在上传大文件时，界面会卡顿超过 5 秒。问题要可验证，比如可以通过测试来确认问题是否真的存在。问题要独立，不要和其他问题混在一起，这样团队可以单独解决。另外，问题要描述现状，而不是期望，因为现状是事实，期望是目标。
这篇文章的核心思想是，团队应该关注问题，而不是解决方案。因为解决方案可能会变，但问题通常是持续的。比如用户需要一个更简单的方式来管理订阅，这个问题会一直存在，但解决方式可能是改进界面，也可能是提供邮件提醒，还可能是自动续费。如果团队一开始就决定做某个功能，可能就错过了更好的办法。写问题，让团队保持灵活，也更容易让团队达成共识，因为问题本身是客观的，而解决方案可能因人而异。
读完这篇文章，你会理解，在团队协作中，如何描述任务会直接影响工作的质量和效率。写问题，就像医生诊断疾病，先找到病因，再开药方。而写用户故事，可能就像病人说我想吃止痛药，医生就直接开药，但没查清楚是不是需要做手术。所以，下次你在团队里提出一个需求时，不妨先想一想，我是在描述一个问题，还是已经给出了一个方案？如果只是方案，那可能你还没有真正理解用户的困境。