06 | Y模型：从问题域到方案域的最硬核解题思路

用心听不要照着做，还可以补充：让用户了解你的思考过程，让用户做选择而不是做决定。 用户都喜欢给产品出主意，尤其是企业内部用户，碰到强势的用户，如业务线的负责人、领域专家、甚至老板，产品经理往住容易被牵着鼻子走，或者迫于压力屈从接受他们提出的解决方案。 产品经理需要深入理解用户的需求，给出浅显易懂的解决方案，这个方案往往不是一个而是多个。产品经理需要给出每个方案的优势、劣势以及自己倾向的方案。还有一点非常重要，不要直接抛出结论，让用户清晰的了解你思考问题的过程，直接说结论用户往往慒逼，还会给人一种不得不从的感觉。

关于微信的「打fei机」之前还听到过另一个比较有趣的说法：当年微信为了和支付宝针对支付进行竞争的时候，直接推送升级微信支付的版本可能升级的人并不多，于是借用「打fei机」让大部分用户无意识的升级到了带微信支付的版本

我不是PM，跟产品研发也有点距离，但时常心怀恻隐，毕竟我们现在的产品以可爱的小姑娘为主 how much和how many最难，倒不是说不知道应该怎么决策，而是她们推不动吧，说PM就是没实权的CEO，估计也就是这个了，各位大佬好好配合下不行么...

知识点口诀：用心听，不照做，深入浅出； 竞争策略：在一个不成熟的领域或全新的市场，只做“节点 1、2、3”就玩得转，随着市场的成熟，产品很快会陷入同质化竞争和价格战，最终整个市场变成红海，而破局的方法就在占领用户心智。 个人感觉最后举得微信游戏占领用户心智的例子有一丢丢不完美，前面酣畅淋漓。

乔布斯说，“人们不知道自己想要什么，知道你把它摆在他们面前。” 但是困难同样在员，你也不知道人们想要什么，即使你把它把摆在人们面前。 “用心听，但不要照着做”，这个还是挺难的。最烂俗的那个“更快的马和汽车”的例子，即使你在当时能够想到汽车的想法，但是如果技术水平没有达到，那估计也很难实现。我是想说，还得考虑但是的技术条件。 这个 Y 模型还是很漂亮的，也很清楚，是作者本人的原创么？ 从 Who, What, Where, When 的用户需求，不断的提问 Why，到达用户目标，进而用户心智，然后从用户心智 反推如何做 How，形成解决方案 Which, How many, How much 当然，大部分时候可能连用户需求都很难搞清楚，再想要深入到人性与价值观的部分，就更加困难了。 其实我觉的那个“马和汽车”的例子有过度解释的嫌疑，如果我们现在继续问，客户需要“更快的车”，那么你要给他什么呢？肯定不是飞机、高铁之类，而是需要不断的去追问为什么？无人驾驶可能是一个答案，也有可能豪华车是另一个答案。 从来没玩过微信“打*飞机”，是否从某个角度说明了我不适合做产品经理，一方面没有对热门产品的好奇心，另一方面似乎没有太多的社交需求。 文末的多控灯案例，难道不应该是提供一个智能声控灯么？这个应该是和智能控制技术发展以及成本有关的。 最近接到的需求是要将资料按照年度来管理，但是每到年初，往往还会有上一年度的资料到来，那么给出的解决方案是直接复制一份程序，一个录入前一年的，一个录入当年的，最终在后台合并。 留言里面 @小天 说的，让用户做选择，而不是做决定，很有道理。但是往往可能需要给用户看到原型界面，甚至操作一番，他们才能真正了解；而且还得做好迭代的准备。 @zebra02 提到了“政府产品”，现在流程要求比较严格，估计这类产品首先是要能够通过最终的项目评审，毕竟在项目初期写文档的时候，是很难做到“用心听、不照做”，并且还能够真正解决用户的问题。

1、什么样的用户在什么场景什么时候有什么样的需求。2、通过追问Why思考为什么有这样的需求，用户真正的目标是什么。3.基于用户真正的目标考虑解决方案设计功能，制定研发计划，包括研发排期和资源投入。4、在产品迭代的过程中深挖用户内心和产品的核心价值，通过和用户的互动、数据的收集、人性、产品价值、用户价值等多方面的思考，逐渐迭代前进，避免被同质化的竞争击垮。

有一个思考模型叫：5W2H，你这是6W3H，具体情况具体分析。方便理解，真棒

很受用，“用心听”对于b端产品是必须的，但是“不照着做”这点很容易因为自己的一些创新导致功能不符合用户想要的，也导致后期推广运行成本更高（特别是政府类产品）。 想请教下老师，政府类产品“不照着做”的边界是不是不改造核心流程呢？

对用户需求理解得要深，这叫用心听，但是给用户呈现的解决方案要尽量简单，把复杂留给自己，把简单留给用户，这叫不照着做。

关灯那个不一定是懒，也可能是单纯为了省时间，那是别的心智发动了