没有技术背景？产品新人请收下这3大生存指南

w8484855@qq.com

在现行的教育体制里，没有产品学这么一个学科，并不像技术研发对应的是计算机或软件工程这个学科。所以，产品经理基本上是从其他职能转岗，而且学习和成长过程基本靠自学或者传帮带。典型的像微信之父张小龙以前就是程序员出身，一己之力开发了名噪一时的Foxmail，后来进入腾讯先后负责过QQ邮箱和微信产品，最后凭借微信名扬天下。

　　成功转型产品经理的人中间，有从技术转型的、有从设计转型的、有从运营或者市场销售转型过来的。尤其对初转型的产品新人，这些产品经理们在公司中承担的职责和面对的问题大同小异，如何能在产品之路上少一点荆棘，多一些成长呢？

　　结合本人从技术转型产品的过程积累的一些经验，给出一些建议，尤其是对于非技术背景转型产品的同学。

　　生存指南1：思维切换，技术思维vs产品思维

如果把产品比喻为房子，那产品经理就是房屋设计师。如果不懂基本的房屋结构和施工原理，设计出来的房屋很可能是无法落地的空中楼阁。

　　对于产品经理来说，每一个设计也都应该在现有互联网技术下可被实现。因此，产品经理学习一些基本技术知识，了解技术边界，对于实际开展产品工作都有非常大的益处。所谓**知彼，特别是在与工程师的工作配合和沟通中能起到关键作用。

　　在实际工作中不难发现，工程师更多的是路径推理的技术思维，产品经理更多的是用户场景的产品思维。产品思维和技术思维的碰撞让问题没有在正确的方向上被解决，原因其实就是双方用了不同的语系，好比一个讲英语的人和一个**语的人讨论一幅画，结果可想而知。

　　非技术背景产品经理，先忘记原有背景经验，以用户视角来看待产品，用产品思维去设计产品，用技术思维去沟通产品实现，能在不同的场景和面向不同角色完成思维切换，是产品经理的核心技能之一。

　　生存指南2：技能切换，写文档vs讲故事

　　产品需求文档（PRD）是产品经理必做功课之一。写PRD需要清晰的逻辑思维能力和文字表达能力，往往一个看似简单的功能，实则隐含了很多非常复杂的逻辑。

　　随着敏捷研发的逐渐普及，PRD随之简化，省去了很多繁琐的文档化流程。有的互联网公司甚至直接用产品经理制作的可交互原型来当做PRD，工程师根据原型进行开发，有问题就随时与产品经理沟通，在过程中发现和解决问题。

　　在现在这种快节奏的迭代方式下，更重要的是通过讲述需求的价值和场景，让工程师能感受到产品经理和用户的感受。以讲故事的气场去描述需求，进而把文档转变成故事蓝本，就像身临其境听故事的现场感，对比阅读书本故事的想象力那般。

　　以讲故事的方式沟通需求，和描述一个完整的故事一样，时间、地点、人物和情节。例如一款音乐播放器产品，产品经理设计了一个随机播放音乐的功能，如果从技术角度考虑这个功能可能觉得毫无意义，应该让用户选择喜欢听什么类型的音乐，至少也是场景，比如摇滚和睡前。

　　那随机播放音乐这个功能在什么场景下成立呢？以讲故事的方式描述需求可以这么说：“工程师小王上班一天晚上回到家，想听音乐放松下，此时已经没有心力再去挑选，打开产品点击随机播放，这种放松感和惬意是前所未有的。”

　　这样，时间（晚上下班后）、地点（家里）、人物（工程师小王）情节（需要放松）就都具备了，这种方式比单纯讨论一个随机播放音乐的功能要生动很多，也更有利于产品经理去推行这个设计。

　　对于现代产品经理来说，在自身技能树的丰富上，沟通和表达能力绝对算得上排前几位。完成技能切换，让讲故事的能力成为强项，会让产品之路顺畅很多。当然，不要瞎讲故事。

　　生存指南3：沟通切换，自我vs无我

　　沟通，产品经理心中永恒的痛，尤其是对非技术背景的产品经理，总有一种明明自己讲得很清楚对方却一脸茫然的错愕。

　　例如，产品经理听到工程师说，某个功能实现不了，就以为是技术实现不了。实际上真实原因，可能是时间不够，或技术方案比较复杂。这就像挖掘用户需求一样，用户want的并不是用户真正的need，想吃包子（want）其实是饿了（need）。

　　放下自我解读进入沟通，能让我们更好的在沟通中获取有效信息并取得主动权。“无我”就是不带有任何主观偏见去认识和讨论一个观点，而人最大的认知误区就是“不知道自己不知道”。

　　工程师的思维方式是一种线性而且逻辑性比较强的方式，他们认为一件事情肯定是按照固定的流程执行，不喜欢中间突然变化或者出错，因为这会使他们感到沮丧。

　　工程师又是一群极为“自负”而且追求极致的人。这种态度源于工程师对自己所编写的代码的掌控力，因为计算机是严格按照工程师所编写的程序代码来执行的，这种感觉会让程序员有一种控制力和驾控感。

　　所以我们经常会看到，当和一个工程师说他们写的程序有问题的时候，很多人的第一反应是：“不可能，怎么会有问题呢？”当这种情况出现的时候，产品经理应该换一种方式去与工程师沟通。

　　比如用一种问题转移的方式与工程师沟通，可以说：“我们在设计产品时有一个逻辑没有考虑到，但现在我们发现了这个问题，我们要一块儿把这个逻辑漏洞补上。”通过这种方式，维持工程师们的“自负”心理，然后将问题转移到产品逻辑没有覆盖到，既可以让问题顺利解决，也让双方都感觉好一些。

　　沟通是产品经理进阶路上的必修课，在“自我”和“无我”间的沟通切换，能让沟通来的更轻松些！

来源：网络