导读：一个三岁孩子半夜哭着要"喝水"，父母换了杯子、调了温度、甚至买了新水壶——问题却没解决。这到底是个产品问题，还是我们理解错了需求本身？
「喝水」背后的真实信号
作者记录了一个反复出现的场景：孩子睡前说口渴，给水后喝一口就放下，过一会儿又喊要水。循环持续，直到大人意识到——孩子要的不是水。
孩子要的是「被看见」。
白天父母忙碌，睡前成为唯一能被完全注视的窗口。喝水是唯一能合法延长清醒时间、获得面对面互动的理由。这是一个三岁儿童能想到的最优解。
从亲子场景看产品设计的盲区
这个案例戳中了一个常见陷阱：用户说的和真正需要的，往往是两回事。
孩子要水 → 父母优化供水方案 → 问题持续。
这个闭环里，双方都困在表层需求里。直到有人跳出「解决问题」的惯性，问一句：如果水没问题，那问题是什么？
作者的身份耐人寻味——前谷歌产品经理，现育儿博主。她用产品语言拆解亲子冲突：需求挖掘、用户访谈、迭代验证，这些职场技能被移植到客厅和卧室。
当「解决方案」成为新麻烦
更讽刺的转折在后头。
作者尝试用「高质量陪伴」替代「给水」——提前20分钟专注陪孩子，理论上应该消除夜间索水行为。结果孩子要水更频繁了。
为什么？因为新方案创造了新依赖。孩子发现：只要喊口渴，就能获得比预设时间更长的互动。需求被意外强化了。
这像极了产品迭代中的「 unintended consequence（非预期后果）」：修复A问题，激活了更顽固的B问题。
最终的解法出乎意料地简单
作者没有给出标准答案。她记录了自己的选择：接受不确定性，停止过度优化。
「有时候孩子只是需要你在那里，哪怕什么都不做。」
这句话里没有方法论，却暗合一个产品常识——不是所有用户痛点都需要被「解决」，有些只需要被「承托」。
从谷歌到育儿，作者的核心能力没变：识别表层需求之下的深层结构。只是这次，她的「用户」不会填写反馈问卷，而她会用余生做A/B测试。
如果职场训练让我们擅长拆解和优化，那么家庭场景是否在提醒我们：有些系统不该被过度工程化？当效率思维遇上无法被量化的需求，你的默认设置是什么？
热门跟贴