又撕逼了?产品人速速收下这5个护身符!
在这个快速变化的互联网时代下,产品经理的沟通协作能力很重要,在这样的背景下,需要我们准备好几项技能。作者分享了当中的5个“护身符”,一起来看看吧。
沟通是门艺术,但首先更是一门科学。4月10日,马云教父以“风清扬”的花名在阿里巴巴内网发布了《致改革 致创新》的帖子。
不知道大家看完该内部信是什么感受?
三表哥说这是一个时代结束了,因为他发现有不少同学在小红书底部留言:马云就马云,为什么说“风清扬”呀?
说实话,镜同学对其信中强调改革的重要和不易并没太多共鸣,反倒是信中下面这一句话一直在我耳边回荡!
“三五年的时间跨度对于互联网领域而言,犹如一个世纪之久,足以发生翻天覆地的变化,AI时代刚刚到来,一切才刚开始,我们正当其时!”
何止是互联网?
在这个AI时代,三年时间对于每个人体都足以发生翻天覆地的变化。
这两周我辅导了两个产品同学,虽然他俩都是才工作两年的年轻人,但镜同学觉得他们的思维认知都很优秀,尤其让我惊喜的是,他们早已开始利用AI来提升自己的工作认知。
比如,其中一名同学用AI整理了高级产品经理的知识库,并特意和我共享屏幕、交流讨论。
说实话,看后让我挺震撼,不仅维度齐全、内容丰富,各种链接、图片、视频、课程资料井然有序,而且还有很多产品方法论和优质作者资源(咱必须得偷偷炫耀一把,镜哥在其资源区置顶)。
当时就让我想起KK说过的一句话“AI不会淘汰一批人,但会使用AI的人会淘汰一批人”。
当然,我们还深度交流了另一个话题,这个话题反倒激起了我更多共鸣——产品人如何避免不必要的“撕逼”。
众所周知,在产品从构思到实现再到推向市场的过程中,咱们不可避免地会遇到各种意见的碰撞和冲突,这些场景我们通常戏称为“撕逼”。
“撕逼”这个词虽然带有些许戏谑,但它背后所代表的却是产品经理工作中真实而严峻的沟通挑战。
显然,对于这个话题,AI并没有给他提供实操性的指导价值,这也是镜同学想通过本篇文章和大家分享一些经验的原因。
事实上,在这个快速变化的互联网时代,产品经理的角色变得越来越重要,同时也越来越充满挑战,我们不仅是产品的策划者和设计者,更是团队协作的桥梁和纽带。
因此,在这样的背景下,护身符就显得尤为重要。
一、需求确认单
先讲一个案例。
去年我们公司业务调整,对定制化团队做了优化,但在工作交接中我们发现原先团队在项目管理上存在诸多问题,起初是有好几个项目需求不明确,随时是陆续不断的新增需求。
有好几次产品经理在和甲方做需求调研时,明明在会议上已经确认了需求范围,可过不几天,我们公司业务人员就来反馈说甲方又增加了需求,又强调说这个业务对公司很重要,希望产品经理能抓紧时间设计一下。
甚至有些业务人员善于夸大其词、拿鸡毛当令箭,如,威胁说这些需求如果不能及时设计完成,产品经理就得被扣工资,还需要对项目失败负主要责任。
原本我们的处事逻辑是以协同解决问题为导向,可我本将心向明月,奈何对方把我们善良当傻X,况且,这些不确定的临时任务都需要加班完成,也增加了其他产品需求的延期风险。
我们先做了内部复盘。
结果就是产品经理是严格按照设计流程在做工作,如,业务人员提报的有市场需求文档,我们产品经理也让他们做了市场需求确认,《需求确认单》上签的都有他们名字。
这就够了。
而向上追溯发现,反而是公司业务人员在和甲方的合同里没有将需求明确,缺失《需求确认单》附件,更没有让项目甲方签字确认需求范围,他们所谓基于的共识其实都是只停留在没有法律效力的口头上。
更干脆点说,甲方新增需求有其法律支撑,因为部分合同条款赫然写着乙方(我司)应根据甲方需求完善产品设计,确保满足甲方业务需要;而我们业务团队拒绝需求反而缺失有效支撑,因为我们没有甲方签字的《需求确认单》。
于是,我们在撕逼大会上拿出了《需求确认单》,优雅又不失礼貌地驳斥了业务人员的超纲需求,他们则底气全无,不再对产品强硬施压,而是变着法求着产品经理帮忙,毕竟,他们对客户的过度承诺总归得要兑现。
所以有人说,确认共识是契约精神的影子。
当然,我们最后仍然协同着业务团队解决题外需求问题,首先就是让业务开始先和甲方先签《需求确认单》。
所以,咱们作为产品经理天天和需求打交道,这个护身符得赶紧收下,此瓜不光保甜还保绩效。
二、会议纪要
会议是沟通协作的重要工具,会议纪要则是会议成果的具体体现。
但现实中却有不少产品同学不这么认为,他们习惯把会议纪要看的很清,总是认为没必要记录重复事项,有这个时间还不如多做几个需求设计。
事实上呢,会议纪要不仅对于关键事项的切实推动有着不可替代的作用,更重要的是对我们产品人的自我保护,避免不必要的撕逼。
因为,会议纪要不仅是明确各方责任,更是储存关键证据,是解决未来争议的重要依据。
前两天,业务同事气势汹汹地找上门说他有个需求我们没有做,产品经理解释了好几次是分步迭代,他反而更来劲了,说我们拿迭代当借口忽悠他,他压根就不知道、不认同迭代推进。
产品同学没再争论,直接翻出来了当时的会议纪要,上面清楚地写着该需求的会议结果是延期处理,而且,还特意@该业务同学,并提示需要明确回复该行动事项。
说到这里,咱就得表扬下该产品同学,他不仅在会议纪要中对待办事项有明确的记录,还做了跟进确认,更重要的是上述案例中的业务同学还回复了“无异议”,才让产品同学底气十足、掌握了撕逼的主导权。
三、正式邮件
众所周知,邮件的主要特质就是书面、正式、可追踪。
正是因此,才使其成为了产品经理在沟通协作中的可靠帮手,我们越是面对不确定性的事项,就越要有意识地主动发个正式邮件,在我看来,这既是当下的信息广播,也是未来的区块链锁。
镜同学认为,在互联网产品的撕逼大战中,邮件就像是一把锋利的瑞士军刀,不仅能用来开路,更能用来防身,这也是我多年来的切实感受。
所以江湖有言:“笔下有真理,邮件有证据。”
在产品设计时,我们经常面临需求变更、项目延期、争夺资源等撕逼场景,而一封正式的邮件就成了你关键时刻的“护身符”,是需求变更的“确认按键”,是项目延期的“时光机器”、是资源争夺的“和平使者”。
事实上,产品同学的工作错综复杂,沟通分歧是常态,冲突管理自然就成了基操,“以暴制暴”不是问题的有效解,有条不紊、自信有底气才是避免撕逼的核武器。
而正式的邮件往往就是文明长存必不可少的核武器。
四、复盘分析报告
如果说前面三种讲的都是事前所需要做的准备,那若准备不充分导致即将发生撕逼或是已经发生了争执,这种情况下,亡羊应该如何补牢呢?
镜同学的经验是抓紧做复盘分析,系统回顾关键过程并认真编写事后报告,当然,你要在报告中整理对自己有利的因素,抢占先机,掌握主动权。
需要提醒的是,咱们主动去做复盘分析、争取有利条件是好事,但是切记要基于事实,不能主观论断,并在表达上要多列举数据,做好逻辑支撑,同时要给出复盘结论,而不是空洞的流水账。
比尔·盖茨所说:“你的最不满意的客户是你最好的老师。”
类比到撕逼场景其实也是一样,和我们撕逼的对方一定程度上也是我们不满意的客户,复盘首先要有学习的态度,这是面对最好老师的最好姿态。
就在昨天,我们有个项目未能如期上线,主要职责在产品经理,一是其设计考虑不全面导致需求变更太多;二是他在项目管理经验不足,没有做好风险识别和过程管理。
但他第一时间做了很诚恳地复盘分析,并且复盘分析报告很务实,不仅自我批评个人设计能力不足、项目管理问题,而且还应用PDCA的闭环思维,给出了扎实的改进措施,最重要的是他还直接把该报告发在了项目群里。
这种低姿态的复盘带来的直接结果就是,还没来得及撕逼,撕逼就结束了,这大概也算是另一种高层次境界,难怪人都说真诚是最大的杀手锏。
五、向上反馈汇报
前面说的四个护身符都是结果载体,而向上反馈汇报则是过程工具,但你别小看这个反馈,从某种意义上来说,得体、合时宜的向上汇报犹如高压锅的泄气阀,天然能为你释放压力。
我们总说,不是一个人的王者,而是团队的荣耀,而领导作为团队leader往往是经验丰富,更能为你指点方向。
相反的,如果很多事情领导不知情,那过错就只能是过错,他想帮你圆场恐怕都心有余而力不足。
比如,前段时间我们的移动端APP被小米应用商店所下架,负责的产品经理也十分用心地在沟通解决问题,但是他从未向上汇报,导致该问题反反复复折腾了3个月。
最后在复盘撕逼时因为没有铠甲护体,迅速残血还冲塔失败。
不仅如此,主动向上汇报应该是产品人的基操,既有利于辛苦付出后的成果体现,也有助于及时获取领导新方向,不至于无端沉默成本。
再举个例子:
前两天,我们某项目经理在早会明确要求产品同学上午发出需求迭代计划,以便他向上汇报,也给业务团队同步。
该同学也明确回复收到,说上午11点前发出来,但他在沟通时发现需求有变更,就想着先处理完再发布。
这一来二去,耽误了两三天,面对项目经理追责时却无言以对、无法争辩。
事实上,当时他只要多汇报一句话就能避免这样的后果,甚至直接在群里发个消息也是好的。
比方说:因需求有变动,迭代计划需要重新调整,调整完成后第一时间发布,请各位领导知悉。
如果领导有特殊要求一定就会联系你,你也不会因反馈不及时而被否定,要知道,放领导鸽子最容易被贴上不靠谱的标签。
最后,镜同学想说,作为产品经理,我们的工作就像是指挥一场复杂的战役,需要与各个兵种紧密协作,在这个过程中,难免会遇到意见不一、利益冲突的“撕逼”时刻。
正如孙子兵法中所说:“故善战者,求之于势,不责于人。”
我们应该依靠制度、流程、机制等智慧来解决问题,而不是相互指责撕逼,这也是良性生态的基本特征。
而本文所分享的需求确认单、会议纪要、正式邮件、复盘分析报告、向上反馈等工具都是我们的“护身符”,也是我们解决问题的关键法宝。
也正如历史上的“合纵连横”,智者通过策略和联盟来稳固地位,我们也需要智慧地运用这些护身符,来巩固我们在产品工作中的专家地位。
希望对你有启发。
专栏作家
产品大峡谷,公众号:产品大峡谷,人人都是产品经理专栏作家。七年B端产品经理,供应链物流与金融领域,擅长需求设计、业务指导、商业观察等。
本文原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自Unsplash,基于CC0协议。
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
说得很好,受教了
说的很实在