💡 如果你是第一次来，建议先点击👉🏻 《致读者》，了解这个 Newsletter 是写给谁的。
你离用户有多近，决定产品增长能走多远
上个月末，我去 Apple 孵化器训练营当导师。
现场，我随机问了创业者们一个问题：
“在座各位，到底有多少人真正跟用户聊过、看过用户使用自己的产品？”
一位创始人的回答让我印象很深。他前前后后聊了 200 多个用户。
一开始，他其实不知道该聊什么，用户也不太愿意搭理他。他只能去楼下的星巴克和咖啡厅，随机找人聊天。
后来，他换了一个方法。
他不再急着提问，也不再向用户解释产品，而是直接把产品递过去，什么都不说，看着对方自己探索。
然后，他看到了两个完全不同的产品。
一个是他脑子里的产品：路径清晰，按钮明显，功能也不难理解。
另一个是用户手里的产品：他以为用户一定会点的按钮，用户根本没有看见；他已经解释过的地方，用户还是不理解；他设计好的任务路径，用户也没有照着走。
这 200 多次对话当然重要。但真正改变他的，可能不是第 200 个用户说了什么，而是他终于停下来，亲眼看见用户做了什么。
用户没有在使用你脑子里的产品
我以前做产品时，也经历过类似的时刻。
有一次，我们组织焦点小组访谈。主持人在会议室里带着用户完成一轮轮问答和测试，团队成员坐在单面镜后面观察。
整个过程中，镜子后面不断有人小声感叹：
“原来用户是这么理解的。”
“他居然完全没有看到这里。”
“我们以为最重要的功能，他根本不在意。”
调研还没有结束，产品负责人已经站到白板前，重新梳理产品架构。他开始当场判断哪些功能应该砍掉，哪些功能需要补上，原来的优先级又该怎么调整。
用户并没有帮我们把既有答案优化得更漂亮。
他们直接推翻了我们对问题的理解。
所以，这次训练营结束后，我脑子里一直有一个判断：
你离用户有多近，决定产品增长能走多远。
很多团队会把用户研究理解成产品流程里的一个环节：立项前做几次访谈，上线后发一份问卷，版本迭代时再收集一些反馈。
但“靠近用户”并不等于拥有几份研究报告，也不等于知道用户对功能的满意度。
真正的距离，体现在团队能不能持续看见用户的真实行为，并让这些证据进入产品决策。
最昂贵的证伪，往往发生在产品做完之后
很多创业团队做产品，遵循的是这样一条路径：
先根据行业和痛点提出假设，再投入时间把产品做出来，最后找到用户，验证这个假设是否成立。
如果假设刚好成立，用户也愿意买单，产品就有机会继续往前走。
但问题是，很多团队把“找用户求证”放得太晚了。
等产品已经开发出来，页面已经设计完成，资源已经投入，团队才第一次认真观察用户能否理解、是否愿意使用。这个时候，每一个被证伪的判断都很昂贵。
失败本身并不可怕。真正浪费资源的是：本来可以用一次低成本观察发现的问题，却要等到整个功能上线以后，才从数据下跌和用户流失里知道答案。
这也是我理解的 0→1 产品验证：
它不是想办法证明自己的判断正确，而是尽可能便宜、尽可能早地发现自己错在哪里。
你与用户的距离越远，假设就越容易在团队内部被当成事实；假设在内部待得越久，推翻它的成本也越高。
用户说“想要”，不等于产品已经被验证
跟用户聊天很重要，但只听用户怎么说，仍然不够。
用户可能会说这个想法很好，也可能表示自己愿意尝试。面对一个热情介绍产品的创始人，人们甚至会出于礼貌给出积极回应。
真正能推动产品决策的，是更具体的行为证据：
他第一次进入产品时，能不能看懂这是做什么的？
他会从哪里开始？在哪里停住？哪些按钮根本没有进入他的视线？
他拿到第一个结果后，会不会主动继续编辑、保存、分享，或者付出更高的时间与金钱成本？
“我觉得不错”是一种态度。
“我愿意继续做下一步”才更接近产品证据。
因此，用户研究的目标不应该只是整理需求清单。它还要帮助团队区分三件事：用户表达了什么、用户真正做了什么，以及什么行为足以证明价值已经发生。
PLG 不是“把产品做好，用户自然会增长”
这也是 PLG 经常被误解的地方。
很多人把 Product-Led Growth 简单理解成：少做销售，多做产品；产品足够好，用户自然会来，增长也会自然发生。
但产品不会因为功能多、模型强、技术先进，就自动带来增长。
PLG 真正要求产品承担的，是一部分原本需要销售、运营和客服完成的工作：
让第一次接触产品的人迅速明白它与自己有什么关系；让用户不依赖大量解释，也能亲手得到一个有价值的结果；让这个结果自然推动他进入下一步，而不是停留在一次尝试。
从这个角度看，PLG 不是一个渠道策略，而是一条由用户行为组成的价值路径。
流量进入之后，用户能不能开始；开始之后，能不能获得结果；得到结果之后，是否愿意保存、分享、继续使用或付费。任何一个环节断掉，增长都会停在那里。
如果用户用了很久，还不知道产品能为自己带来什么，再大的流量也只是在给漏斗加水。
强大的能力，不一定能带来更快的 Aha Moment
最近我在看一些 AI 产品时，反复遇到一个问题。
团队拥有许多强大的能力，也投入了大量精力改善生成效果、编辑能力和完整工作流。但第一次进入产品的用户，面对的却可能是一个空白输入框、一组陌生参数，或者一长排不知道该先用哪个的功能。
从团队视角看，这是能力丰富。
从新用户视角看，这是选择成本。
产品越强大，用户越不一定能快速理解它。功能越多，价值甚至可能出现得越晚。
新用户第一次使用时，通常不需要先理解背后的模型、参数和完整工作流。他需要尽快看到一件与自己有关的事情发生：
“原来我的内容，可以变成这样。”
这个时刻就是 Aha Moment。
它不是产品演示里最震撼的功能，也不是团队最想宣传的技术突破。它是用户第一次亲自确认：这个产品对我有用。
缩短 Aha Moment，也不是把复杂产品做成玩具。它要求团队重新安排复杂度出现的顺序。
先让用户看见价值，再让他理解能力；先帮助他获得第一个结果，再邀请他进入更完整的工作流。
不同用户，不应该被塞进同一条增长路径
还有一种常见做法，是团队在研究中划分了小白用户、进阶用户和专业用户，真正做产品时，却仍然让所有人从同一个入口进入，完成同一套流程。
用户分层如果只停留在画像文档里，就没有意义。
小白用户需要的，可能是熟悉的场景、可直接选择的模板和迅速出现的反馈。他首先想知道“我能得到什么”。
专业用户更关心结果是否精确、能否编辑、参数是否可控，以及产品能不能稳定完成真实任务。他首先要确认“这是否真的可用”。
他们对产品的判断标准不同，愿意承担的学习成本也不同。
因此，用户分层最后必须落到产品上：首屏先向谁表达什么，默认路径服务谁，哪些选项应该立即出现，哪些复杂度可以晚一点展开。
一个产品很难在同一时刻，用同一种方式，让所有用户都满意。
好的增长设计不是消灭复杂度，而是让复杂度在用户需要它的时候出现。
容易传播的结果，和真正建立壁垒的价值
产品增长里还有一个更隐蔽的矛盾。
容易传播的内容，通常快速、直观、视觉效果强。用户几乎不需要学习，就能得到一个愿意发到社交媒体上的结果。
但真正建立产品壁垒的能力，往往位于更深的地方：更精准的编辑、更专业的工作流、更稳定的交付，或者让一个数字结果真正进入现实任务。
如果团队只追求传播，产品可能变成一个用完即走的特效工具。用户获得一次惊喜，却没有理由回来。
如果团队只强调完整能力，新用户又可能在感受到价值以前，就被漫长路径和专业门槛挡在外面。
这两件事并不需要二选一。更值得设计的是它们之间的连接：
让用户先快速看见结果，愿意保存或分享；再让这个结果成为继续编辑、完成真实任务和持续使用的起点。
分享不是增长的终点。它应该带来新的用户，也应该把原来的用户带回更深的价值路径。
真正的 PLG，不是产品里多放一个“分享”按钮，而是让用户获得的结果本身具有传播动力，同时又保留继续使用的理由。
把用户从验收人，变成证据来源
很多团队在产品快做完时，才把用户请回来验收：能不能用，喜不喜欢，还有什么意见。
但用户不应该只出现在流程最后。
从最早的假设，到第一次体验，再到激活、留存、分享和付费，用户行为都应该持续为团队提供证据。
一个更健康的产品增长循环应该是：
提出假设，观察真实行为，找到阻力，缩短价值路径，再用新的行为证据判断修改是否有效。
用户离产品团队越近，团队就越早发现哪些判断只是想象；用户证据离决策越近，产品迭代就越少依赖内部争论。
所以，“多跟用户聊”并不是一句正确但空泛的建议。
更重要的是，改变你获取证据的方式：少问一点“你觉得怎么样”，多看一点“你接下来会怎么做”；少向用户证明产品的价值，多让产品自己完成证明。
那位访谈了 200 多名用户的创始人，真正跨过去的一步，也许正是从“我要问出答案”，走到了“我要亲眼看见问题”。
产品增长的起点，往往就在这里。
我是大琪，擅长产品增长、PLG 和 0→1 产品验证。
我关心的不只是如何获得更多流量，而是如何把用户证据变成产品动作，让产品真正承担增长。如果你也在做产品，欢迎关注我。后面我会继续分享真实项目和工作坊里那些改变产品判断的具体时刻。
做 AI 产品、卡在激活上的 founder 可以 DM 我