生存指南1：思维切换，技术思维vs产品思维
如果把产品比喻为房子，那产品经理就是房屋设计师。设计师如果不懂基本的房屋结构设计和施工原理，那设计出来的房屋很可能就是无法落地的空中楼阁。理想的设计和物理的限制必须有效结合，不存在真正的空中花园和通天塔，在工程领域，每一个设计都是可以被实现的。对于产品经理来说，置身互联网领域，设计互联网产品，每一个设计也都应该在现有互联网技术下可被实现。产品经理学习一些基本技术知识，了解技术边界，对于实际开展产品工作都有非常大的益处，所谓知己知彼，特别是在与工程师的工作配合和沟通中能起到关键作用。
在实际工作中不难发现，当产品经理与工程师就某一个具体问题进行讨论时，双方站在各自角度就问题进行分析和讨论，固有知识结构的差异会使得各自思维模式和视角的差异，工程师更多的是路径推理的技术思维，产品经理更多的是用户场景的产品思维。产品思维和技术思维的碰撞让问题没有在正确的方向上被解决，原因其实就是双方用了不同的语系，好比一个讲英语的人和一个讲法语的人讨论一幅画，结果可想而知。
非技术背景产品经理，先忘记原有背景经验，以用户视角来看待产品，用产品思维去设计产品，用技术思维去沟通产品实现，能在不同的场景和面向不同角色完成思维切换，是产品经理的核心技能之一。
生存指南2：技能切换，写文档vs讲故事
产品需求文档（PRD）是产品经理必做功课之一，尤其是在初级产品阶段，写需求文档更是这一阶段产品经理的主要工作之一，写PRD需要清晰的逻辑思维能力和文字表达能力，往往一个看似简单的功能实则隐含了很多非常复杂的逻辑。在传统软件项目开发流程里，产品需求文档是非常重要的材料，产品经理需要把每个细节在文档里写得非常详细，不能有一丝纰漏。这往往适应于软件工程里瀑布式的开发流程，即花几个星期甚至几个月定义需求并写需求文档，然后再投入几个月开发。 但在现在变化剧烈的互联网时代，这种研发方式明显无法应对市场的变化。所以敏捷研发才会在近年来逐渐普及。对应的，PRD随之也变的简化，省去了很多繁琐的文档化流程，有的互联网公司甚至直接用产品经理制作的可交互原型来当做PRD，工程师根据原型即开始进行开发，有问题就随时与产品经理沟通，在过程中发现和解决问题。 在现在这种快节奏的迭代方式下，写文档已经不再是核心技能，能通过简单的文字和流程把需求书面化表达出来即可，更重要的是通过讲述需求的价值和场景，让工程师能感受到产品经理和用户的感受。以讲故事的气场去描述需求，进而把文档转变成故事的蓝本，就像身临其境听故事的现场感对比阅读书本故事的想象力那般。 以讲故事的方式沟通需求和描述一个完整的故事一样，时间、地点、人物和情节，例如一款音乐播放器产品，产品经理设计了一个随机播放音乐的功能，如果从技术角度考虑这个功能可能觉得毫无意义，应该让用户选择喜欢听什么类型的音乐，至少也是场景，比如摇滚和睡前。那随机播放音乐这个功能在什么场景下成立呢？以讲故事的方式描述需求可以这么说：”工程师小王上班一天晚上回到家，想听音乐放松下，此时已经没有心力再去挑选，打开产品点击随机播放，这种放松感和惬意是前所未有的“。这样，时间（晚上下班后）、地点（家里）、人物（工程师小王）情节（需要放松）就都具备了，这种方式比单纯讨论一个随机播放音乐的功能要生动很多，也更有利于产品经理去推行这个设计。 对于现代产品经理来说，在自身技能树的丰富上，沟通和表达能力绝对算得上排前几位。完成技能切换，让讲故事的能力成为强项，会让产品之路顺畅很多。当然，不要瞎讲故事。生存指南3：沟通切换，自我vs无我
沟通，产品经理心中永恒的痛，尤其是对非技术背景的产品经理，总有一种明明自己讲得很清楚对方却一脸茫然的错愕。在任何沟通中最大的问题是沟通方只表达自己，却少有放下自己去沟通，所谓放下自己其实就是能听进去别人的表达。看似简单，可很多时候我们以为的听进去只是听到了，并不代表听懂了。 例如，产品经理听到工程师说某个功能实现不了就以为是技术实现不了，实际上真实原因可能是时间不够或技术方案比较复杂。这就像挖掘用户需求一样，用户want的并不是用户真正的need，想吃包子（want）其实是饿了（need）。放下自我解读进入沟通，能让我们更好的在沟通中获取有效信息并取得主动权。进入”无我“的状态能在沟通过程中更加游刃有余，”无我“就是不带有任何主观偏见去认识和讨论一个观点，而人最大的认知误区就是”不知道自己不知道“。 工程师的思维方式是一种线性而且逻辑性比较强的方式，考虑问题或者作出行动时往往会按照严密的顺序和逻辑进行，他们认为一件事情肯定是按照固定的流程执行，不喜欢中间突然变化或者出错，因为这会使他们感到沮丧。 工程师又是一群极为“自负”而且追求极致的人，这种“自负”并不是贬义的自负，而是一种对自己所做的东西的自信，这种自信又超出传统的自信，所以用“自负”来描述这种超额自信。这种态度源于工程师对自己所编写的代码的掌控力，因为计算机是严格按照工程师所编写的程序代码来执行的，这种感觉会让程序员有一种控制力和驾控感，这种感觉会让工程师们形成这种“自负”的效应。 所以我们经常会看到，当去和一个工程师说他们写的程序有问题的时候，很多人的第一反应是——“不可能，怎么会有问题呢？”没错，正是因为这种“自负”让工程师对自己所写的代码极为自信，因为计算机是对程序代码毫无条件的严格执行的，一旦出现问题，就说明程序代码在逻辑上存在错误，而这种错误肯定是工程师留下的，但人本能是不愿意承认自己的错误的。 所以，当这种情况出现的时候，产品经理应该换一种方式去与工程师沟通。比如用一种问题转移的方式与工程师沟通，可以说“我们在设计产品时有一个逻辑没有考虑到，但现在我们实现时发现了这个问题，我们要一块把这个逻辑漏洞补上”，通过这种方式就可以维持工程师们的“自负”心理，然后用问题转移的方式将问题转移到产品逻辑没有覆盖到，这样既可以让问题得以顺利解决，也让双方都感觉好一些。 沟通是产品经理进阶路上的必修课，在“自我”和“无我”间的沟通切换，能让沟通来的更轻松些！ 本文转自微信公众号：ryantang007。【转载说明】 若上述素材出现侵权，请及时联系我们删除及进行处理：8088013@qq.com
