作为PM,其实我们的沟通能力可能不及格

在很多项目环境中,产品经理,其价值充分发挥之程度,几乎全部仰仗有成效的沟通。但大部分产品经理简历上的所谓“沟通能力强”,都算是一种常见但无效的自以为是。评价沟通能力,诸如语速快、声音高、反应快、表情多、会用形容词副词等等一些表面功夫,相对而言。而沟通背后所需的信息传递节奏控制、对方意图的揣摩、环境气场的感受等等,却容易被前面这些沟通技巧所掩盖。

自以为的有效沟通,很多时候,并不有效

被老板分别过问时,A说与B说的完全不一致,甚至背道而驰。但A和B开过会、有会议纪要、A和B都自以为达成一致,信誓旦旦。WTF?其实,团队越大、跨组越多、KPI越不同,这种情况就会越来越多。而且很多时候,当事人并不知情,只有事后扯皮。

不经思考或训练的人,如无天分,一般都在说自己能听懂的话。每个人都是如此,这很正常。“见人说人话、见鬼说鬼话”,据我的体验,多数PM都做不到。解决这个问题?第一步,就是先拉低自己对自己沟通能力的自信确认一下,对方听懂了吗。让对方复述或解读,或者让自己换个方式阐述一遍看对方反应,都可以验证这个问题。

验证一下,你会发现,你之前白说的话比你想象的多得多。“幸好确认一遍,免得需求变更。。。。”

重新认识沟通,当做一门综合学问,而不只是传递信息这么简单。信息本身既然没有边界,难以界定,那么靠说话就要把两个人的信息搞对称,显然是个技术活儿。假如认识到沟通的重要性,不妨拉低自己对自己沟通的评分,从“急事当面说、要事走邮件”的基本技巧,到“对照锚定、同化锚定”等经典心理学逻辑,研究一下这门学问。

每个人身边,都有那些沟通起来简单不费劲,甚至说到心坎里、不谋而合的人,相信我们都爱这些人,乐意与其为伍,甚至终生为伴。在一个团队中,项目经理,首先就应该成为这样的人。而我一直坚持认为,好的产品经理,一定是一个好的项目经理。

让自己成为团队中的SOULMATE,与你神交的人,要么是战友,要么是知己。

——————————

另一个地方阅读,微信公众号,欢迎关注

劣松同学   ID: liesongtongxue

在一个层次上沟通,什么层次?

回忆每一次需求方案的讨论过程,有一些讨论陷入僵局,需要反思。

创业产品阶段下,如果你要说服我1+1=2是错的,与其反复证明1+1=2是错的(毕竟需求很难证明),不如在1+1=3、4、5等芸芸答案中选出你认为正确一个,并且为这个正确答案的实现方法,构建出你认为的可行的、完整的方案。

Q1:为什么“不能反复证明1+1=2是错的”?

原因1 :干巴巴的讨论,不是证明手段,证明难度极大。互联网产品,对于一个如火如荼产品的功能及架构等细节,没有任何人是预测其方向生死的神。即使是JOE。精益创业的理念从来不是让一群人坐在一起讨论出某个决策方向的对错。提出需求,是需要认真思辨,但不能陷入自说自话的争吵。执行需求,则需要在假设-快速测试-验证并调整的循环,而不能在一些细节方面通过说话证明真伪。

原因2:真要消耗时间吗?不行,根本没时间。这不是学术研究,不是政策改革,是创业阶段的产品,每一个版本都是赶时间、拼生死的时候。我们坐在一起讨论之前,是不是都认同这是个创业产品,是在赶时间、拼生死呢?换句话说,我们的价值观,或者我们对问题的边界定位,是否一致呢?如果不一致,恐怕很难达成决策统一。

Q2:为什么说服我,要通过1+1=3、4、5等其他答案?

原因:这是最节省时间的方式,也是最推进项目的态度。说出你认为正确的方向,我们一起感受。

Q3:为什么你自己必须要为你选出的答案,构建可行的、完整的方案?

原因:如果你没想过,或没有能力想清楚是否可行,那是在耽误大家时间。如果你没想过,或没有能力想清楚完整的方案,那也是在耽误大家时间。更可怕的是,如果我帮你想出可行性、完整性中的问题,你仍然无法理解,那么问题已经不再是方案之间的差异,而是在提出方案的那个脑子里,对于问题理解、目标诉求的差异了。

归根结底,

层次1:价值观层次

不要把价值观层次简单的归结为“都是为了产品好”,这是最假的一句话。为什么假?因为有很多人的潜意识中,会天然形成“就算产品不好,我自己是否也能好”的思维,人性使然,这在所难免。价值观层次的判断,要赤裸裸的剥开KPI、考评、职位、金钱,避开这些不谈,空谈为了产品好,算什么价值观呢?产品哪个方面好?好的标准或参照物是否统一,是否可量化?

产品的设计让人无可挑剔,还是可以接受即可,这种也是伪命题,无法讨论出结果。为什么?无可挑剔,或者接受即可,是否有统一参照物、统一标准、可量化?没有的话,讨论没用。而恰巧对于产品设计的把控尺度,深埋于每一个人对于自身产品职位、产品角度的理解,别试图去找出参照物、量化标准,否则就好像是要统一所有人丢与美女的理解,多美算是美?谁统一的了呢?

层次2:能力层次

这个很直接。行就是行,不行就是不行。一方若承担了提升另一方某项能力的义务,相信也必然被赋予了安排另一方具体工作的权利。如若不是这样,双方的合作关系就是一起配合,那就要在一个能力层次上配合。用你明显的短板来要求我的专职业务,那就是刷流氓。反过来我若用我的短板来要求你的专职业务,也是在耍流氓。

所以更关键的问题是,认清自己的短板及强项,别被自己和环境蒙蔽,这是最重要最重要的。

思考到最后,仍然回到了认清自己的本质问题上面。无论是判断项目中各环节、包括自己的价值观,还是在具体配合中判断自己的决策是否自信、是否靠谱,判断自己的短板是否拿出来丢人,都是要从认清自己出发,深刻的,认清自己。同样的,也需客观理性的,认识他人。

【短】笼络团队的角色

铁打的营盘,流水的兵。

对于大部分项目来说,尤其在大公司当中,没有任何一个人是不可或缺的,谁走了,都可以有替代者让这个项目往前走。但,我的观点是,绝对不应该为了做到“任何一个人离开都会让项目正常运转”这一点,而刻意朝着这个方向努力。任人唯贤,目标第一,永远是最高原则。如果项目过分依赖某一个人,首先要问责的,不是工作分配不平均的问题,而是其他人为什么不可依赖的问题;如果值得依赖而未去依赖,那么才是用人的问题。铁打的营盘,再牛的兵也有可能是流水,别忘记营盘的责任,在这个基础上再去考虑兵吧。

如何笼络?

如何笼络那些值得笼络的兵,让他不要这么快流走,甚至可以常驻。在笼络之前,应该思考的是,兵的诉求是什么。与上一篇文章的思考一样,这次仍然回到认识一个人的问题上。在这个问题上,我也没有什么经验和方法,只能依靠自己基本的判断。粗糙的分类,或钱、或稳定的混着、或做事的成就、或个人的成长。换位思考,自己若处于对方的阶段及位置,想要什么呢?当然,如果连自己想要的都没想清楚,就别为别人操心了。

作为一个兵

自己想要什么?自己所想要的,有人知道吗?自己想要的,有努力的方向和渠道吗?就这三个问题。除了第一个问题,后两者可以暂时没有答案。但不能长期没有。

2013年年中。

隐性KPI:对项目管理的合理追求

问题:在产品发展和项目推进过程中,如何追求项目管理的科学性和合理性,是恰当的?

下文中提到的所有项目管理观点,全部都以“利于产品发展”为最高优先级的大前提,其他利于团队团结、公司发展等细节都次之。(当然都是可以方向一致、相辅相成的,你懂的。)

在一个产品发展过程中,根据架构背景、项目背景、产品背景三个方面的因素,综合考虑当前项目管理的最后方案,才能保证“利于产品发展”的目标。三个背景缺一不可,少评估一个,就多一份风险,默默的埋藏在执行过程中,并且很难被再次发现。

将三个层面的背景梳理清楚,才有可能综合的判断问题根结,假设:

架构背景:

1、产品、运营、视觉三个方面的跨部门合作;
2、各个部门中的团队考核标准不同,晋升机制不同,团队氛围不同;

3、各个部门中团队,前期没有进行过磨合,并且供职于不同领域的产品;

项目背景:

1、产品上线初期的快速迭代优化状态;

2、竞争市场非常激烈;

产品背景:

1、社区产品,依据线上情况及需求变动,随时作出产品动作;

2、产品负责制,说白了,就是产品部门说了算,并对产品最终负责;

“架构背景”所导致的实际问题:

Q1:架构背景不同,导致:团队之间的思维模式及个人愿景不同(架构无法改变)
Q2:不同的思维模式及个人愿景,导致:合作过程中的细节及方向分歧
Q3:细节及方向分歧,导致:合作过程中的过度讨论及精力消耗,以及最终决策权的实施
Q4:在消耗精力的讨论过程中,反复由产品实施最终决策权,导致:产品负责制的外在表现更强,即产品强势

Q5:产品强势,导致:其他非产品团队成员的工作归属感减弱、工作挫折感增强

面对可怕的Q5,当其他非产品团队成员怨声载道的时候,如何很好的解决这个问题?这也是我们目前要做的选择。

PS:在架构背景不同的前提下,尝试统一思维模式,让不同团队的个人愿景与产品愿景一致。能做到吗?

答:当然可以用各种方式统一跨部门、跨地域团队的个人愿景与项目愿景,比如项目宣讲、团队洗脑。但要质疑的是,这种仅限于表层的苦口婆心,是否真正能够战胜不同的架构背景?在当前的产品背景和项目背景下,我认为不可能。此类产品及项目背景,决定了该项目属于创业项目(大公司也有无数个创业型项目),这种创业项目,不允许让项目核心成员把精力聚焦在团队默契培养和远景统一方面。

如很多同行所说,大公司里搞创业产品,困难比创业公司更大。就是这个原因吧。

产品初创期间,没有一个强有力的默契的大团队,就已经是危险的了。面对这种困难,选一条错路来与架构背景死磕,就更危险了。

下面看看各种解决方案的优劣:

针对Q5的解决方案1:

1、制定明确的需求确认过程,三方或N方共同确认,由产品方面组织,说服各方,正正规规的抹平分歧,降低产品强势的感觉;
2、制定明确的流程控制策略,明确各个环节的时间节点和责任人,并跟踪各节点,控制流程进度,拉平产品部门与其他部门的地位,克服产品部门的封闭感。

即,侧重法制。

方案1的风险:

风险1:对抗“产品强势”而做出的流程设计,导致:合作过程中的需求确认更加严谨、分歧讨论更加频繁、进度控制更加流程化,即“死板的需求、无谓的讨论、机械的流程”。

比如:需求管理无弹性,导致试错成本增大,让各方需求提出更加谨小慎微。为需求做减法,可不是以扼杀积极性为基础。
分歧讨论的频繁发生导致各参与成员逐渐形成逃避分歧的行为惯性,或者导致各个参与成员在无谓的细节中浪费大量时间。

进度控制流程化导致任务质量与时间节点之间的矛盾更加突出。

风险2:“死板的需求、无谓的讨论、机械的流程”,导致:各个团队之间的合作关系比较机械,即将合作过程中的社会规范变为市场规范。

比如:过去我可以跟其他团队成员,共同完成一个作品。现在,我是让其他团队成员为我的产品完成一个任务。

面对靠谱的合作人,我可以因为更高的质量,而放宽时间进度。现在,时间进度的死板与分歧讨论的挫折感,让我与他都开始不自觉的规避违背流程的事情发生。

最终,冰冷的市场规范与无谓的时间浪费,导致:迭代速度下降、产品决策效率降低,影响产品健康度

方案1的适用条件:

1、各方团队对产品或需求把握能力基本靠谱,即,具有说服他人或被他人说服的基本前提。
2、产品发展趋于稳定。稳定的市场份额、用户群、竞品情况,决定了产品已经不需要频繁的大动作,正常的优化速度已经保证产品可以正常存活

3、跨地域或跨部门的团队合作比较频繁

针对Q5的解决方案2:

1、在沟通过程中,产品团队与其他团队的核心人员建立社会规范,让产品与其他环节的重要角色成为好基友,
2、避开无法统一的思维模式和个人愿景,而尝试统一团队之间的近期目标,以保证近期步调基本一致
3、好基友之间在工作过程中产品细节与方向分歧,仍然实施产品负责制,但基友的关系保证了受挫方的感情基础不动摇。

即:侧重人制。

方案2的风险:

风险1:人制过程,需要实施者有更完整的“情感应对”经验,实施起来很复杂,需要潜移默化的搞之。

比如:甚至针对不同的合作角色,采取不同的沟通和协作方式,以保证充分发挥不同合作角色的最大效率和能力。这一点很困难,做不好的话,人制优势尽失。如,有的人适合情感激励,对同一个工作培养出统一的认同感和成就感;有的人适合流程化的合作方式,到时间就交活儿,少废话。

风险2:虽然保证了效率和速度,放弃的则是制度化的工作沉淀和规范,不适宜大规模的项目团队或产品。

比如:人制过程必然导致多数环节的责任人不明确,或由“人制实施方”单方面承担,因此要求关键角色能力过关且素质靠谱,以保证任务产出质量的潜在风险,在周边团队和项目进程的忍受范围之内,且速度最快。不然,周边团队必然怨声载道。

没有制度和流程,导致多数细节无法回溯和落实责任人,则要求无制度无流程的社会规范,发挥更大的作用。

方案2的适用条件:

1、产品需要快速迭代、扛得住激烈的竞争环境,从而要求项目团队效率及质量优先,其他方面次之。

2、产品团队规模较小,各环节间的沟通及配合复杂度在可控范围内。

产品KPI的介入时机和制定方式,对产品很有影响。而对项目流程的期许,也或许是一种隐性的KPI,需要谨慎为之。

总之,在复杂的架构背景下,根据项目和产品背景的优先发展,调节架构背景所导致的各个变量(考核不同、个人愿景不同、能力差异不同等等),才能确定“最利于产品发展”的最优路径。

如果在这一个评估过程中,少考虑了一层元素,就会在流程实施中埋进隐患。表面上,流程顺利了、产出物质量稳定了、时间节点控制更加严谨了,但却很容易为了“顺利、稳定、严谨”,而在过程中付出了更大的时间和精力代价。这些时间和精力代价从哪里来?从产品中来。搞定的是流程,伤害的是产品。并且,这种伤害,却比较容易在“顺利、稳定、严谨”的喝彩声和欣欣向荣当中,被忽视掉。

这些都是人性,总是容易犯的错误,不是说把控就能把控的。比如说,一个总是能够高调满足阶段性KPI的产品,绝对是一个有可能挂掉的产品。而在产品发展阶段,把项目流程搞的“顺利、稳定、严谨”这一个愿景,也很有可能是另一种隐性的KPI,如同PV/UV一样,默默的在工作过程中影响着执行人的思维,从而映射到产品发展本身。

所以,在解决问题的时候,一定不能只冲着问题表面去解决,仍然要综合“三大背景”,周全考虑,才能降低风险,解析出最优方法。

这就需要沉浸在执行细节中,研究细节,记录下细节中表现出的真正问题,对症下药,才最安全。

@劣松 URL:http://www.liesong.me/?p=421

产品管理:用机制降低风险

最近一直在跟的一些项目,过程中出现了一些反复,原因有很多。深入分析一下问题根结,希望以后能避免。

关键词:产品负责制、确认层级机制、产品脊梁、靠谱

问题:

1、项目初期,产品原则已经开会统一、皆大欢喜,但中期却在产品原则上出现分歧。甚至在产品面临上线时,还有人为该产品赋予新的定位。

2、产品设计环节中,在产品需求和定位已确认的情况下,纠结在“不符合需求、偏离定位”的设计细节,僵持不下、浪费时间、拖垮精力。

3、跨部门合作的项目,设计部门提交的工作结果,经常被他们自己的上层或左右推翻重来,即使对产品有利,却伤害整个项目,伤害自己人。

根据这些问题,需要问很多为什么。

为什么初期统一过产品原则,中期却出现原则上的分歧?“发起分歧者”所具备的必要条件是什么?

首先需要问公司:产品负责制,到底有没有明确和落实?其实,产品人员已经也应该,把对产品的长期责任,承担在自己身上。但是公司层面和总监层面如果没有强有力的确认产品负责制的归属,我们这种自我承担的产品负责制,永远不会在关键时刻发挥作用,而只会左顾右盼。

在产品负责制尚不明晰的情况下,即使团队核心成员开会确认了产品原则,也永远不会有一个强有力的角色把产品原则贯彻到每一个阶段,初期产品定位和产品原则的会议确认,是没有力度的,只是表面上的统一而已。

原因很简单,当一切顺风顺水、条条大路通罗马的时候,旅游团众大佬必然跟着美女导游就OK了。当路遇挫折时,导游就算熟悉路途中的险恶,也仍然不是无法把自己伪装成团队的菩萨,左右不了各位大佬的想法。(默契,可以克服这一问题。但在大公司的营盘里面,想培养一个默契而完整的项目团队,一般是可遇不可求的。但默契的产品小组还是有的。)

在以上这种情况下,发起分歧者有什么必要条件?一是长期跟进产品,了解最初的产品原则和定位;二是了解整个团队的工作重心和产品市场情况,而不是只熟悉自己所管部门的情况。可悲的是,熟悉了以上两点的人,往往不会做出不靠谱的决策,而去伤害整个项目。

既然已经确定了产品需求,为什么会出现“不符合需求、偏离定位”的设计细节?为什么会在这种问题上浪费时间?

这种问题出现非常正常,当设计人员没有做充足的竞品分析,也没有充分理解产品的情况下,总会在设计时出现偏差。只要产品人员说明需求和修改原因,说服设计人员回归需求即可。可怕的是“僵持不下”,设计人员坚持己见,认为设计细节是正确的、靠谱的、符合产品需求的,产品人员却无法认同。僵持不下时,应该搁置问题,继续推进项目,而不是在这种问题上纠结一个下午,还把各种用户调研、应用实例搬出来说理。

最终做决定时,如果依旧僵持不下,那么谁对产品长期负责,谁做决定。谁对产品长期负责?回归的上一个问题。

为什么“工作结果”可以推翻重来?谁赋予了提交者“提交的权利”,又是谁赋予了推翻者“推翻的权利”?

首先要问的问题是:是不是根本没有明确“确认层级”的工作流程,或者只是口头明确、表面默契而已?
比如一个设计稿,当然要由直接负责人A确认,没有问题了,再交到下一步去执行。那么这个负责人A需要评估:自己是否能够保证这一个确认结果是最后结果。如果不能保证,那么再提交上一层的负责人,让他确认。但如果上层负责人曾经授权了负责人A的确认权限,就不应该在A已经确认之后,轻率的推翻确认结果。

在这种确认过程中,应该在每一个项目实施之前明确“相应的设计工作,需要有相应的确认层级”,这一点至关重要!“确认层级”都不明晰的情况下,首先应该检讨的不是设计质量没有达到要求,而是为什么会出现这种流程上的漏洞,让不符合设计质量的东西推进到下一步骤。漏洞不堵住,就没有资格反复插手,这样既伤害团队,也拖垮自己。

相反,当指定了项目设计工作的确认层级之后,再出现提交设计稿不合格、推翻设计工作不符合流程的情况,就可以明确的质疑“提交的权利”和“推翻的权利”,是否符合“确认层级”的流程。这个时候,是能力问题的就调整确认层级或更换负责人、是流程问题的就贯彻流程,比大家互相装无辜更加务实。

最后感叹一下,产品经理是妥妥的炮灰,哪个环节出问题,都可以揭出产品规划和项目管理的漏洞和伤疤

一个产品项目,从立项、交互、视觉、开发、测试等各个阶段,总会因为各种问题而反复伤害。尤其是跨部门合作、多环节配合的流程,伤害问题发生的隐患比比皆是。这个过程期间,产品经理的职责,就是想尽办法,避免各种伤害的发生、避免各种伤害打击到核心成员、伤及团队重心。

可悲的是,在大部分环境下,卑微的产品人员不仅无法预估各种隐患问题,对于已经发生的伤害问题也没有足够的防备资源和职权。这个时候,产品经理,就是妥妥的炮灰,众口一铄,灰飞烟灭。最后,产品经理仍然必须站起来,拖着被各种问题所累的核心成员,继续把项目推进下去。

不知道这种情况,在其他公司是否常见。当没有固化的产品负责制和确认层级管理机制的时候,深埋问题的跨部门团队开发产品,然后暴露出一堆问题,一遍又一遍的伤害每一个产品。所以,这种公司总是出现一堆一堆的打折产品,承担着一堆又一堆不给力的数据和市场境况,最后担责到产品人员身上,该调走的调走、该跳槽的跳槽,再招进下一批未知轻重的欣欣向荣者,如此反复、以至无穷。

关键角色位置的靠谱牛人,是产品的脊梁

产品团队,碰到这种复杂的情况,唯一的救命稻草,就是产品各环节的关键位置,有靠谱的关键角色把持,然后这类关键角色需要保持持续的头脑清醒、精神集中,在任何阶段都能回溯最初的产品原则、评估当前的团队重心和高层要求,统一麾下执行者的行动,并说服高层。

从这个角度讲,没有那么多流程管理和部门配合的小团队产品和创业公司产品,要更加安全、更加靠谱。近期组里的一个小众产品,没有大资源投入、没有多部门合作、没有高层压力、没有战略意义,虽然选择了一条难路,但整个产品从设计到运营,让外人看来,显得张弛有度、节奏明确,这就是一个明显的例子。

只要人靠谱,做什么都是靠谱的。如果人本身不靠谱,在任何角色上,都会出问题。至于什么问题:细节不到位、文档及版本控制逻辑不清楚、决策前后矛盾、协调成员配合乏力、工作重心聚焦不正确、沟通不主动……比比皆是。

希望自己靠谱一点。
@劣松 文章链接:http://www.liesong.me/?p=334

PD是个什么情况

我是一个有些急功近利的人。写博客可以帮助我暂时的静下心来,思考我的工作、计划、心事。2005年开始写博客,几乎前几年的日志,也是一种急功近利,或者无病呻吟。成长了这么多年了,再不成熟,就要成仁了。满是压力,全是压力。

做产品不足三个月,逐渐开始体会到了各种PM工作过程中的机关要害。看完隔壁老大书下的产经理炮灰论,在回头核对自己的各种无奈、短板、瓶颈,确实感同身受。呃,才三个月,就感同身受了。我是一个从党政机关脱身的理想主义者,至少这些无奈和瓶颈,还不足以撼动我对前一行的厌恶,和对这一这行的热爱。兴趣就是一切困难背后的支柱。不然,谁来做这个倒霉的中间人呢。

第一、产品策划,没有任何资源。

技术(前端、后端、页面)和视觉、交互,都是珍贵的资源。一个产品想法的实现过程,这些珍贵资源缺一不可。好在目前简单的视觉和交互,都可以由自己代劳,基本可以保质保量。而面对技术,只能鞍前马后的照顾各种项目的进度和优先级了。这一点告诉我,在没有能力让自己负责的项目获得较高的重视程度和优先级的时候,就必须学会跟各种脾气的技术骨干斡旋,并且让自己几乎可以完全胜任简单的视觉和交互工作。必须斡旋、必须胜任。

第二、产品策划,是最不值钱的人。

没错,一定是策划最不值钱。不能以为设计出新的产品功能,就站在了项目的最顶端。想法最不值钱,给出想法的人也最不值钱。策划要充当好产品功能的设计者、产品发展进度的控制者。但没有开发,一切产品设计和发展都是空谈。但没有这个产品设计和发展思路,另一个设计和发展思路同样可以充实开发工作。最不可替代的,当然是开发。次之者,也不一定轮得到策划。这就是现实。

既没资源又不值钱,还有什么盼头。

策划要热爱思考、可以产生想法,可以让想法实现,看到被别人实现的自己的想法成为上线的一道风景,何乐而不为?有兴趣才行,没有兴趣就完蛋。

慢慢研习吧,认清情况才能大步走不扯蛋。HOHO。

————————分————————割————————线——————————————————

今天天气很好,滨江阳光普照,当然也有些雾气蒙蒙的轻微污染。公司楼下竟然在拍电视剧,崭新的警车和粉丝小护士服,一看就是垃圾作品。

博完,跑步去了。