24《叫我如何对你说》中国产品经理联盟.docx
《24《叫我如何对你说》中国产品经理联盟.docx》由会员分享，可在线阅读，更多相关《24《叫我如何对你说》中国产品经理联盟.docx（27页珍藏版）》请在冰豆网上搜索。
24《叫我如何对你说》中国产品经理联盟
中国产品经理联盟《叫我如何对你说》专题暨第24期网络简报
前言
在产品管理界，对产品经理有一个形象的比喻，被称为“沟通技术和市场的桥梁”，从这个比喻中我们可以看出，产品经理大部分的工作时间都是“泡”在市场和技术部门中。
因此，对于产品经理来说，和市场、技术部门同事进行有效的沟通是确保产品计划顺利执行的关键因素之一。
但是，现实的情况却让许多产品经理朋友们感到非常郁闷，一方面是因为我们对市场和技术部门的同事没有直接的管理权限，这是公司的组织形式所决定的，我们通常是无法改变的，而更重要的一方面是因为我们所要面对的市场、技术部门的同事，往往都有自己的性格特点，不同性格的同事在对待同一件事情的时候，往往会表现出不同的态度。
而作为产品经理，要带领的产品团队就是由这样一大群性格各异，脾气秉性完全不同的精英所组成的，我们如何能够让这个精英云集的团队按照既定的产品计划开展工作，这对于任何一个产品经理来说，都绝对是一个挑战。
而这，往往是我们可以通过自己的努力可以改善的。
这也就是我们这些产品管理人认为应该具备的第一素质-沟通能力-的最现实表现了。
在B2C行业中，大部分的产品经理很少有机会能够直接和客户进行交流，但是在B2B行业中，肯定对产品经理会有一个很高的要求，就是必须能够和自己的客户（这里的客户不仅仅指产品的终端客户）进行有效的沟通，甚至有时候还必须为销售人员提供最直接的支持，帮助他们完成销售任务。
因此，如何和客户进行有效的沟通，对产品经理来说也是一个非常重要的工作。
因此，联盟策划了《叫我如何对你说》这个专题，这个专题里包含三篇文章，分别是：
1、《如何与技术人员沟通》2、《如何与市场人员沟通》3、《如何与产品客户沟通》
这三篇文章完全是联盟的朋友根据自己的工作体会总结而成，都是非常具有现实意义的，如果大家能够从这个系列中体会到一些有价值的东西，那么，这个系列的目的就达到了，联盟更希望的是大家都把自己的工作体会记录下来，和大家一同来分享。
如何与技术人员沟通
【摘要】产品经理在日常的工作中，我个人认为，接触最多的就应该是技术团队的同事了，大到新产品需求的商讨，小到一个产品bug的提交，每天至少要花40%以上的时间在这个方面，尤其是到了产品研发阶段，花的时间就更多了。
大家都说做技术的人虽然执着但是产品视野不够宽广，精于技术但是对市场不够敏感，尤其是在打交道的时候，总是在这方面发生争执。
那么，技术团队的同事都有什么样的特点呢？
我们应该如何进行沟通才最有效呢？
我总结了一些个人的体会，和各位朋友交流一下。
1、闷头干活型：
先看一个案例：
PM：
这是用户提出的要修改的一个地方，你看能做吗？
Looking……
程序员：
能做！
PM：
今天下班前能完成吗？
程序员：
能！
PM：
不影响现在的项目吧？
程序员：
没事，我加班做吧！
……
然后开始做，再不多说一句话，即使下班前没做完，也会真的去加班赶工。
这就是典型的“蒙头干活型”的技术人员，这类技术人员最大的一个特点就是“一切按照安排做，几乎不发表个人意见”。
其实遇到这样的技术人员，对于产品经理来说，是比较幸运的，因为这样的技术人员从项目管理的角度来说，就意味着“放心”，第一，他们一切按照公司安排来进行工作，第二，他们会努力按照要求的时间完成工作，即使加班加点也要完成。
这点是产品经理最愿意看到的，在产品团队里，多几个这样的技术人员，通常就决定了产品项目周期是否能按时完成。
但是，从另一方面来说，这样的技术人员也存在一个严重的问题：
就是足够努力，但是不够灵活。
对安排下来的工作，没得说，肯定按照要求按时按质完成，但是很少能从整体去合理安排自己的时间，毕竟产品经理不了解你手中的工作进展是怎样的，突然临时给你加了一个活，也不重新评估一下个人项目时间，或者是知道对现有项目会有影响，但是憋在心里不说，直到最后影响到现有项目了，只能自己一个人去加班加点去做，想想，也挺难为这些同事的了。
作为产品经理，如果遇到这种类型的技术人员，需要用“抛砖引玉”的方式来确定他的工作时间，例如可以这样问：
PM：
这是用户提出的要修改的一个地方，你看能做吗？
Looking……
程序员：
能做！
PM：
你现在手里还有什么项目吗？
程序员：
有XXXX，XXXX！
PM：
是比较着急的项目吗？
程序员：
XXXX要求明天下班之前完成的。
PM：
你估计我现在给你的这个活需要花多长时间呢？
程序员：
我估计怎么也得半天吧。
PM：
这样吧，这个活先放到你这里，我去和你们的经理协调一下，然后再通知你，怎么样？
程序员：
行！
……
刚才说到了，这类技术人员的特点就是“一切按照安排做，几乎不发表个人意见”，也就是说无论是产品经理安排的，还是部门经理安排的，或者是其他人安排的，只要是涉及到技术方面的工作，他都会无一例外的重视，而这种重视很大成份上是无原则的，即没有项目级别的思想，安排什么，马上做什么，好的说是“负责”，不好的说是“死板”。
因此，建议通过引导的方式来确认项目的时间安排，这是因为他们不一定没有想法，或许是有想法但是不愿表露，也许是性格决定的，也许是职业压力决定的，但无论怎样，一定要让他们说出来。
这种类型存在于两类技术人员中：
第一是参加工作时间不长的；二就是完全性格内向的。
2、技术痴狂型：
先看一个案例：
PM：
这是用户提出的要修改的一个地方，你看能做吗？
Looking……
程序员：
我觉的这个地方有些问题呀？
PM：
哪里有问题？
程序员：
你看，这个地方我觉的这样做不合适，应该……
开始讲解他认为最好的方法。
PM：
那如果按照你认为的方法做的话，需要多长时间呢？
程序员：
我也说不好，这种方法我没用过，不过我可以试一下，这样吧，等做完了，我通知你吧！
PM：
……
这是典型的技术人员，这种类型的技术人员天生就是做技术的料，他们对于解决问题所涉及到的技术的痴迷要远远大于项目、产品、市场本身。
他们可以花一个晚上的时间去研究如何解决一个问题，他们喜欢在技术上的挑战，喜欢采用自己在理论证实可行的方法来实践，但是恰恰忽略了他们做的是产品，是要用来为公司盈利的商品，产品只不过是提升他们实力，验证他们技术理论的平台而已。
他们始终追求的是“最好”，而不是“最合适”。
可惜中国大部分的IT企业不是微软，不是google，在微软和google有专门的部门来负责新技术的研发，也就是实验室，而大部分的技术人员还是需要按部就班的去按照公司计划去执行开发任务。
这类技术人员其实就是没有给自己一个很好的定位和角色调整。
在公司，你就是程序员，就是按照公司计划和安排去做技术工作，在工作之余，你花多少时间去研究新技术，新应用，都是可以的。
但是一定要知道角色的转换，每天早上打完卡，你首要考虑的就是“我今天要做PRD中的那个功能？
还有多长时间项目结束？
”，而不是去用连自己都不确定的思路去做项目。
因此，对于这种类型的技术人员，应该用“借刀杀人”的方式来让他按照时间安排来做。
例如可以这样说：
PM：
这是用户提出的要修改的一个地方，你看能做吗？
Looking……
程序员：
我觉的这个地方有些问题呀？
PM：
哪里有问题？
程序员：
你看，这个地方我觉的这样做不合适，应该……
开始讲解他认为最好的方法。
PM：
那如果按照你认为的方法做的话，需要多长时间呢？
程序员：
我也说不好，这种方法我没用过，不过我可以试一下，这样吧，等做完了，我通知你吧！
PM：
这个问题是用户非常急迫要求修改的，我必须知道一个确切的时间，否则无法向用户说明。
程序员沉思中
程序员：
好吧，其实有种方法也可以实现，今天下班前我尽力做完，做完了，我通知你。
……
对于一个公司来说，天大地大，用户最大，在公司内的任何一个人，都不敢不把用户的要求放在次要位置的，一旦遇到这种情况，你用用户来胁迫，十有九个会就范的。
3、好为人师型：
先看一个案例：
PM：
这是用户提出的要修改的一个地方，你看能做吗？
Looking……
程序员：
这个问题是什么用户提的呀？
PM：
是咱们的一个XXXX用户提得。
程序员：
靠，我看这用户什么也不懂，这也能叫做问题！
PM迷茫中。
程序员：
你看，用户之所以出现这个问题，是因为……
大概讲了几十分钟后，看着PM，带着满足的眼光问道：
你知道了吧，这都是用户太笨，不懂计算机，你去和他们说一下，这种问题就不用改了。
如果还有不清楚的，可以来问我，以后不要什么问题都改，我那有那么多时间。
PM彻底晕倒。
这类技术人员最大的特点就是认为“从我手里出来的产品就是最好的，不会用那是因为你笨，而不是我笨”。
因此，这类技术人员在遇到这种情况的时候，通常立刻转化角色，把自己当成一个诲人不倦的老师，一步一步地告诉你应该怎样去做，然后让你去告诉用户应该如何去做。
说实话，这类技术人员不去做客服真的是浪费了，这种耐心简直让人佩服万分，可惜的是，有剖析用户问题，嘲笑用户使用技能，教授如何使用的时间，我想也应该把要修改的问题做完了吧。
因此，对于这类技术人员，要采用“欲擒故纵”的方式来让他认清自己应该做什么。
可以这样去说：
PM：
这是用户提出的要修改的一个地方，你看能做吗？
Looking……
程序员：
这个问题是什么用户提的呀？
PM：
是咱们的一个XXXX用户提得。
程序员：
靠，我看这用户什么也不懂，这也能叫做问题！
PM不做回答，故做迷茫，听他解释。
PM：
你看，用户之所以出现这个问题，是因为……
大概讲了几十分钟后，看着PM，带着满足的眼光问道：
你知道了吧，这都是用户太笨，不懂计算机，你去和他们说一下，这种问题就不用改了。
如果还有不清楚的，可以来问我，以后不要什么问题都改，我那有那么多时间。
PM：
是呀，是呀，我也知道这些都是小问题，好多都是用户使用不当造成的，这样吧，我就按照你的建议去和用户说清楚，希望能有帮助吧，不过这个单子市场已经下了，我就按照你的建议去和他们说，要是再有用户问，我就让市场的人直接找你了，行吗？
程序员思考中……
程序员：
你先把单子留下吧，我再看看，和我们经理商量一下，一会通知你。
……
在这个以营销为主，客户为上帝的环境中，谁都知道，把你直接推到用户面前，都是对自身的一种考验，之所以他们能给你滔滔不绝的讲一堆东西，讽刺用户的使用技能不足，那是因为他们不用直接面对用户，因此才敢口无遮拦，并且他们也知道，你是PM，你就是他们和用户之间的防火墙，有什么话他们敢说，你PM就不敢说，因此，一旦遇到这种情况，最好的方法就是看似尊重他们的意见，实则把自己这道防火墙关掉，直接让他们和用户面对面，我相信，这个时候，他们就得考虑一下，能否真能应付这些在背后不知被嘲笑了多少次的用户了。
4、自以为是型：
先看案例：
PM：
这是用户提出的要修改的一个地方，你看能做吗？
Looking……
程序员：
这个问题是什么用户提的呀？
PM：
是咱们的一个XXXX用户提得。
程序员：
这都什么问题呀，一看就不是咱们的最终用户，不要管他！
PM迷茫中。
PM：
那这个问题也的修改呀，要不如何向用户说明呢？
程序员：
我知道，我会改的，不能什么都按照用户的要求来做！
PM：
那你打算怎么改呢？
程序员：
这个你不用管！
PM：
那什么时候能改完呢？
程序员：
改完了，我会通知你的。
PM极度郁闷中。
……
这类技术人员是极度的自以为是，在他们的眼里，产品只是由技术构成的，技术和产品之间是划等号的。
任何不懂技术的人，从本质上来说，就是不懂产品，因此，你们提出的所有关于产品的问题，都是外行提出的，都是不专业的，也都是不需要你们去了解的，你们要做的，就是告诉我问题，至于怎么改，什么时候改完，这些，我都不需要告诉你们，因为说了也是白说。
这里的“你们”，自然包括产品经理。
遇到这种类型的技术人员，产品经理就不好对付了，通常这类人多少是真有两把刷子的，并且经历的也多，公司也有一定的名气，有一些还是担任一定职务的，因此，像前面使用的三种方法在这里就都不太好用了，但是这种情况肯定会遇到的，那怎么办呢？
我个人的方法是：
金蝉脱壳
可以这样说：
PM：
这是用户提出的要修改的一个地方，你看能做吗？
Looking……
程序员：
这个问题是什么用户提的呀？
PM：
是咱们的一个XXXX用户提得。
程序员：
这都什么问题呀，一看就不是咱们的最终用户，不要管他！
PM：
那这个问题也的修改呀，要不如何向用户说明呢？
程序员：
我知道，我会改的，不能什么都按照用户的要求来做！
PM：
那你打算怎么改呢？
程序员：
这个你不用管！
PM：
那什么时候能改完呢？
程序员：
改完了，我会通知你的。
PM：
好的，不过我认为我还是需要知道这些情况的，毕竟也得和上面交待，是吧？
我要是说不清楚，上面就不是怪罪我一个人了，对不对，你还是给我一个明确的答复吧，否则，那我就只好实话实说了。
并且会和你们的经理进行说明的，让他来协调吧！
程序员：
随便！
然后去找他们的经理进行说明。
……
其实遇到这种情况，就我目前个人的能力来说，只能依靠上一级的力量来协调此事了，因为，这种类型的技术人员，第一，知道公司起重他，有恃无恐，第二，经历的可能比你还多，根本不在乎你的各种手段，第三，尤其是在一些技术起家的公司，技术部门普遍具有优越感，CEO是老大，我们就是老二。
因此，作为产品经理，完全没有必要去硬碰硬，可以把矛盾的主要方面转移成部门冲突，让上级领导去协调此事即可，不过，这个时候需要注意一点的是：
一定要把握住冲突的主题，是因公而生的冲突，而不是个人冲突的升级。
如果说前三种情况中，遇到的技术人员还是容易沟通的，那么，第四种就很难沟通了，因为，在他们心目中，什么产品经理，不就是一个写文档的吗，懂什么技术呀，这种心中的地位落差就已经决定了你不可能和他们平等的对话。
最后做个小结：
第一种：
蒙头干活型，采用“抛砖引玉”的方法；
第二种：
技术痴狂型，采用“借刀杀人”的方法；
第三种：
好为人师型，采用“欲擒故纵”的方法；
第四种：
自以为是型，采用“金蝉脱壳”的方法。
其实在产品经理与技术人员打交道的经历中，远不止这四种类型，不过因为我个人经验有限，只能总结这么多出来，也不知道大家是否有同感，当然，大家可以都做一些总结，提供一些方法，这样，咱们多多交流，肯定能把工作做的更好。
如何与不同类型的市场人员进行沟通
Postedby汤圆on2008-8-116:
19:
53 View1670 Comments34
我写了一篇《叫我如何对你说—技术团队》，大家的反响不错，给了我很大的鼓励，在产品经理的工作中，除了和技术团队打交道最多外，就是市场团队了，这里的市场团队定义可能不够准确，从我个人的经验来看，主要是两个团队，一个BD，一个就是销售。
在本文中，我就总结了一些我在和这两个团队合作的时候，遇到的一些问题以及我个人的处理方法，希望对大家有些帮助。
大家都知道，产品经理有一个重要的工作就是为市场和技术搭桥，因此，从这个角度来说，产品经理在市场部门眼中，就如同技术部门在我们眼中一样是对产品和技术熟知的人，因此，他们通常会用一些我们对待技术部门的态度和方法来要求我们，唯一的区别就是我们能够从整体上来评估产品和技术，而市场团队则很少能够做到这一点。
1、客户压制型
有些销售人员经常会把客户挂在嘴上，动不动就拿客户来压制产品经理，毕竟公司的客户一般是不敢得罪的，于是经常会出现以下的情景：
销售人员：
XXX（产品经理是也），这个产品应该这样做才行，我的一个客户就是这么要求的。
XXX：
这个需求我知道，但是我得整体考虑，因为这个需求要去实现确实挺需要时间的，我得看看这个需求的量有多少。
销售人员：
这个我不管，但是这个客户可是咱们的老客户了，你不怕得罪，我可怕，你好好考虑一下。
XXX：
！
@#￥￥%……。
因为通常来说，每个销售人员手里都会维持着某几个公司的客户，在他们眼里，这些客户就是他们的衣食父母，根本得罪不起，于是，为了维持他们个人的收益，他们会把客户提出的各种需求强加给产品经理，让产品经理必须要去做，这就让产品经理很是为难。
去做吧，这个需求可能只是一个客户提出来的，不具有代笔性，不去做吧，销售那边不断的给你施加压力，那么，应该如何处理呢？
我个人的做法是“将计就计”，我通常会这样来回答他。
销售人员：
XXX（产品经理是也），这个产品应该这样做才行，我的一个客户就是这么要求的。
XXX：
这个需求我知道，但是我得整体考虑，因为这个需求要去实现确实挺需要时间的，我得看看这个需求的量有多少。
销售人员：
这个我不管，但是这个客户可是咱们的老客户了，你不怕得罪，我可怕，你好好考虑一下。
XXX：
这个没问题，你看，我这里有好多需求了（拿出需求矩阵表给他看），都是咱们的客户提的，还都是大客户，每个需求我都不能忽视，这样吧，你这个需求我记录下来了，具体做那一个，一是我要进行评估，二是必须符合咱们产品的计划，不过你可以放心，你提的这个需求我会优先考虑的。
面对这种情况，如果你直接说“做”或者“不做”都是不行的，最合适的方法就是也站在销售人员的对待客户的角度上去说，说的时候需要注意几点：
1）客户的需求我们一定会关注，这是前提，如果你只从产品经理的角度来说，就容易形成对立。
2）客户需求的满足不能脱离公司的计划，这是条件，销售人员是不敢否认说公司的产品计划有问题的，至少当面不敢。
3）客户需求的满足我尽量去考虑，但是要有优先，这是结果，不直接去说结果是什么，这里要注意，产品经理千万不要向销售承诺什么，销售就是记性好，呵呵，尽量给他一个看起来是倾向于他的结果就可以了。
2、不切实际型
这类情况主要存在于BD部门多一些，因为BD主要是和外界公司进行合作，通常会根据合作情况来要求产品部门设计对应的产品，在这种情况下，因为他们要受到来自于公司合作业绩的压力，因此，他们最主要的想法就是尽快把合作搞定，再加上他们对产品和技术通常不了解，因此，他们会要求产品经理在他们期望的时间内完成合作产品的开发，而这种时间通常是不切实际的。
BD：
XXX（产品经理是也），咱们和XXX公司进行了合作，咱们得提供一个XXX平台给对方，对方才能做，你看，这是对方提出的需求，5天内能做完吗？
lookingXXX：
这个产品做起来很麻烦的，5天肯定做不完了，要不你去和对方说一下，我估计至少得10天。
BD：
这怎么可以呢，我都答应对方了，要是做不完，可耽误事情了，谁来负责呢？
XXX：
！
@#￥%……
从对话中感觉到似乎BD的工作热情有多么强烈，我们作为产品经理，面对合作一定是要全力支持的，是的，这点没错，但是全力支持并不代表着不切实际，毕竟公司的产品是在按计划在走，插入一个合作产品，一要上报高层，二要调整产品计划，虽然或许就是一个几天的工作，但绝对不能说做就做，如果是这样的话，你就会被BD牵着鼻子走了。
面对这种情况，我个人的方法是“反客为主”，我会这样来沟通。
BD：
XXX（产品经理是也），咱们和XXX公司进行了合作，咱们得提供一个XXX平台给对方，对方才能做，你看，这是对方提出的需求，5天内能做完吗？
lookingXXX：
这个产品做起来很麻烦的，5天肯定做不完了，要不你去和对方说一下，我估计至少得10天。
BD：
这怎么可以呢，我都答应对方了，要是做不完，可耽误事情了，谁来负责呢？
XXX：
5天的时间是肯定不行的，我想你可能只看到了产品的实现周期，但是，我这里需要上报领导，需要调整计划，需要和技术部门沟通确定人员，这些都是要花时间的，10天的时间应该差不多，要不这样吧，你把他们负责任的联系方式告诉我，我来和他们沟通，说明一下情况，毕竟双方都是为了合作成功，谁也不愿意拿一个有风险的产品出来，对吧？
这样说有几个出发点需要注意：
1）产品部是非常支持合作的，也会尽力协助。
2）把产品开发的流程和规范说清楚，我们不能违反公司制度。
3）委婉地说明如果只有5天时间的话，可能出来的产品会风险非常大，不利于BD人员进一步合作。
4）如果BD认为自身无法说明情况，产品经理应该主动去进行合作沟通。
这就是反客为主，要把合作沟通的主动权拿过来，因为据我观察，通常合作进入到产品沟通的时候，对方也通常会是产品经理在负责（当然了，前提是对方公司有产品负责人员），两个产品经理进行沟通，总是能谈到一块的，也容易达成一致。
毕竟BD的根本目的是促成合作，而不是拿一个有风险的合作产品出去，孰轻孰重，你只要告诉他，他会明白的，也会理解的，还有一种情况是BD本身对产品和技术不懂，如果坚持让他进行产品细节的沟通，他会有畏惧感，因此，如果出现这种情况，产品经理一定要主动站出来，拿到接力棒。
3、产品无知型
以上的两种情况都谈到了通常BD和销售对产品或者技术都不是很懂，尤其是在销售团队中更为明显，这种对产品的不熟悉就容易造成他们只看到产品表层的东西，认为产品其实就是那么简单，通常会出现以下情况。
销售：
XXX（产品经理是也），这个产品的XXX功能我觉的不能这样做，应该那样做！
XXX：
我和你说一下，之所以不那样做，是因为XXX、XXX实现起来比较困难，挺花时间的。
销售：
有那么困难吗，我看很简单呀，不就是加个按钮和文本框吗？
XXX：
！
@#￥%……
当他们只看到表象的时候，他们会认为任何产品都是简单的，我们经常听到他们会说“不就是加一个文本框吗？
”、“不就是改一下文字位置吗？
”、“不就是修改一下背景吗？
”，在他们看来，这产品好像就是用纸往出画了，想怎么花就怎么花，根本想不到前台的一次改动几乎都要涉及到后台的修改，他们认为一分钟就能搞定一个修改，几天就能做出一个功能，一个月就能做成一个产品。
面对这种情况，我通常的方法是“抛砖引玉”，我会这样说。
销售：
XXX（产品经理是也），这个产品的XXX功能我觉的不能这样做，应该那样做！
XXX：
我和你说一下，之所以不那样做，是因为XXX、XXX实现起来比较困难，挺花时间的。
销售：
有那么困难吗，我看很简单呀，不就是加个按钮和文本框吗？
XXX：
是呀，在前台看起来就是加一个文本框和按钮，但是需要技术需要在后台做很多改动的，要不这样，我把这个模块的负责人叫过来，咱们一块讨论一下，你就知道是怎么回事了。
销售：
！
@#￥%……
记住，遇到这种情况，产品经理千万不要也犯技术团队中的问题，就是“谆谆教导”，产品经理在这个时候没有教育人的义务，面对这种无知的疑问，大可不必多说，只需要简单说明一下原因即可，如果对方还是不依不饶，那你把直接的技术人员叫过来和他解释，我相信，十有八个技术人员是没功夫搭理他的，产品经理直接和销售人员接口，技术人员可没这工作职责。
这个时候事情就简单了，不是我不给你解释，是产品经理我也不是技术专家，但是技术人员又不想和你说，我也没办法，I’AMSORRY！
你只需要把这块“砖”抛出去就行了，至于是否会有什么样的“玉”回来，就和你无关了。
4、极度自信型
极度自信就是自负，这种情况尤其存在于有一些技术背景或者懂一些行业技术和产品知识的销售或者BD身上，就是因为他们懂一些这方面的知识，并且又认为自己是市场端的，认为自己是全能型的，因此，总喜欢在你面前指手画脚，你去和他说需
升级会员 