最近，我到杂果店里买“毛豆”（我对蔬菜种类只是大概了解）。我也无法确定这玩意是在蔬菜区，还是冷藏区，或者罐头区。我放弃了，找了个店员来帮我。结果她也不知道。
这个店员本可以给我其他答复。比如她可以让我一脸懵逼的去别处看看，或者给我个模糊的区域，甚至干脆告诉我他们不卖这个。但她没有，她想抓住机遇一样对待这次询问，争取找出答案帮助顾客。她找来了其他店员并在很短时间内给了我可靠选项——在冷藏区。
在这种情况下，店员看了下请求，然后基于“我们能解决问题并给予满意答复”的前提开始行动的。她从yes开始，而非no。
当我头一次当上技术主管角色的时候，我觉得我的工作就是将那些来自产品经理和商业分析的可笑需求挡在门外，以保护我美丽的软件。我发起的很多谈话，都是将请求视作否定，而非允许。
某一刻，我突然顿悟，或许有不同的方式来工作，只需要把我的观念从no倒转为从yes开始。事实上，我开始相信，从yes开始是一个技术领导者的基本素养。
这个简单的变化彻底改变了我的工作方式。事实证明，有非常多的机会说出yes。当某个人和你说：“呐，如果我们将所有的窗口都做成半透明的，那这app确实就想蜜蜂的膝盖一样！”，你肯定会把它当个笑话给驳回了。当它通常用“为什么？”来开头更好。通常情况下，由于某些必然的原因，人们会要求圆形、半透明的窗口放在第一眼的位置。例如，你可能和一个新的大客户签订了圆形半透明窗口的委托书。
通常，你会发现当你了解的请求的前因后果，新世界的大门就打开了。常见的就是以其他方式利用现有产品来完成请求，不用干活就可以说yes：“事实上，在用户偏好设置里，你可以下载并切换到圆形半透明窗口的皮肤”。
有时候其他人会有一些简单的想法与你的产品视角不同。我发现通常这对于转过来问自己“为什么？”会有帮助。有时候说出原因的行为会清楚的表明你的第一反应是没有道理的。否则，你需要提高一下格局来引导关键决策者。记住，这一切的目标是为了对他人说出yes并使其正常运转，不仅仅对他有利，对你和你的团队也是如此。
如果你能对功能请求与现有产品的冲突给出强有力的解释，那么你很可能对是否构建正确的产品进行高效的谈话。不论谈话是否结束，每个人关注的都是哪些是产品的本质，哪些不是。
从yes开始意味着和同事一起工作，而不是与他们为敌。
