职责之一：引导决策者将用户和市场需求转化为明确的产品目标。

实施原则：做问题的提出者，分析和解决方案的引导者。

这不代表，你不用去分析和做解决方案，你需要尽可能多的分析和尝试建立更多的方案，对解决方案的优劣有深切认知后，你才会有针对性的提出问题，为解决方案做出导向。

在与决策者的谈判沟通中，做一个谦虚的记录者，记录下一个个方案的产生和比较过程。适宜的提出引导问题，为优劣筛选的评判依据提供线索，最终产生明确的产品目标。

当有确定的目标后，把会议记录邮件发送一下做为存档非常有必要。因为决策者往往在过了一个晚上后，会把之前的结果推翻，如果没有记录，你需要重新沟通，把引导过程再进行一遍。几次三番地把产品目标推翻，甚至产品开发到一半了还犹豫不决的决策者并不少见，也很容易理解，决策焦虑使然。重要的答案，得到的不能如此轻而易举，一定要经历些波折痛苦，才能让那颗小心脏平复下来。

职责之二：确保产品开发过程中目标明确不偏移，产品细节的战术实施也要淋漓尽致的体现战略意图。

最终做出的产品价值鲜明，富有生命力。才算将职责履行完整。

一个产品经理如何参与到产品的设计和开发中呢？

主要方式就是沟通。当然很多产品经理，喜欢深入到设计、开发或测试一线的方式工作。他们认为这样可以给自己的领导力加分，同时距离更近，交互更频繁，沟通会更加顺畅自然。当然很多时候又是情势使然，也都无可厚非。

那么，沟通的原则是什么？换句话说，你认为产品重要还是开发产品的人重要？

当你和老板沟通时，一般不会有这个问题。大多情况下，你会下意识的认识到，老板更重要。当有分歧时，你自然而然会想到要照顾老板的情绪。

当面对开发人员时，许多产品经理会用压制的方式令团队成员服从。在其拿着“产品至上”，“用户体验为王”的理论招摇时，就更让人厌恶。

以人为本应当是你在沟通时的一贯原则，无论对象是团队中的小程序员还是大老板。团队成员不愿听你的，并非不懂用户体验，而是讨厌你对老板谄媚对普通成员压制的不同处理方式。

● 需要注意的第一点：不要滥用你的领导力！

认可你的领导力是一回事，被领导力强迫压制又是另一回事。不沟通解决，问题就会一直存在。团队成员关于产品执行上的困惑，很可能隐含着对产品设计是否合理的疑虑，不沟通你就失去了发现问题和得到启发的可能性；

● 需要注意的第二点是：湹清职责边界

产品经理往往脱胎于设计师或工程师，有时还承担着相应的工作，承受不同方向的压力。往往项目一紧，就放弃了自己产品经理的职责。目标决策变成了公司谁说了算听谁的，产品一日三变；产品实施上怎么快怎么来。离目标渐行渐远，最终的产品，用户看不到价值所在，因而没有生命力。

提几个常见的面对设计开发人员的沟通案例：

● 问为什么要这样做

这是空洞的质问，于事无补，反遭嫌恶。

可以直接问，这样会有1、2、3项缺点，还有更好的方法么？

或者说，实现4、5、6的优点更能体现产品价值，你认为呢？

● 问能不能做

这不光给对方造成压力，还容易埋下冲突的隐患。能不能做都不知道，说明你的功课没做到位。

● 拿出一个案例，说别人能做，为什么我们做不了。

为别人保留尊严，是起码的职业素养。不提案例，直接把案例的优点建议出来，看能不能有所启发，留出块空地，让他练练。

● 这样做难道不是应该的吗？

同样是空洞的质问。请直述你所谓“应该”带来的优点，一二三摆列清楚。

沟通如此重要，建议每一位产品经理都去读一下谈判课程，全面掌握沟通技巧。

一个产品团队就像一支征途上的探险队伍，有勇敢的领队、有各怀功夫的队员，也有机智敏锐的向导。产品经理的角色，就是队伍中的向导。遇到叉路要多和领队沟通，提醒大家哪里会有危险。

产品经理最常用的沟通方法：问题引导法。

先了解对方遇到了什么问题，然后用问题引导至分析和解决流程中。

产品方向上，面对老板，通过用户和市场需求的问题引导形成产品的目标定位。实施中，面对设计开发人员，通过问题引导分析具体方案的优劣。

最后，再强调一下：

● 你不是老板，不要想当然的直接摊明目标；你也不是实施者，不要提出具体的实施方案。

● 你的细节建议要有理有据。 

让老板看清问题自己拿主意，享受决策的快乐。让实施者瞄准目标自己去解决，享受创造的快乐。

本文首发于微信公众号：软件湾。欢迎关注。