刚入职的时候，如果有人问我“你会听说读写吗？”，我应该会给他一个白眼，活了这么多年，怎么可能不会这些基本的生存技能？但是，如果现在再问我同一个问题，我的回答应该是“还不怎么会”。为什么答案不一样呢？因为产品人员需要的是升级版的“听说读写”—“用心的听、有力的说、高效的读、准确的写”。作为一个入职未满三个月的产品新人，想要把我对“听说读写”2.0的感悟分享给同为新人的小伙伴。

用心的听

大家在与人交流的时候可能会碰到以下情况。

对方说的不是自己想听的，自己想听的对方不讲，这种情况往往是由于双方没有统一沟通重点引起的。对于产品新人来讲，这里的重点更多的是指自己在学习过程中的知识或业务盲点，且交流的对象更多的是公司内部人员。

大多数情况下，新人进入一个项目的时候，产品已经在迭代了。这个时候，很多业务逻辑需要理解，但若只是通过PRD或其他记录文档去了解，很难在特别短的时间内了解整个产品的业务流程。然而，如果你愿意去拜托同组的前辈给你梳理一下，并针对自己的业务盲点发问，不仅节省了时间而且也能对业务有更深入的了解。然而如果只是去听而不及时发问，双方理解的沟通重点可能会有偏差，沟通的效率也会降低。所以，对新人来讲，不仅要做到用心听，还要及时问。

有力的说

产品人员在某种程度上说是靠“嘴”吃饭的，跟运营说，跟开发说，跟测试说，跟交互说，跟需求方说。那么对于新人来说，怎么去处理沟通的问题呢？首先，要“往桌前坐”，敢于表达自己的意见和看法。很多时候，新人常会因为担心自己的问题是不是太low？会不会引起别人的嘲笑？或者发表的一些看法会不会引起别人的不满？等原因而不愿发表自己的看法。

脸书第一夫人谢丽尔.桑德伯格在《向前一步》中也描述了这种担忧，书中提到每个人面临不确定性的事物都会有恐惧，而区别在于能否克服恐惧去表达自己。新人如果想要进步，想要提升自己就必须克服这种恐惧，并要告诫自己这些是必经之路，早犯错，早解决，早成长。

正如宜家创始人英格瓦·坎普拉德所说：“犯错，是积极主动者的特权。”其次，表达有力。没有重点，杂乱无章的表达往往是没有说服力的，并且会让对方对你的能力产生怀疑。

作为新人，怎么训练自己才能表达有力呢?

第一，别急着开口，先明确自己的对象是谁，需要传达给对方的重点是什么。

第二，开口时先说结论，让对方能够立即抓住重点；再分1、2、3点给出论据。为什么是“1、2、3”而不是“1、2”或“1、2、3、4”呢，因为研究表明3个论据是最容易说服别人且方便记忆的，这是套路啊。当然，这个1、2、3是要有先后顺序且相对独立的，一个论据说三遍可不行。

高效的读

随着互联网的发展，信息传递的成本大大降低，每天有大量的各种各样的信息轰炸我们的眼球。很多人特别是90后在这种大环境下习惯于被动的不加辨识的接受信息，主动阅读的能力逐渐退化。

那么新人怎么才能在相对有限的时间内，做到高效的阅读呢？

对我来说，不同的阅读对象会有一些差异。当阅读对象是前辈的PRD时，可以尝试将需求复盘并将自己的方案与前辈的做对比，找出自己的不足并寻找自己提升的空间；当阅读对象是产品相关书籍时，可以将自己的产品带入书籍中，与作者的思路做对比，思考为什么作者会这么做产品、这么做有什么好处、我的产品为什么没这么做等；当阅读对象是工具类书籍时，可以针对性的进行部分章节阅读。

每个人的读书都不一样，怎么将自己的读书效率最大化是最重要的。推荐给小伙伴《如何阅读一本书》，书中描述了读书的四个层次，读来很受益。

4. 准确的写

入职两三个月之后，很多小伙伴开始跟进需求并产出相关文档。而在写文档时，却很难确保方案的完整性和文字的准确性。

方案的完整性

为保证方案的完整性推荐使用MECE（Mutually Exclusive Collectively Exhaustive，相互独立，完全穷尽）分析法。以一个业务型需求的解决方案的产生为例：

上述例子中，使用了两次MECE分析法，第一次在需求分析中，保证了需求被正确分析、且选择出的方案最优；第二次在方案实现中，保证了业务流程被完全覆盖。

描述的准确性

“XX，你来看看你这PRD写的是什么意思？有问题吧？”每到听到这句话，小伙伴们的内心OS可能是“又没写清楚？是你理解能力有问题吧”。

讲真，很多新人在做方案写PRD的时候有些理所当然。比如金额字段，新人们可能就觉得这就是个金额字段啊，没什么大不了的啊。而忽略了这个字段怎么取值，是否可以为正值/负值/零、最大/最小值是多少、有无小数，四舍五入怎么处理等校验条件。我们可以把这些描述不准确的地方使用思维导图总结一下，下次再遇到就尽量避免。以输入框为例：

在不同的阶段对“听说读写”的认知也会不一样，这仅是作为一名新人的浅薄之谈，不妥之处，还望大家指教。产品之路漫长，愿和各位小伙伴一起进步。

作者：公子烨，电商平台的产品新人

本文由 @公子烨 原创发布于人人都是产品经理。未经许可，禁止转载。