这特么是什么玩意儿？和我说的根本不一样！这算完成了么？”为什么在产品开发的过程中总是容易出现定义和交付分歧呢？特别是甲方的产品，经常听到需求方说这个不对那个不是，作为产品经理又如何解决呢？
这是问题的致命起因，产品经理应该成为业务专家。
较为常见的是，产品经理在收集需求的时候，听着客户一顿胡吹，整个人就已经失去了判断力，无法有效的跟客户确认真实的场景，也没有能够有效的引导客户朝着正确的方向集中注意力。
出现这种现象的根源在于产品经理对业务的理解出现了偏差。可能是未理解真实的业务场景，也可能是过分解读了用户需求，还可能是被用户下了套，把某个用户的需求达成了大众需求，甚至还把用户的“解决方案”当作了需求。
所谓解决方案与真实需求，最简单的理解就是“嘴上跟你说的”，和“心里真正想要的”，这不是用户言行不一的有意忽悠，而是用户基于他自身的理解，所寻找到的他认为最合适的办法。
比如，用户说“我要一把锤子”，作为产品经理你应该怎么做？——最恰当的办法是，追问他为什么要，用来做什么，以及什么时候要。这就是引导和挖掘用户需求，哦，原来他是想要把结婚证挂在墙上。也就是，用户实际上并不一定是要“锤子”，还可以是其他工具，而真实的情况下，我们往往可能考虑怎么弄一把漂亮精致的锤子，我们总是在思考锤子的造型是怎么样，手感是怎样的。
产品经理在接受和分析用户需求的时候，务必保持清醒的头脑。用户想要的任何功能，都一定代表着他在某一个点上的想法和期待，但并不直接等于用户需要解决的痛点，用户只是在提他的方案而已。你需要反复的倾听，求证，甚至反复做情景模拟，才能真正确认他们的需求。
放下你“专业的偏见”吧，用足够的耐心倾听来自多方的声音，去和用户一起模拟真实场景下发生的每一个细节，去找到那个带有普遍意义的“为什么”，从行为上倒推真正的需求痛点。
不可掉以轻心，更不能草率决策，不要轻易的认为你已经理解用户的需求，更不能片面接受用户的需求。你需要有立场，有方向感，在接受用户需求的时候，要能够反推场景，并引导用户，甚至去改变用户的惯性认知。
不能让用户理解你的设计
首先，作为产品经理，你应该建立一种心理自信：
我是为更好的解决用户的业务问题而来，而不是简单把线下业务转化为线上的系统功能。这一点，会让你有一种心理优势，也能让你避免一种身在局中的迷茫。我们要承认一点，想要与熟悉业务的用户达成一致是有难度的——毕竟他的痛点，他的习惯，早已不是一两天的事情了。子非鱼，安之鱼之乐（苦）？
对产品经理而言，当你具有一定的产品经验之后，你很容易就会形成一种本能的判断，或者说是产品直觉：面对用户的任何想法，你往往能够快速的在脑子里面构想出你的解决方案；甚至会快速的在脑海中得出一个结论——这人就是个是傻瓜，“这种想法居然也会有”，“这种事情也会发生”。
你也很容易产生一种“凌驾于用户”之上的想法优势，正是这种隐形的因素导致与用户的心理对立，你与用户产生一种不可预知的隔阂，而你的用户，也正在快速的形成一种对你专业的偏见，结局是你不认同他的问题，他不接受你的方案。
产品经理有很多优秀的工具来应对和解决用户的理解与认知问题，在我看来，所谓的专业技能，大抵就应该是协助你解决与他人的分歧。
思维导图
你可以借助思维导图的工具，充分的收纳用户每一个想法，并基于某一种逻辑规则进行问题的分类和筛选，并与用户达成对“问题本身”的一致认可，确保你采集到了最全面和最原始的素材。
记录和分类的方法有很多，但你至少得保证动词和名词不要搞混，所以这需要你有一种比较清晰的表达素材的能力，比如“接入第三方的内容”与“第三方内容的接入”，细细推敲这其中是很有区别的，你需要一种能清晰表达并能够有效分类筛选的方式，快速的把用户嘴上说的，和心里想要的，以及你需要做的与用户进行确认。
业务流程图
流程图的绘制是产品经理的必修课，流程这个词，意味着一种顺序，解决的是什么时候做什么，以及出了异常怎么办。你可以不太讲究流程的“画风”，但一定要学会区别什么是用户动作，什么是业务阶段，什么是结果输出，你也需要严谨的分析逻辑条件，以及用户角色在整个过程的影响。
从我的经验来看，越是复杂的，多环节多角色的业务流程，越需要高超的流程梳理与流程图的绘制能力，作为产品经理千万别整出状如蛛网的流程图，它会让你，以及你的整个团队陷入一团乱麻。甚至可以说，当你看到你的流程图在交叉并呈现加剧的现象，基本上意味着整个流程开始陷入复杂、低效的局面且不可逆转。
这种专业能力，是你能否与用户达成一致的基本要求，它代表着你是否真正理解用户以及是否理解用户需求，也代表着你是否已经足够清晰的开始解决用户的问题。你需要提供一份让你接触的每个用户都能一眼看明白业务分析图和业务流程图，才能和用户坐下来达成一致。
不能在团队内部真实的传递需求
在信息传递和寻找解决方案方案的这个环节上，是很多产品经理最容易与内部团队产生分歧的开始，最终导致产品与用户期待的分歧。
产品经理有意无意之间，会成为一个信息的黑洞——或者说信息漏斗。产品经理会出现不能有效将用户需求带给团队的现象，当然也可以认为是产品经理基于自身“专业”的分析，过滤了用户的不合理需求。
作为产品经理，在获取到需求之后，除了自身提出的解决方案，还应当在团队内部获取到更多的灵感和解决方案——前提是：必须确保用户场景被有效的传递和真实的还原。
在这个问题上，其实对产品经理有非常高的要求，你不但是要深入的了解用户，深刻的理解用户需求和应用场景，还需要有很强的逻辑能力和表现能力，生动而又不失严谨的向团队成员传达业务过程和实现细节。
在面对用户需求的问题上，产品经理和团队内部的任何一方，都应该摒弃哪种“我有信息来源”的心里优势，而应当把信息尽量的共享才能够充分的交互意见，不要人为的设置信息障碍，信息本身不能作为一种能力，集团队之力解决用户的需求才是。
很多问题，其实有更好的解决办法，可能是更好的交互方案，也可能是更优的技术方案，当然也可能是业务上的优化，这一点甚至比产品本身更有效。作为产品经理，除了足够真实的还原需求之外，还应该尽最大努力促使团队达成一致的理解，答疑解惑，并充分发挥其他专业的力量，寻找最优化的业务解决方案。
当你没有把内部搞定的时候，你交付的产品往往搞不定外部的用户。
不能帮助客户在内部达成一致
A部门的需求不是B部门的需求，A领导的意思B领导不接受。这种情况在跨部门的需求以及甲方项目中最容易出现。
这里有一个专业词汇“干系人”，也就是项目的利益相关方没有理清楚，不知道哪些问题需要解决，也不知道哪些人的环节要走通。还有一种情况是，客户内部的官僚主义导致的，一种“很奇怪”的互相扯皮拖后腿的现象。一旦出现这种局面，搞不好整个项目都可能烂尾。
解决这样的问题，很可能已经不是产品经理可以独立应付，你需要借助更多的力量和途径才有效。换句话说，这种项目从一开始，就已经不再是单纯的业务问题，而更多是一个管理问题，需要有更多的维度去思考项目的全部“利益相关方”的影响（正向/负向）。
作为产品经理，特别是对于（甲方）的项目，你应当在项目的萌芽阶段，就应该开始着手做相关的准备（或者借助其他渠道/力量），在项目的启动、进行，甚至包括结项的全过程，应该充分发挥团队的集体智慧，特别是来自商务端的信息，响应以及支援。
后记
对产品经理而言，业务的边界、需求的定义其实仅仅是一个产品生命周期中的一些节点，“产品经理的专业技能”仅仅是保障整个过程良性运转的基本要素。
