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