在本文中，创作者将结合自己的一些从技术上转化产品的工作经验，得到一些建议，尤其适合在非技术场合转化产品的同学。
随着互联网的发展，产品经理已经成为每个互联网公司的标准配置。很多传统工业企业服从“互联网技术”的策略，刚刚开始逐渐接触互联网，产品经理也慢慢从it行业之外扩散到其他领域。虽然传统行业本身有自己的产品经理，但是在岗位职责的界定上还是有一些差异的。今天大家熟悉的产品经理应该是互联网技术产品经理。尤其是随着以乔布斯、微信张小龙为代表的最优秀产品经理的出现，产品经理这个职位也披上了可以改变命运的盔甲，以至于一批人涌入这个职位，开始了各种战斗。
在目前的标准教育体系中，没有产品科学这样的课程，不像技术研发，是计算机或者软件开发的课程。所以大部分产品经理都是带着其他职责跳槽，学习、培训、成长的基础都靠自学或者师徒。微信的创始人张小龙，之前出生在成。他自己开发设计了著名的Foxmail，然后去腾讯依次承接QQ邮箱和手机微信产品，最后凭借手机微信名扬天下。
成功转型产品经理的，有从技术、设计方案、运营或销售市场转型的。在此之前，很有可能有大量的人是从技术转型过来的，尤其是那些自己了解产品，没有资格只完成功能的专业技术人员。到现在，除了专业技术人员，转型做产品经理的人越来越多，而且情况多元化。尤其是对于初期转型中的新手产品，这类产品经理在企业中有着相同的工作职责和问题。他们如何在产品上少一些刺，多一些发展？通过整合一些在技术改造产品全过程中积累的工作经验，我想出了一些建议，特别适合非技术情况下正在改造产品的同学。
生存指南1：逻辑思维转换，技术性逻辑思维vs产品逻辑思维如果把一个产品描述成房子，那么产品经理就是房子设计师。如果室内设计师不了解基本的建筑结构设计方案和工程施工的基本原理，那么设计方案出来的房子很可能就是一个落地阁楼。理想化的设计方案必须与物理的局限性合理融合，不会出现真实的空别墅和锁妖塔。在工程项目行业，每一个设计方案都可以完成。对于产品经理来说，身处互联网科技行业，设计互联网科技产品，每一个设计都应该是在当前大数据技术下完成的。对于产品经理来说，学习和培训一些基本的技术专业知识，掌握技术边界，开展具体的产品工作是非常有益的。说白了就是知己知彼，尤其是在与工程师的合作与交流中。
在具体工作中也不会太难发现。产品经理和工程师在讨论一个实际问题时，会从各自的角度对问题进行分析和讨论。原有知识体系的不同，会导致思维方式和视角的不同。工程师多是以逻辑推理的方式进行技术逻辑思维，产品经理多是客户情况的产品逻辑思维。产品逻辑思维和技术逻辑思维的碰撞，使得问题得不到应有的处理。其实原因是他们使用的语系不同。就像一个说英语的人和一个说法语的人讨论一幅画，结果很明显。
对于非技术型的产品经理来说，忘记原有的工作经验，站在客户的角度看待产品，用产品逻辑思维设计项目产品，用技术逻辑思维沟通产品完成，在不同的情境下，向着不同的人物进行逻辑思维的变化，是产品经理的关键职业技能之一。
生存指南2：专业技能转换，写文本文档vs说故事产品需求分析文档(PRD)是产品经理必须做的功课之一，尤其是在初级和中级产品环节。写PRD也是这个环节产品经理的重点工作之一。写PRD一定要有清晰的思维逻辑工作能力和文字语言表达能力。通常一个看似简单的功能，其实隐含着很多复杂的逻辑。在传统的项目管理开发过程中，产品需求分析文档是非常关键的原始资料，产品经理必须把文本文档中的每一个关键点都写得很详细，不能有任何遗漏。这通常会整合到软件开发中的瀑布式开发流程中，即需要数周甚至数月的时间来定义需求、编写需求分析文档，然后投入资金进行多月的开发和设计。
然而，在当今这个变化强烈的网络时代，这种产品研发方式显然无法解决销售市场的变化。所以近几年智能产品的研发会普及。匹配，PRD也变得简化了，省去了很多复杂的文字文档步骤。有些互联网公司甚至马上把产品经理做的交互原型作为PRD。工程师刚开始按照原型开发设计，有问题随时随地可以和产品经理沟通，全程发现并解决困难。
如今，在这种快节奏的迭代更新方式下，撰写文本文档已经不再是一项关键的专业技能。按照简单的文字和步骤，用文字将需求形式化就足够了。更重要的是根据叙事需求的使用价值和场景，让工程师感受产品经理和客户的体验。用讲故事的气质来描述需求，从而将文本文档转化为小故事的原型，就像亲身听别人讲故事的临场感与阅读文章、书籍、小故事的想象力相比较一样。
通过讲故事的方式进行交流，需要和讲一个详细的小故事一样的时间、地址、角色和情节。比如一个音乐播放软件产品，产品经理设计了一个任意的音乐播放功能。如果从技术角度来看，这个功能很可能会觉得毫无价值，那么应该要求客户选择他们喜欢听哪种类型的歌曲，或者至少是场景，比如摇滚乐和就寝时间。任意播放音乐的功能是在什么情况下产生的？讲故事要求你可以说:“小昭是一名工程师，他工作了一夜回到家，想听听歌曲来缓解压力。这个时候，他已经没有精力再去选择了。他打开产品，随意点击视频。这种缓解压力的休闲方式是前所未有的。”这样一来，时间(晚上下班后)、地址(在家)、角色(工程师小昭)和情节(必须释放压力)都有了。这种方法比单纯讨论任何音乐播放的作用要生动得多，也更有利于产品经理实施这种设计方案。
就当代产品经理而言，就自身技能树的丰富程度而言，沟通和语言技能绝对是名列前茅的。改变专业技能，把讲故事变成优势，会让产品流畅很多。自然也就不用废话了。
生存指南3：沟通转换，自身vs无我沟通是产品经理心中不断的痛，对于非技术产品经理来说尤其如此。说话清楚的对方总有一种震撼。在所有的沟通中，很大的问题是沟通者只表达自己，少数学会放下自己去沟通。说白了，学会放下自己，其实就是能够倾听别人的表情。看似简单，但很多时候，人们以为听到的，并不代表他们就理解了。
比如产品经理听到工程师说某个功能完成不了，他就认为技术上完成不了。其实真正的原因可能是时间不够或者技术规范复杂。就像发现用户的需求一样，客户想要的并不是客户真正的需求。想吃包子其实是饿了。学会放下自我解释，进入交流，会让我们获得合理的信息内容，在交流中获得主导权。走进“无我”的情境，才能在整个沟通过程中更加得心应手。“无我”是指不包含所有的主观刻板印象去理解和探究一个观点，而人的更大认知能力的错误观念是“不清楚自己”。
工程师的思维方式是线性的、逻辑的思维方式。考虑到困难的问题或行动通常是按照严格的顺序和逻辑进行的，他们觉得一件事必须按照固定的步骤进行，讨厌中途突然改变或失败，因为这会让他们感到沮丧。
工程师也是一群极度“骄傲”、追求完美的人。这种“骄傲”不是贬义的骄傲，而是对自己所做的事情的一种自信。这种自信超过了传统的自信，所以用“骄傲”来形容这种过剩的自信。这种心态来自于工程师对自己写的代码的掌控。因为电子计算机是严格按照工程师编写的编程代码执行的，这种感觉会给程一种控制感和驾驶感，而这种感觉会给工程师这种“骄傲”的效果。
所以我们经常看到，当我们去找一个工程师，告诉他们自己写的程序有什么问题的时候，很多人的第一反应是——“不可能，为什么会有问题？”不，更多的是因为这种“骄傲”让工程师对自己的编码无比自信。因为电子计算机严格遵守没有编程代码的标准，一旦出现问题，说明编程代码在逻辑上有错误，这种错误肯定是工程师留下的，但人的本能反应是不愿意承认自己的错误。
因此，当这种情况发生时，产品经理应该用另一种方法与工程师沟通。比如用一个问题迁移的方法和工程师交流，可以说是“我们在设计项目产品的时候没有充分考虑一个逻辑，现在做完了才发现这个问题，要一起把这个逻辑漏洞补上。”按照这种方法，可以维持工程师的“骄傲”心理状态，然后用问题迁移法来迁移问题，直到不覆盖产品的逻辑，既可以让问题处理成功，又可以让双方都好过。
沟通是产品经理晋升的必修课。“自我”与“无我”的沟通，可以让沟通变得更容易！
#有关创作者#微信公众平台唐人:ryantang007，大数据技术产品运营人，是《产品经理必须知道的关于技术的一些事》的创作者。
未经批准，严禁截留。
注:阅读相关网站基本建设方法的文章，请移至网站建设教程频道栏目。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）