T公司做互联网个人软件的，其WEB相关的产品经理(PM)都很“盲”，网盲的盲。因为这些人大都是刚毕业就找过来的，没有任何经验的毕业生，而且
很多都是和互联网专业不相干的，在到公司之前甚至都不了解公司的产品。他们每天背负的任务只有一个——“收入”，很少去研究行业发展和相关产品，更不要提
如何做好产品的设计了。
有事实为证：某PM到其他部门同事的座位上讨论产品，看到同事正在使用一个竞争产品，该PM问：“这个是什么？！感觉很不错呀！”。实际上这个竞争产品已
经出来很久了，而且在业内较有名气，作为产品经理他们竟然不知道。当设计师仔细告诉这个产品是什么、怎么用、怎么好以后，他们回到座位依然会打电话问“那
天你用的那个xxx是什么来着？怎么下载？”。同事晕倒。
他们的PM和UE之间经常这样合作：PM突然想出来一个好的赚钱的点子(或者上头因为“业绩不好”压过来一个任务，他们又想出来了一个“强奸用户”的办
法)，什么都没有准备或者只准备了一个“项目说明”，描述”我们想达到什么目的”，然后就直接拿跑去跟UE的同事说：我们有一个新项目，要怎么向用户收
钱，你给我们“交互一下”吧…
B公司做互联网社区，他们的PM个个都是“职业网虫”，对于互联网和自身业务理解非常深。这些人大都是从各大互联网社区中挖掘出来的，也有很多是专业非常
对口能力很强的高才生。他们没有收入指标只有简单的流量压力，每天在想的事情就是如何为网站创造更大的流量更好的粘度，从而卖掉更多的广告。他们对于产品
设计也有自己的理解，但对于界面设计这种他们认为“很无关紧要很容易”的事情向来不屑一顾。
之所以说他们是“职业网虫”是因为他们每天都混迹在中国各大网站上，每天都在不停的关注着业界动态和网站数据，不停的分析和体验着用户的行为。互联网上新
出来的东西他们总是第一个先接触，互联网上所有的“意见领袖”他们都很熟悉，他们每个人都有自己的博客，在各大社区上都有自己的马甲…
接下来也说说他们和UE之间典型的工作方式：当要发起一个项目时，PM从来不会和任何其他部门的同事商量，他们只会在自己部门内部讨论并直接形成“结论
”，然后他们会成立小组，所有小组成员分工撰写详细的PRD。PRD的详细程度甚至到“界面上的某个按钮应该放在什么位置，应该多大”。等PRD写完之
后，回去找UE的同时进行“设计”，并要求每个设计细节必须遵照PRD…
T公司的这种情况造成的后果是：他们的设计师往往很累，项目进行的更累，而且容易出现设计和需求的偏离。
设计师在设计之初都很难真正理解PM的具体需求，PM也没有能力描述清楚需求，导致项目总是在不停的反复。甚至往往由于时间关系，产品设计稍微达到预期就
得上线，不能做到本可以达到的更好效果。在这里设计师走着走着成了产品的主导者，最终很容易就发现产品的发展偏离了原始的方向，按照设计师那个不完整理解
的构想走了…
B公司的这种情况造成的后果是：对于设计并不擅长的PM在做设计，设计师成了摆设。设计师成了“界面”的制作者，很少能够真正参与到设计。
遇到对于项目要求比较简单的产品还好，最多只是细节设计出现一些比较白痴的问题。等遇到对于设计要求较高的产品时（比如交互要求很强的软件产品），PRD
文档的“直线描述方式”不能表达清楚完整的产品设计。由于PM坚持自己主导设计，结果导致设计一团糟，而本可以做好设计的设计师却没有机会参与到其中。项
目拖延时间，公司蒙受损失。在这里产品经理成了设计师，一个按钮一个颜色都会产生争执，最终的产品设计不是极其普通就是极其糟糕，更好的设计效果不能出
来。甚至陷入到了产品的细节难以自拔…
(以上为两种极端情况的假设，请勿对号入座)
其实这里存在一个最基本的问题：产品经理是应该只给出简单需求，还是应该直接给出设计方案？
我的答案是：两种极端都不行。
angela写“如何了解用户”的时候我们回复说：“其实所有的用户研究最主要的问题就是解决：‘用户需要什么，用户希望要什么’”。同样的道理拿到这里通用：
如果你渴了，希望我帮你解决这个问题。那么不要告诉我“给我来碗稀饭”，这样我没法了解你的真实需求，如果恰巧我没有稀饭，你只好饿着；也不好只告诉我“
我渴了”，这样在我有水又有稀饭的时候，可能只会给你一杯水，不便于我直接给出更合理的方案（对于水和稀饭其实你更想要稀饭）；你可以告诉我“我渴了，给
我来碗稀饭吧”。如果有稀饭，我会直接给你。如果有水没有稀饭，我会说“我给你来碗水吧。现在没有稀饭”。
如果只给出简单需求，会大大提高沟通的成本，特别是设计师理解需求的成本，往往会造成设计过程的反复。如果直接给出设计方案，势必造成设计师没有发
挥的空间，而PM不是专业的设计者（或者说没有时间、或者不应该深度参与到具体设计中）却要主导设计的所有细节，最后造成糟糕的设计成果。
所以，我并不赞成Banlon和子条他们说的：“
老妈子就是老妈子，妹子就是妹子，哨子就是哨子”。哨子不只是有必要告诉老妈子今天街上是否热闹有多少客人，还有必要建议老妈子今天让什么样的妹子先出
台，什么样的妹子可以在后面等更有钱的主，但只是建议；老妈子也不只是应该把客人分配给妹子，还有必要建议妹子用什么样的方法对付什么样的客人，但只是建
议。老妈子不能代替妹子伺候客人。
绕了这么多，其实想说的很简单：
什么人做好什么事，是规矩。但如果什么人只管做好什么事，就是团队最大的忌讳。协作才能真正提高效率。
PM的需求文档不应该只是需求，还应该有粗糙的够“解释需求”的“设计方案”。设计师拿到需求时应该结合PM的“设计方案”去理解需求，这样更快也更直观。但PM的“设计方案”只是为了说明需求的“方案”，对于设计只是建议，不是必须遵循的“方案”。
