产品经理如何优雅地撕逼.docx
《产品经理如何优雅地撕逼.docx》由会员分享，可在线阅读，更多相关《产品经理如何优雅地撕逼.docx（5页珍藏版）》请在冰豆网上搜索。
产品经理如何优雅地撕逼
产品经理如何优雅地撕逼？
产品经理如何优雅地撕逼？
江宽北京慧享科技有限公司产品总监6小时前一、撕的目的首先说说产品经理也撕逼的目的。
先谈为什么撕？
再说撕什么？
怎么撕？
带着目的去，才可能撕出水平，撕出精彩，这是这部分希望达成的一个目标。
为什么撕呢？
通过有理、有利、有节的沟通，排除由于意见不一致导致的执行障碍或拖延，促使目标能够顺利达成。
有理：
有道理，有条理，主要解决的是对方听不懂的问题。
有利：
有好处，寻找共同利益解决对方没有动力的问题。
有节：
有节制，适可而止。
主要是为了避免说的太多、大家闹情绪、对着干，毕竟我们并不是说真的要把某个人排除在外，而是希望最后我们的目标达成。
二、撕的内容这是产品经理平时就需要准备好的东西，只不过我这次特意把它提出来。
我对大家的建议是：
采用系统的方法去构建我们需要准备好的东西，这样才能达成我们有理有据的效果，我个人是以《用户体验的要素》这本书中描述的几个层次去做的准备。
这本书本身概念结构非常清楚，我建议没有看过的同学去看一下。
1.拒绝大杂烩式的任务从脑图中，我们可以看到首要的一条就是理清思路，而我给大家的第一要务就是拒绝大杂烩式的任务。
那么大家回忆下，自己有没有经历过类似的任务，就是有一堆需求，却从来推进不下去。
1）大杂烩式任务的特点通常大杂烩式的任务有这么几个特点大家干起来没劲，因为没有统一的目标，最后做完了也不会有什么成就感。
经常会被各种挑战，因为小的项目特别多，可被攻击的点也特别多，所以就经常容易被挑战。
容易没有结果，因为根本就站不住脚，没有站得住脚的地方，所以特别容易被其他项目强行插入然2）应对这种任务的方式这种项目最好不要接。
如果一定要接的话看，那么设法扣上合适的帽子。
3）大杂烩式任务举例说明比如对于用户体验优化这种事情，汇总起来可能有几十个需求，而修改BUG可能有几十个小BUG包含在内，对于这种问题其实一次性解决会比较干净，可是看上去缺少目标也没有重点，那么我们就需要给他扣上一个大帽子：
具体做法就是：
我把所有想象都列出来再打包到一起，而我们的主要任务就变成说我们去修复这些问题，之后体现我们的反馈率因此降低了多少，这样其实就是做了一个“化零为整”的事情，本质就一件事情被扣上一个大帽子。
4）大杂烩式任务的处理时机可能有的同学认为我的观点不正确，认为公司有很多琐事、没有人管，可是自己觉得特别重要，内心面对任务问题就会很纠结。
我想提醒的是：
这可能是由于你所在的位置、所接触的信息还有视野不够，进而造成自己对事情优先级的排列不当。
通常这种事情可能在别人的眼里，按四象限法则来分的话，属于不紧急不重要的事情，但是可能你站在自己的角度会认为这是众人皆醉你独醒的一种状态。
而我想说的是，即使这种情况下你是对了。
你可以等到问题更凸显的时候再解决，这样的情况下大家可以更容易取得一致，你推进也会更容易。
我不建议这种事情大家像祥林嫂一样，一直都是絮絮叨叨的不停地叨念但是从来没有人解决。
总之，我希望大家能够拒绝大杂烩一样的任务。
2.明确目标，理清逻辑下面来说一些相对完整的项目。
这些项目首要目的就是要把目标和逻辑理顺，我用到的工具就是用户体验的要素里面提到的五个层面：
战略层、范围层、结构层、架构层和表现层，战略层里有项目目标和用户需求；范围层里面有功能规格和内容需要；表现层则是最后一个层次，主要是视觉设计的事情，产品经理通常情况下可以不做重点关注。
前面四个层面（战略层、范围层、结构层、架构层）是主要搞清楚问题。
1）提前准备的重要性项目目标、用户需求、功能规格、内容需要、交互设计、信息架构之类的一系列的内容通常而言都会在PRD里去体现，但是PRD通常比较正式，我带的大部分项目里边PRD其实都是到了测试阶段才正式开始写，但是上面四个层面的信息需要在立项的时候就完全准备好，否则可能面临的是无尽的撕逼。
2）具体的操作方式对上述内容，我会在产品上有不同的要求，战略层面的项目目标和用户需求需要能口述出来，同时可能有些真实的目标也是不太适合写到PRD里，这部分口述出来就好，范围层主要是做什么工能、达到什么标准，我希望大家能够用脑图直接呈现出来，清晰有主次把他呈现出来就好了，结构层和架构层主要是需要出交互稿，AXURE、墨刀或其他的STAGE之类的出的交互稿，其实都是OK的。
这是我目前对自己团队的要求，大家也可以参考一下。
3）层与层之间的联系用户体验要素里面的这几个层面的内容其实非常有意思，从上面一层，其实是可以推导出下一层要做什么的，他的逻辑是完备的。
同时，从下面一层也可以完善分析，然后可以分析出下面一层是如何支撑上面一层的，这里边的逻辑其实是完备的。
经常有些pm其实在做需求的喜欢夹带一些小的改进、小的改动啊！
可能为了大多数人能够多做一点事情，但这种事情极有可能会让整个项目的目标变得模糊，撕起来的时候站不住脚的地方也特别多，所以在明确项目目标的同时我希望是减少这一类的夹带需求。
换句话说就是从立项之初，和项目目标不相关的BUG、优化呀，从产品最初就不要提，中间也不要试图去加，这种大杂烩的东西刚才已经说过处理方式了，可能最终不处理也行，开始的时候就要杜绝这种情况发生。
如果已经出现了，其实避免的办法也比较简单就是。
在正式沟通需求，正式说我们要对外开撕之前，我们内部从上到下，再从下到上各捋一次，然后每一个层面上面全都做减法，确保每一个层面上，他的逻辑都是通畅的。
确保每一步都是可推导出来的，并且从下到上也是可支撑的。
这样至少在道理上我们就可以立于不败之地。
在我们正式开会或者是正式讨论需求的时候能够少花时间在各种细节需求上面。
4）战略层面的具体应对方式明确项目目标和用户需求我想强调的是战略层面项目目标和用户需求一定要非常的明确，我最近在这方面其实也遇到了不少的坑和困难。
不少从产品的同学其实看了很多业内大佬的一些观点：
以用户为中心，所以凡事都想靠上用户的需求，这种思想实际上做事的时候会非常的别扭。
往用户身上靠，其实是一个正确的事情，但是实际工作中有很多项目其实是满足老板YY的需求、满足甲方合同、照顾合作伙伴面子的等等。
其实并不是以用户为中心去做的，如果说这个里边需求出现了偏差，最后执行层面上就会遇到非常度多的困难。
战略层面上一定要想的明白后面的做事才能够确定范围做成什么样子，才能够承接上。
否则我们就会面临无休止的讨论和反复。
然后面对领导以及面对研发或者测试的各种质疑和不满。
这里再补充一句，我刚才说的可能有些目标无法写进PRD的，可能是不能文档化的，但是这种目标一定要自己清晰，同时让团队成员清晰。
具体案例分析我这边有一个例子，我们慧享科技其实有一个项目是为中国移动服务的，有一款教育类的产品叫“和宝贝”。
之前有一段时间移动的领导提出我们需要一个家园联系册的功能，这是个什么功能呢？
简单说就是家长想了解孩子在幼儿园里面发生了什么事儿：
孩子吃喝拉撒睡、学习各种情况如何。
怎么去沟通这个事儿呢？
幼儿园里面有个小本，专门记录这种东西。
这种东西可以电子化吗？
当然可以电子化。
移动的领导看到了这样一个东西，他希望也能够把这个事情电子化一下。
我们一个同学，接到这样一个需求，折腾了俩月，各种调研、各种讨论、同时没有产出，被团队、老板、还有移动各种质疑，最后没有成型的产品出现。
这里面能不能花一个月时间，抄一个移动领导曾经见过家园联系册，然后再花一个月时间去调整优化、满足用户的需求呢。
这只是一个问题，其实我更想问的是，这个项目的目标究竟有哪些可能性。
我怎么才能搞定这些可能性，摸清真正的需求是什么？
然后我再来决定后续的工作如何，这个问题请大家可以思考一下，在分享结束之后，因为后面还有类似的内容是可以解决这方面的问题的。
5）效果层面的具体应对方式效果层的解释请大家返回脑图，最后我还补了企业产品里的一项，是我们还是要考虑到一个效果层，这个是在用户体验的要素里面没有被描述的，这层原则上来说是和营销沟通的，最后形成企业产品卖点的。
比如我们之前做了一个企业级的项目，我最后把它总结出来的是：
“8张报表搞定企业经营管理”这么一个说法。
那么从效果层面来说的话，我就需要有8张报表，同时我要让人感受到我能帮他搞定企业管理，同时这里面有道理有逻辑，当然我都可以和营销的同学说清楚。
但是这个效果层其实是在整个用户体验要素里面是不太相关。
企业产品和用户产品的差异为什么不相关呢？
其实是企业级的产品，和用户产品有一个巨大的差异。
在于说，企业产品的客户和使用者是分离的，而用户产品的用户和客户也就使用者和掏钱的人，是统一的。
企业产品不是这样的，是老板掏钱员工去用的。
员工可能用的很不爽，但是老板爽了。
企业产品也就卖出去了。
注意事项具体怎么做企业产品就不展开了。
但是做企业产品的同学需要注意的是，沟通层面上需要把效果这个层次展现给营销、展现给市场、展现给老板，否则这类产品极有可能是推不出去的，同时营销和产品之间会产生非常巨大的矛盾或者至彼此质疑。
以上内容就是撕的内容，是我们撕之前需要准备好的哪些信息，我们自己心里要心知肚明。
三、撕的方法
上一部分四个弹药（战略层、范围层、结构层、架构层）大家应该知道需要准备哪些内容了，这一部分要说的则是怎么准备弹药，如何把这样一个弹药打出去？
这里主要有四件事情我认为是一定要做到的，第一件事情是问，第二件事情是听，第三件事情是说，第四件事情是不说。
以下我们逐一展开。
1.问问是非常重要的事情，因为很多老板在沟通的时候会省略过程而直接说结果，比如他想说他想要一个聊天功能，但是为什么要做？
费多少精力做？
做到什么要求？
什么时间完成？
通常而言，产品经理是不知道的。
你若是不问，他可能也不会说，而等你作出不好的结果后，就只能被老板指责，同时被研发团队或者其他人埋怨。
1）举例说明我刚刚接手的一个项目，就是这种情况。
负责的pm一问三不知，为什么要做？
做成什么样？
全都不知道。
战略层、范围层的东西一概不知，研发干起活来也是非常郁闷和没有目标，不知道该做啥，也没有干劲。
老板对项目长期来看的话，就是进展缓慢，也不知道自己有没有说明白，反正就是很郁闷，骂又骂不出来。
2）解决方式这是一个挺糟糕的例子，我也知道，对于问领导，尤其是问大BOSS，很多PM心里面有障碍，就是害怕被领导认为自己是傻逼，认为自己如何如何，出于挽救团队的目的，我就把这个PM开除了，这是一种杀鸡儆猴的做法，目的是让其他PM吸取教训。
总结下来，就是遇到不知道的事情，产品经理一定要厚着脸皮，横下心去问，不问就没有办法做好。
3）问的内容那么具体需要问老板或者知情人什么事情呢？
1.做这件事情的目标是多少2.我们应该花的成本是多少，费多少精力去做3我希望做到什么样的要,4什么时间需要完成，总而言之一定要问出一个SMART原则出来。
如果有人不清楚。
问不出来的话你也可以先设定出来让别人去确认，但这个事情一定要敲定好。
否则后面战略层面的事情定不下来。
范围层面还有执行层面的事情其实根本就是无法推进的。
4）问的技巧关于问，其实还有一种技巧就是----套词。
就是我先试探一下，问一下别人是什么样的想法，你以中立的态度去问，以便说我在正式讨论之前了解谁可能和我的观点一致，谁可能获得观点不一致。
为什么不一致？
这样我可以针对性的做准备。
说白了就是“确认盟友”的过程，目的就是避免出现死机的情况，就像出现六大派围攻光明顶的长场景，而你又不是张无忌。
甚至有可能你的顶头上司都无法站在你这边为你说话，这种情况其实会非常惨。
2.听第二件事情是听，听到的东西可以是主动问出来的，也可以随便聊出来的。
随便想聊出更多的信息，就需要平时关系处的融洽。
要多一起吃饭，平时要多开玩笑都扯淡，都在一起玩儿，如果只是说发发需求文档，跟人在微信或者QQ里边聊两句言，这种其实是完全不够的。
比较好的做法是平时就能玩儿到一块儿去。
能开玩笑，能主动的想办法和人一起去做一些事情。
这样大家在生活当中接触多了，在工作当中也容易聊出真实的想法，真实的态度。
1）听的内容那么听的内容是什么，听到的内容其实也是可以分开层次来看的。
1.有的内容可能是单纯的提供信息的，这话你可以收集。
2.有的人是希望积极的提出建议想让这个事情变好的。
3.当然，听到内容也可能是消极的，他不想做他想找托词的。
这三种内容其实我们在日常工作中需要区分的。
比如找托词可能是因为怀疑项目本身，觉得说自己的投入产出比特别低，也懒得付出。
当然也可能是说这项目根本就不是我的目标，也不是我的工作重点。
我省的麻烦，我也不想惹的一身骚，所以推脱掉是可能比较稳妥的选择。
要解决这类问题其实是需要寻找共同利益的。
2）举例子比如说协调UI资源，其实应该和UI的沟通是比较困难的。
这方面我有个办法可以和大家分享一下，就是寻找共同利益。
通常UI都不愿意被称为美工，这是一个他们很头疼的问题，他们希望成为一个优秀的设计师，这是他们的愿望。
但是从我的角度来说，我看UI的工作分成三部分，1.第一部分是沟通，从需求方面或许需求。
2.第二部分是设计，3.第三部分是把自己设计出来的东西推广出去，让需求方接受，只有这三部分内容，那么你看，在这三部分内容里面，两部分都是沟通，只有三分之一是设计，我们与UI沟通的时候，需要明确的是：
不仅是PM，优秀设计师也要有出色的沟通的能力，明确需求方的要求，从中获取有用的信息，这样才能拥有设计主动权，而不被人指手画脚去工作。
总结下来，UI和产品一样都需要沟通。
3）特殊情况处理方式当然遇到有些人特别难沟通并且搞不定，我的建议是：
采用下策。
让找托词不配合的人，如果不配合，他自己会不舒服，比他配合要更不舒服。
这样就能从痛点上去驱动他去工作，包括说我其实并不排斥产品经理去吹吹风或打打小报告，让整个事情推进的更快一些其实。
这种达成目标的方式虽然让人不适，但是下策也是能解决问题的。
3.说1）说的层次1.表达别人的想法，2.表达自己的想法。
2）表达别人的想法的目的1.沟通后，及时的反馈，知道你听懂了2.和别人确认你的想法是否正确3.起到终止对话的目的，有些人沟通能力差，会啰嗦，节省时间。
3）表达自己的想法具体的内容，其实在撕的内容里面已经说过了，但是需要注意的是受众不同，侧重点其实也不太一样。
对市场营销、合作伙伴、客户、或者说销售出身的老板通常而言，对市场营销、合作伙伴、客户、或者说销售出身的老板来说，沟通战略层面和效果层面是最重要的，他们关心的是项目的目标是什么，用户的需求是什么？
最后通过什么样的具体的方式能够解决用户的需求。
把钱给挣了这是他们关注的重点。
对于研发测试对于研发测试这类产品体系内部的小伙伴来说。
我认为战略层的范围层的结构层的架构层的。
都需要沟通而且中间的逻辑要跟人讲明白，以促使整个项目被充分的理解。
当然这东西有你说了很多人可能是不关心的，但是但凡有那么一个人关心。
你在做项目的时候就会得到更多的知识，你出现纰漏的时候就会有更多人帮你去补救。
而你如果不说，这一切都不可能发生。
具体这人的比例是多少其实取决于团队建设的成熟度究竟如何，可能有的团队一直就是一盘散沙。
我们甚至都不能称之为团队，他们就是来拿工资的几个人。
无论如何仍然不要放弃通过自己逻辑的力量去影响和你一起奋斗的小伙伴，让他们能够感受到你的思考，你的道理，从而能够从行动上，从思想上和你的项目保持一致。
当然不同的团队或者不同的公司，他们内部的风格方式是不同的。
总的来说，越靠项目内部的人，需要了解越多的中间逻辑、中间的过程，以使他们每步行动有理有据，越靠外部的人，只需要了解头尾，也即战略层和最后的效果。
4）沟通的技巧同时产品的沟通的时候，除了方案本身，在表达自己的想法的时候，其实还不可避免的，也必须要传递些虚的东西出去，这里我可以举个例子。
最近有一个产品我说他和研发测试在沟通的时候经常被挑刺儿，执行的过程中也时不时被捅刀子，然后被告状，感觉自己没有得罪别人，然后非常苦恼。
而我看到的情况是，他在和别人沟通方案的时候经常抱着说大不了，无所谓，随便的态度。
那么你想想跟你合作的这些人，会不会也认为是大不了，随便，无所谓呢？
其实他们不会，他们只会觉得说和你这和你这么去干活儿，很有可能我干不出成绩，那我就只好推委，只好推脱了。
我们在沟通方案的同时，除了方案本身，其实还会传递的是自己的态度，对项目的信心。
以及这项目的压力等等很多额外的信息，这其实全都会影响你的受众。
你吊儿郎当，别人觉得和你做事没什么希望，自然容易找茶，自然容易找理由推诿，说白了就是你挡人财路了，为什么这么说呢？
你的活干不好，他的成绩和劳动都白费了，他当然觉得不爽了，当然不愿意跟你去干活了。
作为PM有一个底线的要求就是，别影响团队里面的其他人升官发财，做好这一点你就有把整件事情做好的一个动力了！
4.不说1）不说的前提最后一个是不说，这里说的不说不是绝对不能说，而是撕逼的时候不要说。
2）不说的内容埋怨的话题其实在最开始就说过了撕逼的时候要有节制，什么叫有节制？
就是大家最后还是要在一个战壕里工作的？
所以埋怨的话题，在撕逼的手容易收不住，说多了也就无法站在同一个战壕里面了。
因此这点要克制。
目标无关的话题第二个是和项目关的话题。
遇到这种问题时及时打住，避免浪费时间，尤其是大家一起开会的时候，这种浪费时间其实特别严重。
有个相对好的消息其实是据我了解大家对这种产品其实都是非常深恶痛绝的。
你说行。
可能因此打断了别人说一个无关的话题看上去可能让人不太爽不太礼貌，但是我可以告诉你的是。
开会的人里边应该有不少都是暗爽的，他们可能不会当面表示出来他们会暗爽，做他暗爽的事情挺好的。
你没有想过的话题。
第三个是没有想过的话题。
产品通常而言考虑的是，整个事情的主线，而从研发和测试的角度，最重要实现和验证，他们会面对非常多细节的问题，产品经理在面对这种问题的时候，会感觉自己的权威受到挑战，很常见的心态，这种情况容易发生撕逼，被人质疑，对待这种问题，记录就好，说得越多，自己被攻击的点就越多，也越收不住。
言多必失。
上面这个图是本次分享的一个脑图，也希望大家未来在产品沟通的过程当中能够用相对系统和结构化的方式和别人去沟通，这样能让自己的逻辑更清晰。
总结：
产品经理如何有理有利有节的撕逼，首先需要大家做到的是斯的内容要准备好;其次，撕的方法要得当；最后，撕个目标要明确。
江宽：
慧享科技产品总监。
本文由PMCAFF会员@江宽原创发布于PMCAFF产品社区（），未经许可，XX出于对PMCAFF用户的尊重，任何在PMCAFF产品经理社区发布的内容，在未经允许的情况下，不得在任何平台被直接或间接发布使用或被用于其他任何商业目的。
如有违反上述声明者本网站将追究其相关法律责任。
微信公众号：
pmcaffcom投稿邮箱：
tougao@GreatedbyPMCAFF产品经理社区-本文为头条号作者发布，不代表今日头条立场。
升级会员 