产品经理那点事之沟通

144
作者 dreamaj
字数 4137 阅读 32评论 0

 

“沟通是产品经理的常规武器之一。在我看来也是最重要的一种武器,沟通能力不行,那么很可能就意味着你在工作中没有那么顺利。我从技术转型PM的时间不多,不过也有了一些关于沟通方面的自己的积累,现在尝试对这些积累进行实体化的总结。”

我将沟通分为以下六个方面。

1. 注意沟通逻辑

面对一项复杂的功能时,需要给小伙伴们去讲述你的产品逻辑时,一定要注意你讲话的逻辑,请确保大多数人能够在花费最少的代价,最短时间内明白你的需求,没错就要这样做,那如何做到讲话简单易懂呢?我用的方法其实就是把自己讲话的要点进行二叉树结构化(可能是技术出身,干啥都离不开技术O(∩_∩)O),从父节点开始,一个流程一个流程的讲述。不要试图想用一段话将整体内容全部概况,不现实的。既然是概况,就以为着细节是遗漏的,最后做出来的东西,跟你想象的东西大概率是不一样的。

2. 说话语速

绝大多数人在给别人将事情的时候,未经组织的发言都是自认为大家能够听懂的语言。所以PM在跟小伙伴们进行沟通的时候,一定要放缓语速,给大家一个短暂的接受与消化时间。在沟通需求时,可能一个功能需求没听懂,可能会影响下一个功能需求,毕竟产品内的功能都是关联性的。试问,在放缓语速的情况下一遍过的需求舒服,还是机关枪一样的语速,对着小伙伴们来回来去的突突5、6遍(如果他们很享受这个过程,当我白说~)?

3. 带着原型说话

老话讲,好记性不如烂笔头,其实说的就是图形界面的重要性。将需求以及交互体现在图形上来说,对任何人都更直观,更容易理解。将需求中要注意的地方一一标注出来,并写清楚为何这样,讲清前因后果以及用户场景。这样的话,在开发过程中,开发人员能够专心的进行coding,相关没遇到一个问题就需要过来提问,这样对双方都是一种很奢侈的浪费,毕竟workin/out(我给命名的,意思是说在工作时进入忘我状态,该状态下的工作效率确实是高到可怕。可惜的是,进入这样的状态所花费的时间有点长)耗费的时间却是不短。

4. 带着解决方案说话

曾经纯银大大说过这样的一段话。“推动产品观点的时候,除了论证观点的正确性,更重要的是提出观点背后一整套的实施方案(哪怕粗一点,哪怕只是可行性强的解决思路),这样才有推动力。重要的产品改动都是牵一发而动全身,不解决“动全身”的那些疑难点,你的产品观点再怎么正确,别人的接受度也是很迟疑的,推进速度也是很缓慢的。”这段话我一直看作是我的警句。推动力在我看来其实就是大家对工作的积极性,积极性从哪里来,就是大家对工作的喜爱,我一直认为兴趣驱使工作是最轻松也是最高效的。大家对你的产品观点都表示或多或少的迟疑的时候,会带着问号去工作,试问这样又怎能全身心的投入?

5. 避免争吵,尝试从对方的角度考虑问题

在遇到双方意见不统一的情景下,需要考虑是否将需求放入了典型的用户场景中,让场景来说明一些,不要谈自己的观点,所有逻辑全都是建立在场景的基础之上的,脱离了场景,也就成了无稽之谈了。如果还是有不同意见,那么这时候要静下心来从对方的角度考虑问题,是什么问题导致对方对你提出的需求有抵触,短时工作量、开发难度亦或是觉得与其无关。经过分析后,对症下药,将这需求的完成与其KPI联系上,让他知道做完这个功能会对整个产品有多大的帮助,亦或是能在以后帮助他减少多少工作量。

PS:这些特质只是个人工作经验中的认识,不代表标准答案,仅供探讨,还望各路前辈指点。

-----来自一野蛮生长的产品经理AJ


经验分享
登录 后发表评论