我是这么回答的：

　　1.『产品经理不是经理。』

　　刚入行的时候觉得自己高高在上，或者至少觉得自己很有分量。相信大多数产品经理都这么感觉的。『我比程序员高贵。』『我是未来要成为 CEO 的男人/女人。』

　　实际上呢…

　　请自行百度『产品经理是条狗』。歌词很感人。

　　真把自己当成经理，工作上绝逼会步步维艰，什么都推动不了。

　　2. 『不管设计得再怎么样完美，需求总会改的。』

　　以前还特别奇怪，你设计产品的时候考虑周全点儿不就行了，干嘛非得改需求。但是经过了很多次惨痛的教训，终于发现，需求总是会改的。

　　改需求不代表产品经理不认真、太随意，也不是老板或者高层总喜欢拍脑门想点子，而是有很多现实原因。

　　可以列举一些：

　　市场情况变化。比如因为某些事件，用户的需求变动;或者竞争对手的动作，导致必须有应对措施。

　　运营策略变化。比如公司的运营手段不同了，导致产品上的支撑方法也要不同。

　　研发阶段暴露出了问题。比如有一些底层逻辑之前很难发现会出问题，但研发中暴露了，导致产品方案要改为更适配的。

　　时效性变化。比如由于开发周期过长，导致时效性下降，所以也没必要用原来的复杂方案。

　　临时需求插入。比如各种因素导致的，有更重要的需求紧急加入，这时必然要修整原来的方案或者延后开发。

　　虽然产品经理确实会在设计上出现纰漏，但更多情况下，产品经理只是背锅侠而已…这是我从事这个职业前没有意识到的。

　　3. 『用户很傻，而且会越来越傻。』

　　这里说的傻不是 low，也不是笨，而是用户不会愿意在使用产品的时候还思考。

　　我在入行前也觉得说用户傻的人才傻，现在是什么年代，大家的知识量、对新事物的接受程度都大不一样，什么不会用去网上搜一搜、跟朋友问一问不就好了?

　　几年前很出名的书《Don’t Make Me Think》说的理念我就不太明白，想一想怎么了。

　　后来发现在设计的时候真的很蛋疼。

　　一些特别小的问题、在用户体验上一点极小的漏洞，都会产生巨大的灾难性的后果。真的除非把用户当成小白，不然设计出的产品总会被骂。

　　比如之前朋友做的产品的一个功能，是邀请有奖。用户 A 发二维码给用户 B，用户 B 扫码下载，注册成功再去输入邀请码，两边都有奖。就是中间有个环节，用户 B 扫码下载后，90% 都意识不到要去设置里输入邀请码。

　　虽然邀请机制在各种 APP 里都有我们认为大家都很熟悉了，虽然在用户 A 发给用户 B 的使用说明里都明确写好，但是用户就偏偏不去找，也不知道去找。

　　最后怎么办呢。把用户当成小白，设计中用户 B 扫码后先填自己的手机号，才能下载。这样记录下用户 B 的手机号，也就知道他是用户 A 邀请的了。后面就不需要用户 B 再输入邀请码了。

　　就是从产品设计上来说很小的改动，让这个功能的使用率上升了好几倍。

　　空白页的设计也是很好的防呆设计。比如相册、任务表等空白页里，可以提示用户点击什么/去哪里找到新建照片、新建任务的功能。是的，现在看起来都很傻，但真的很重要……估计众多产品同僚们有过血泪史。

　　防呆、把用户当成傻子，是产品设计的基本思路。并不是说用户真傻，而是他们越来越懒，并且希望找到最不需要动脑的产品。

　　这也是为什么 T2 发布会上老罗主打的远程协助功能引起大家共鸣。这个技术难吗?不难。这个功能之前没有吗?有啊。但是发布会里演示的效果就是操作简便，老人用起来不费力，这也是产品的竞争力。

　　说到用户越来越傻，其实大家都是有体会的。各种设计都在让大家少动脑、少动手，过去的电脑要经过专业培训才能用，现在的智能手机 3 岁小孩都可以快速上手。

　　4. 『要把用户体验做好，很不简单』

　　每次用什么产品，总觉得卧槽不就是几个按钮点来点去，几个页面切来切去吗?有什么难的。

　　用户体验的话，大家都差球不多，都没啥区别，比着搞一搞就行了。

　　后来才慢慢知道，原来看起来越简单、越自然的操作，就越需要更纠结、更慎重的考虑。

　　比如很多人用过聊天时会标注消息已被对方读到的功能后，就觉得自己想得比微信远了。大家都倾向于认为自己想到的别人没想到的，就是自己有理;而自己觉得应该没有，别人有了，也是自己有理。其实微信做这个是有自己的考虑的，他们的产品经理也不傻：

　　如果我们针对需求一个人去满足，你可能获取了这部分用户，但是得罪了另外一部分用户。有人就挺不喜欢把我的已读状态暴露给别人，你想这样的话，如果你的上级找你，你看了然后你又不回，就很麻烦。

　　我们要给人撒谎的机会，我们说人性是什么?给他撒谎的机会，说我没有看到。你看短信不太准确，我们经常会说，你那个短信丢了，我们没有看到。如果我们把人都像机器一样约束起来不一定是好事。

　　我们为什么不做已送达的状态?因为我们觉得未来的系统是绝对可靠的，我们有这个信心，肯定会送达，除非他关机了，我们不会再专门做一个是不是已送达，只有不自信的系统才会做这样一个状态。而且你每发一个消息还有个已送达或者发送中，那很丑陋的，多了一个东西在那里。所以这也是一种态度。对于这种用户要什么就给什么，其实这是考验产品经理水准的东西，因为我满足需求很容易，但是你怎么找到理由拒绝他，或者说找到什么方式实现它这个非常难。

　　也是从此之后，我对很多产品有了敬畏之心，不是想当然地跟大家扯皮：『这个 APP 做得好垃圾，你看这里XXX，你看那里XXX』。

　　真是做产品经理时间越久，就越发现自己的无知。比如很简单的可用性三个字，就有所谓的尼尔森十大原则：

　　一、状态可见原则

　　用户在网页上的任何操作，不论是单击、滚动还是按下键盘，页面应即时给出反馈。“即时”是指，页面响应时间小于用户能忍受的等待时间。

　　二、环境贴切原则

　　网页的一切表现和表述，应该尽可能贴近用户所在的环境(年龄、学历、文化、时代背景)，而不要使用第二世界的语言。《iPhone人机交互指南》里提到的隐喻与拟物化是很好的实践。此外，还应该使用易懂和约定俗成的表达。

　　三、撤销重做原则

　　为了避免用户的误用和误击，网页应提供撤销和重做功能。

　　四、一致性原则

　　同一用语、功能、操作保持一致。

　　五、防错原则

　　通过网页的设计、重组或特别安排，防止用户出错。

　　六、易取原则

　　好记性不如烂笔头。尽可能减少用户回忆负担，把需要记忆的内容摆上台面。

　　七、灵活高效原则

　　中级用户的数量远高于初级和高级用户数。为大多数用户设计，不要低估，也不可轻视，保持灵活高效。

　　八、易扫原则

　　互联网用户浏览网页的动作不是读，不是看，而是扫。易扫，意味着突出重点，弱化和剔除无关信息。

　　九、容错原则

　　帮助用户从错误中恢复，将损失降到最低。如果无法自动挽回，则提供详尽的说明文字和指导方向，而非代码，比如404。

　　十、人性化帮助原则

　　帮助性提示最好的方式是：1、无需提示;2、一次性提示;3、常驻提示;4;帮助文档。

　　现在真的不敢随便说『用户体验不就是那么回事』这样的话了。

　　5. 『产品设计，尤其是交互和 UI，(大部分情况下)在一个产品中起到的作用只占 10%。』

　　这也是过去我嗤之以鼻的。牛逼的产品的交互和 UI，没有做得烂的，怎么可能起不到主要作用。

　　后来真的发现，如果功能不好用，再顺畅的交互、再华丽的 UI，都没意义。

　　比如聊微信，你发现数据丢了、记录没了，你是不会再用的;比如逛淘宝，你搞了半天都找不到想买的东西，你也不会再用。

　　再比如 12306，交互一塌糊涂(当然改版后略有好转)，验证码烂到爆，更没什么视觉效果可言，但大家不得不用啊，因为能买票，买到票就行了。

　　所以你看，12306 核心竞争力是垄断了票务，[敏感词]网站也是提供了其他地方没有的资源。交互和 UI 比起这些来微不足道。

　　这是一个方面，你会发现真的几乎没有人单纯为了交互和 UI 去使用什么产品。从另一方面说，互联网公司的成功之路上，产品设计相对于运营、推广、内容、资源，都是微不足道的。

　　你会因为滴滴打车那几个弹窗舒服、按钮合适就用吗?当然不是。用是因为补贴多，或者能打到车(有雄厚的推广资金和强大的线下运营团队)。

　　你会因为微信比别的社交 APP 简单、色调明朗就用吗?当然不是。用是因为大家都用啊，没得选(有海量的用户基础)。

　　你会因为支付宝的交互优秀、视觉突出就用吗?当然不是。用是因为安全啊，因为方便啊(有极佳的技术支撑和广泛的线下合作)。

　　有人会问，那为什么好产品的设计和交互都很不错呢?只是因为他们花得起钱雇高阶的设计师了而已…

　　6. 『产品经理要多看书、多学习。』

　　在入行前别人告诉我多看书多学习时，我不认可，我觉得产品经理应该多体验、多实践。

　　我当时想到证明我的论点的理由是：

　　互联网是千变万化的，产品经理又是很新的职业，过去的书和知识不能提供帮助

　　产品经理需要的都是软实力，比如逻辑判断、沟通能力、审美和创新能力

　　产品经理并不需要太多技能和成体系的方法，尤其是工具、流程和制度，没有通用的

　　只要够聪明，在摸爬滚打中同样能快速成长

　　于是摸爬滚打一段时间后，再开始看书、虚心跟牛人学习，才意识到自己犯了很大的错误。

　　按刚才的顺序，倒着来说。

　　关于成长

　　够聪明的确能快速成长，但是产品经理的工作周期很长，也不像工程师或者设计师，做的成果很快就能得到检验。产品设计和项目跟进做得好不好，很有可能是要通过长达数月甚至半年的检验。

　　自己摸爬滚打的成本很高，还是建立在学习能力足够强的基础上。

　　而产品设计或者项目跟进的工作，可不像写代码一样，调试时就会报错，甚至还会告诉你怎么改。产品经理的工作你可能做了一年，成果有好有坏，但你很可能不能发现原因，也不知道好的怎么保持、不好的怎么改正。

　　所以明明通过别的途径能少走弯路，却偏偏要靠自己撞墙来学习，这是不合理的。

　　关于技能和方法

　　确实没有通用的技能、工具和制度，比如有的团队喜欢 Axure，有的就喜欢 Keynote。有的喜欢把文档按照交互逻辑整理，有的喜欢按照功能逻辑整理。大公司讲究格式和流程，小团队追求效率。

　　这只是说浅层次的，在深层次的概念和方法论，却不仅可以算是通用的，简直要说是必备的。

　　比如刚刚说的用户体验中可用性的原则，再比如用户体验的五大要素(层次分类方法不一样，但道理都相通)。还有大致有几种图片排列方式啊、有哪些注册登录方法啊……这些海量的知识，如果不去有针对性地学习，很可能需要自己折腾几个月搞明白一个地方的做法后，才发现在知乎上别人已经答过了，看一眼就全明白。

　　前人的经验在这个方面显得特别重要。

　　关于软实力

　　逻辑能力、沟通能力等等，都确实是产品经理要具备的。但这些能力反而更需要系统去学习。

　　从逻辑方面来说，有的是能应用于日常生活中的逻辑科普书籍，讲社交和沟通的更多。其他的能力比如管理能力、组织协调能力，也都是成熟的大企业已经总结过成熟的方法论的。

　　这些仅靠个人领悟，不知道多久才能悟到书里能达到的水平。

　　关于变化

　　我在读很多书时看到例子觉得老，就有点嫌弃了。估计大家都有这种感受。书的出版周期很长，所以时效性难免差一些，不过主要是指例子。

　　在读了很多关于互联网、创业和产品的书之后，我深刻感觉到，除了例子很老，绝大多数的方法论、道理和逻辑，都是不会过时的。

　　这简直打开了新世界的大门。我翻了很多出版三五年，甚至七八年的书，发现现在遇到的问题居然都能得到解答。Web 时代的很多分析，用在移动互联网只是在实现层面有差别，在底层逻辑上完全一致。这也是为什么《用户体验要素》是差不多上个世纪的作品，过了 15 年仍然是产品经理们的必读书籍。

　　就拿《启示录》举例子吧。这是 2008 年的一本书，但关于产品设计的内容，到 8 年后的现在都是适用的。

　　比如很多朋友会问我的问题：『外包团队靠谱吗?有什么问题?』

　　书里提到(作者把外包成为定制)：

　　长久以来，开发定制软件困难重重……虽然需求存在，但客户通常不知道自己想要什么……等到交付软件时，客户往往发现到手的软件和想象中的相差十万八千里，于是又要求开发人员修改，如此恶性循环，客户屡屡失望而归。

　　定制软件的客户认为自己了解自己的需求，所以不需要什么产品经理，他们也不需要用户体验设计师……客户不理解什么是用户体验，以及对成本过于敏感(让开发人员设计产品可以节约成本)。

　　是不是特别眼熟?

　　换句话说，这就是现在到处问『开发个 APP 到底多少钱呀?』『我让外包做的产品怎么不满意呢?』的土老板们遇到的问题。

　　他们既不理解为什么需要产品经理和设计师(不就是放几个按钮、画几个图标吗?)，也不理解为什么外包团队总是做不满意(告诉他们大概的样子，实现不就行了吗?)。

　　我见过的所有的，真的是所有的，外包团队的作品，都会遇到这样的问题。

　　我再摘录几段话，看看是不是感觉特别有道理、特别眼熟。是的，这些在我之前的答案中都出现过。

　　许多产品团队没有意识到，或者很晚才意识到要转变工作重心。更糟糕的是，产品经理还时不时冒出新点子;公司高管认为产品文档还可以继续修改，导致开发要求大幅变更，严重影响开发团队工作。结果不是发布日期一推再推，就是某些功能被迫取消，或者产品质量下滑。

　　这段话说的就是我提过的『产品经理不仅要想点子，还要保证产品的实现』。

　　在我看来，每当团队内出现严重的意见分歧时，并非是大家对事实的认定有争议，而是对目标和目标的优先级有不同的理解。

　　这是我提过的『有争执时讲道理都可以解决问题，除非大家价值判断不同』。

　　我无法想象不深入理解用户需求，特别是在禁止与用户面对面交流的情况下，产品经理怎样打造出让用户满意的产品。

　　这是我提过的『任何事情都看用户的需求，做判断，而不是主观上做太多自以为是的设计』。

　　目前流行的研发模式通常是这样的：创业者想到一个好点子，得到启动资金后，马上招聘程序员开发产品。由于创始人最清楚要做什么，因此，他通常会扮演产品经理和产品设计师的角色。开发团队则按照他的想法实现产品。这些创业公司一般在『秘密状态』下运行，很少与用户互动。另外，由于产品需求和创意往往边做边变化，开发进度相对较慢。

　　这里面同时提到了创业中『创始人会兼任产品经理』、『创业过程中太过频繁改动需求』和『创业者过于关注自己的点子的保密性』的问题。难以想象，08 年美国就流行的事情，在如今的中关村和望京 SOHO 重新上演。

　　我看书的时候边看边拍大腿，一是因为说的太有道理了跟我想的一样一样的，二是妈蛋为什么没有早多些读书。

　　7. 『程序员总是会讨厌产品经理。』

　　不管怎么讨好程序员，他们总会讨厌你的，不用太担心是不是自己做得太差。协作中尽量公正就好啦。

　　具体原因?还用说吗。参见第一条。

　　希望能帮到你。