一个会“讲人话”的产品经理有多重要

　　常听到有人讲了几十分钟的理论，却被一句：说人话！给呛住。以前这个场景多是“技术产品”，现在更多的是“产品运营”。原因如下：
　　大部分的技术由产品对接，运营更多的是面对产品
　　逻辑思维的不同，产品思维是多个视角的出发，结合了产品逻辑、业务形态、商业前景等等。而运营则是更多价值的聚焦，包括某个活动、某个场景、人群、需求等。
　　产品经理是自负的，这在创业公司更常见，也是因为对应的运营还没有足够经验。
　　具象化视角的不同，这和逻辑思维又不一样，比如：
　　喵：国庆节想要增加特殊化标签，增加用户活跃度
　　狗：特殊化标签有哪些形态？应用场景什么？预计会增加多少日活？时间点是什么？有没有考虑过用普通标签满足需求？那为什么不把普通标签一起优化呢？
　　喵：。。。说人话
　　往往就没有了然后！
　　这应该是每个产品经理都会遇到的问题，因为产品经理本身赋予了更多的使命，去思考的更多、构架的更多，且要担任运营与技术的需求润滑剂。筛选需求、完成需求、计划需求！
　　产品经理如何讲人话？
　　首先从产品的迭代讲起，产品迭代涉及了需求收集、需求分析、产品定稿、需求评审、里程碑、测试验收、产品发布等等。发现其中运营仅在第一步“需求收集”中占有角色，而需求的来源包括了：用户、运营、产品、BOSS等。
　　早期的创业公司总是产品先行，在发展到一个阶段后再由运营去驱动，所以每次迭代通常是一个大功能用户小需求和优化。
　　在技术、测试完成后，我们通常会召开内部的“产品发布会”，在大号电视前演示迭代增加和优化的功能，发布会总是很成功的顺利举行！！！
　　产品上线后，PM又开始了新一轮的需求收集，而喵们也开始运营当前的产品功能（产品运营），但总发现运营对产品的功能不了解，在运营过程中还会反复的询问产品！
　　当时很无奈，应对的措施是：针对每一版本迭代去更新“产品运营规则说明文档”，我记得当时后台的一份文足有8000字，之后发现效果还是不行，索性将需求文档（PRD）也抄送给运营。再之后我们开始邀请运营一起参与到需求评审中！
　　直到。。。
　　“能不能说人话！”
　　什么是人话？
　　我自己也思考了很久，也和BOSS沟通后得出以下几点：
　　运营需要背负自己的责任，产品不应该处处领先运营
　　不把运营当baby，尽量的等量
　　运营是产品，产品即运营
　　我更换了和运营沟通的方式并做了更多的交流，舍弃“产品运营规则说明文档”和PRD文档的“死人式”交流，尽量的做到facetoface，沟通的基础上再辅以功能更新说明（用最简单的方式陈述功能）。如：
　　XXXAPP2。3版本更新内容：
　　增加了IM（在线聊天），支持商家对用户，不支持群聊（原因已做说明）
　　我的页面优化，增加我的权限（权限展示）
　　xxx、xxxbug修复
　　xxx页面xxxUI优化
　　在事后做了进一步的沟通和对比，发现运营对这样的操作接受度和兴趣度更大，再加上验收时邀请运营参与也会增加运营的兴趣度和对功能的理解。
　　当运营提出需求时
　　这些是针对非运营提出的需求对其的影响力，如果一个功能或bug类是由运营提出的，大情景有不相同！
　　这又会有两种情况，区分点在于运营的关注度：
　　A类：关注度高，比如要配合某个活动或场景提出的功能，喵甚至会迫不及待的参与到测试和验收的环节，以便有充足的时间做运营相关准备
　　B类：主要是收集到的BUG和优化类意见，说运营不关注也非，主要是喵们抛出各类问题后处于“记忆弱区”，在没有遇到提出问题的相应场景前，基本不会再次提出。
　　针对A类，给予运营更多的参与感，针对B类，我的应对措施是：产品问题记忆表
　　这是我在12。23收集的部分需求，在N次需求表迭代后，将字段分为以下维度：日期、提交者、类型、紧急度、商业价值、描述、场景、可能原因、是否满足、方案、完成时间、问题、状态。
　　这些应该根据每个公司不同的情况进行字段的增加或减少，很多公司这份表格是直接由需求提出者填写的，有的是以卡片格式，有的则是通过邮件，方式不限，请找到最合适自己公司的操作方式。
　　做到记录这一步还没有结束，最重要的是跟踪需求情况和反馈。若需求满足，你就是这个需求的项目经理，你需要负责跟踪，需求因果后也需要通知喵们验收和接受反馈意见（在一个阶段后可增加“需求满意度”）
　　若需求无法满足，则需要给予对方不满足的原因或者其他说明。
　　第三点，故事描述
　　故事描述起先是产品经理针对技术的一种功能说明方式，因为思维方式的不同，普通的产品描述技术可能无法理解，那么就把他们带入场景中，以用户的视角去发现问题和提出解决方案。
　　这一点同样适合产品运营
　　故事描述的接受度和理解度远超其他的描述方式，因此PM需要成为一个“有故事的人”。
　　以上三点其实都是个人在实际场景中遇到的问题解决方式，由于在旅行，可能描述还不到位，观点也更多的是针对小型或创业企业，成熟企业已有了规范的流程，运营也具备能力和经验，所以不需要更多的担忧，而我们更多的是需要灵活，我见过有公司为了敏捷开发甚至抛弃了产品原型和PRD文档，除了团队更多的都是产品经理牵头的沟通。
　　不同企业的问题也会有不同的放大缩小，千万不要简单的套用其他团队的沟通方式。
　　讲人话，没那么玄乎！讲的是人、情、理，PM除了做好产品设计者和负责人，更是整个企业组织的衔接者、驱动器。还需要更多的打开、放低，因为你是整个组织的中心。
　　记住，PM无处不在！