作为领导者，应该广纳谏言，还是应该坚持己见？这其实是一个没有标准答案的问题。
所谓成功学往往事后诸葛，一个人比较独断专行，如果成功了，就是坚持信念，有自信。如果失败了，就是不听人意见，太自负。如果一个人耳根子软，也是同理，正反都可以说的东西，你怎么给结论呢？
确实，我们看到很多两方面的案例。因为盲目自大，不听人言而走向衰败的企业。因为误信人言，盲目转型，自废武功而衰败的企业。两边都有坏案例，也都有好案例，这事怎么说呢？没有标准答案，但是有一些原则。
第一原则，不妥协原则。
这既是一个产品原则，也是一个管理原则。如果你的产品试图讨好所有人，让所有人满意，结果很可能就是一个非常平庸的产品，毫无特色和亮点。好的产品，我之前提过一个观点，让一半人尖叫，一半人离开。在对产品定义和目标追求上，很多时候，极端与偏执并不是贬义词。在团队协作和管理上，不要试图讨好所有人，在需要决断的时候，不要试图和稀泥，不要试图搞平衡，要坚持你的原则和目标，这一点特别重要。很多大公司，在相当时间内无法开发出令人激动的产品，就是产品经理所受到的各方面的要求和压力太大，经常要采用平衡和妥协的办法来设计产品，到最后，就是一个什么都满足但毫无特色的东西，然后，就没有然后了。
第二原则，允许质疑原则。
很多创业团队的创始人，往往个人能力很强，初期带领团队从一个胜利走向另一个胜利，但这也很容易导致盲目自信，在后续的发展中，听不进任何意见和建议。一些巨头公司也出现老板被神化的情况，而且这种情况颇为普遍。一个领导者、一个企业，如果不允许员工质疑自己的决策，不允许员工批评，这其实是很危险的。领导人很可能陷入危机而不自知，犯了严重的错误而不自省。
在我的理解里，这两条原则并不冲突，当然，其中有一个度的把握。实际上，就算你掌握了这两条原则，也很有可能做出错误的决策和烂产品，所以在实际的工作中，是没有所谓标准答案来指导你的，具体情况复杂多变，曾经正确的理论也可能早被颠覆。但我依然希望每个试图加强领导力的人，能体会并理解这两条原则。说到底，容人之量，听得进批评其实是一种自信，你相信自己的判断力、自己的眼光，你就能听得进别人的批评和质疑，并取其所长为己所用。反过来，有些人之所以听不进去，是生怕别人是对的。比如三国时的袁绍，就是此类，所以才有田丰的悲剧。今天要做一个总结，兼听则明，是有前提的，没有主见和自信的人，兼听是不会明的。
处处皆学问
我们经常会遇到这样的问题，很多人都是在做同样的事情，都是在完成同样的工作，为什么有的人起来得特别快，有的人就差很多。
日常大家都是刷朋友圈，为什么有的人就总能找到好的机会，有的人就总是慢人一步。大部分人会认为这是运气，是命，但我要说是因为对同样的事情的观察视角不同，在判断、学习、成长中极大的差异。
保持对信息的敏锐，保持好奇心，足够敏锐，足够好奇，你才会发现生活中处处皆学问，处处皆商机；你才会保持不断前进。那么，怎样才能敏锐，怎样才能好奇？说到底，还是你看问题的视角，即怎样在平淡的信息中，找到价值点。
实例说话
1.大家都逛淘宝。
大部分人看的是，哪个货物好，哪个东西你喜欢。
敏锐的人看的是，店家用了什么招数，使用了什么心理暗示，来提高用户的点击率、转化率。
思考题：如果你来做苹果官方天猫旗舰店产品描述页的优化，如何提高成交量。如果是非知名品牌呢？
2.很多人都刷朋友圈。
大部分人看的是，哪篇文章写得好，哪篇文章我想分享给朋友。
敏锐的人看的是，这篇文章用了什么方式让你获得认同感，它的访问量多少，点赞数多少，为什么那么多人点赞，哪些人在转发，为什么他们会转发？
思考题：常见引起大规模转发的心理诉求有几种，在不掉节操的情况下如何写一篇广为流传的文章。
3.很多人都在微信群斗表情。
大部分人看的是，这个表情“碉堡了”，我赶紧存下来。
敏锐的人看的是，什么类型的表情在什么人群中容易被传播，一个传播广泛的表情包系列需要有哪些考虑。
如果你够敏锐，有好奇心，这些资料藏得都不深。
思考题：如果你需要做一个品牌推广，基于什么原则设计该品牌的表情包并如何启动推广路线。
4.天天看新闻，看媒体，看各种文摘。
大部分人看的是正文。
敏锐的人会看到，这么low的广告怎么又在底下出现了，为什么这个广告一直出现，看来能赚钱？
思考题：你知道什么类型的广告主适合什么类型的媒体吗？
5.很多人玩游戏，乐此不疲。
大部分人看的是，这游戏怎么升级，怎么能变得更强。
敏锐的人看的是，这游戏在吸量上是怎么设计的，适合什么人群；付费点怎么设计的，针对什么用户心理，对非人民币玩家、小人民币玩家和大人民币玩家的平衡是怎么设计的。
思考题：如何快速评估一个热门游戏的收入能力和核心付费人群。
以上仅是一些最常见的例子。他在天天玩游戏，刷朋友圈，我也是，为啥他创业成功了，我还是一个月几千块的打工者。因为你只看到表象，后面的真不一样。
日常工作也是同理
你天天给老板写报告、分析数据，老板要什么你做什么，这是一个常态。但是你对每个数据都好奇，都深究，对数据的变化追根问底，你的体会就会远远高于前者。
你做客服，把问题罗列出来扔给产品和运营，这是一个常态。你通过反馈分析客户的特征和心理诉求，然后整理出产品或运营优化的思路和方案。当然，很可能是不成熟的，会被批一顿，没关系，你知道哪里不成熟，为什么被批，这不也是一种成长吗？
你做市场，组织各种营销活动，钱也花了，效果也打出去了，你觉得任务完成，蛮好的，这是一个常态。你深入追踪把合作伙伴花钱的细节和效果跟踪的细节咂摸透，深入了解不同渠道、不同投放效果、不同合作伙伴的投入转化比，知道投入到哪里的钱效果最好，投入到哪里的钱其实浪费了，你这样下去境界肯定比前者高得多。
你做技术，把代码提交了，BUG解决了，任务完成了，蛮好的，这是一个常态。但你写代码的时候多想几个为什么，如这个需求的最终目的是什么，其产品形态中的哪些诉求是可以深挖的，哪些是可以简化的，哪些未来是需要考虑扩展的，哪些是权宜之计不用太费精力的，等等，多想一些，你的职业道路就会宽一些。
在职场里写程序，很多优化诉求产品经理是给不出明确的方案的，比如推荐算法，搜索优化逻辑，他们只能给出一个效果评估方法，那么技术人员从哪里思考、如何思考，就需要对业务、对用户行为特征有认识，有了解，这和大学参加算法比赛不是一回事。
你说你算法能力很强，编码技术很高，是因为在学校参加算法大赛，别人把边界条件、详细的场景和诉求都明确给你了，但是在实际工作中，很多优化工作需要你自己去提出问题，挖掘需求。产品人员不懂技术，他们只能从评估体系来看到问题，甚至看不到问题（这也取决于产品人员的分析问题能力），你很可能需要自己来发现问题。（优化和完成功能不一样，大家都不知道优化的极限在哪里，所以这里永远有挖掘点，而且通常会超出产品人员的视野。）
中国和美国，程序员出身的顶级富豪都有一大批，你说为什么人家成为创业典范而你还是“码农”，一步登天的招谁都教不了你，先把视界抬高一些总没坏处。
关于产品与技术沟通的一些建议
沟通成本过高是很多企业项目研发中经常遇到的一个问题，无论是初创企业还是大企业，而造成的工期延误、人力资源的浪费也是非常惊人的。很多产品人员觉得主要问题是技术人员不配合，不理解他们的描述；而技术人员则抱怨产品人员需求变动太快（很多时候是同一个需求，表达方式发生了改变），经常前后不一致。那么，我们试图去提出一些可供参考的建议。
第一要旨：产品人员在提出功能需求时，应明确告诉开发人员，其需求的目标是什么。
很多产品人员做需求设计，给开发人员的时候只告诉开发要做这个这个，那个那个，而并不具体说明为什么要做这些，也许他们认为开发不需要了解这个，也许他们认为开发应该一看就明白这是什么，但实际上，往往这里就产生理解歧义。此外，产品人员，特别是没有技术背景或技术背景一般的产品人员，有时候会替开发人员多想，比如会认为这样做简单而那样做复杂，但可能技术实现成本并不是他想象的那样，而对于创业公司，实现成本往往也是特别需要考虑的因素，产品人员往往没有给出实现成本最低的方案，而开发人员则盲目按照定义的需求出发，有时候做出的东西从实现成本上来说非常不经济，特别是时间成本，消耗非常巨大。
在符合第一要旨的前提下，开发人员应能参与需求的讨论，我知道有些大公司或者产品经理不希望这样，他们可能会认为，我定义好的需求你去实现就好了，你做研发的讨论这个干什么？但这样其实是有好处的。
1.研发人员的参与意识强，对产品的热爱度和积极性会提高。
2.加深对需求目标的理解，减少开发过程中因理解歧义做无用功或不符合需求的状况。
3.有可能提供目标一致，且实现成本更低的方案。对创业公司，开发力量不够完善的场景而言，这一点也非常重要。
当然，强调一点，研发人员可以参与需求设计的讨论，但决策权仍需要明确掌握在产品经理手里。
第二要旨：产品人员应给出所有功能需求的流程和结构图。
在给出具体功能需求设计之前，应给一个总纲，也是为了加深需求理解，形成完整的需求概念的一步重要工作。很多时候，产品经理会觉得，我说得都那么清楚了，你怎么不明白呢？其实主要就是因为在这个环节上，产品经理对整个项目的背景、结构、前提、目标早已有了代入感，所以觉得每个细节都理所当然是这样的，但是对研发而言，他们并没有得到完整的背景信息，对细节的理解往往就出现偏差和误判。
比如，用户的某个属性，在某个功能中体现出来，而在另一个功能中产生变化，但是因为需求设计的时候，没有给出整体的结构和流程，只是在局部的设计中提供了不精确不严谨的描述，那么，实现设计的工程师（甚至可能两个不同功能是不同工程师实现），也许会误判做成两个不同的字段，赋予不同的定义。这样这个属性的实现就彻底错了，而在上线前双方都没意识到存在这样的问题。
第三要旨：具体视图设计的三要素。
不论是设计网站，还是设计App，基本都是由一个到多个交互视图组成需求设计。
产品设计人员在提供这样的交互视图时应给研发者如下三要素。
1.界面元素。比如哪里是文字，哪里是下拉框，哪里是按钮，这些属于界面元素，可以用草图，或Word简单排版，但要明确界面上的元素是什么，如何展现，是静止还是浮动？
2.数据逻辑。比如页面这里是最新新闻，那么你要说明，这个最新新闻是基于怎样的数据逻辑获取的。有的产品经理说，这不是技术活吗？我怎么知道？要是真不知道，就要跟技术人员沟通这个问题，看看你需要这个地方出现的东西体现出怎样的一种特征，然后问他应该怎么来设计。然后你也要参与思考，这个数据逻辑是否符合用户的预期，以及在运营中是否会出现一些位置会固化、新数据无法体现的问题，这些都是产品经理要思考和确认的，不能甩手给技术。
3.操作逻辑。界面上可以进行操作的有哪些元素，哪个可以点击、可以选择，操作后出现怎样的反馈，比如显示浮层，进入新页面。这也是要在需求设计文档里说清楚的。
一个视图的设计，说清楚界面元素、数据逻辑、操作逻辑，开发者才能明确这个视图的开发需求。不要让开发的工程师自己去猜，去揣测。如果有些逻辑涉及算法，产品经理不清楚，也要与开发者确认他所采用的逻辑是什么，以及效果是什么，并与自己所预期的效果做比对，而不是说，这个我不清楚，让工程师决定。操作逻辑可能会指向其他视图，这就是前面说的，结构流程图要说明的地方。
在百度这样的公司，产品经理要写烦琐冗长的MRD（市场需求文档）。但对创业公司而言，还是尽可能简单直接有效最好。
说一个执行中的要点，当产品经理给技术人员展示完文档，表达完需求后，最好的一种确认方式是让技术人员按照自己的理解重述一下需求，重述的过程往往容易暴露出理解的歧义。你要确保你表达的与对方理解重述的一致。