产品经理最常挖的坑及解决方案

　　在工作中，挖坑也成了产品经理所具备的基本素养之一，所谓“不挖坑，不产品”！毕竟，这是每个产品经理都会存在的，但具体的都会有哪些坑，以及如何更好的规避呢？
　　产品经理工作中常见问题
　　1。成了纯粹的传话筒
　　可能是源于对产品经理这一工作神圣不可侵犯的误解，在刚接触产品经理工作之初，急于有实际的需求来执行。当接受到其他部门的需求后，内心深处想着终于要干一出天翻地覆的大事来了。
　　于是乎，火急火燎完全不经过大脑的来直接执行，压根不去分析功能本身背后涉及的业务、逻辑、什么角色在使用等等。
　　最终，成了一个纯粹的毫无主张的会话筒。
　　2。重功能轻逻辑
　　由于对公司核心业务缺乏认识和了解，在接受到需求时，往往侧重于需求本身对外的表现形式，比如：视觉、交互这些，但往往忽略了最为核心的需求本身用来解决怎样的问题。
　　在这此情况下，往往把页面做得天花乱坠且内心对自己佩服的五体投地，但上线后却发现用户压根不买账。
　　3。有评审无跟进
　　产品经理都知道会有需求评审，拉上一大帮人开会开会开会。但貌似需求评审以后，所有的事情就已经结束了。后续的更细致的跟进呀优化呀之类的，和自己完全没关系一样，最终导致研发过程中存在大量的问题。
　　4。上线后就撒手不管了
　　终于上线了，终于上线了，终于上线了。感觉上线了就解脱了一样，再也不愿回头正眼看一下自己做的东西，有BUG也不管直接抛给研发人员，真是应了一句老话：“分手了就别再找我”。
　　产品经理应该如何做，才能输出更好的产品
　　1。接到需求后，搞清楚来龙去脉
　　当产品经理接到需求后，请列出以下几个问题点，并找提需求的同事进行沟通确认，确认无误后再内部进行沟通确认：
　　此需求是基于怎样的背景提的核心的问题点是什么；
　　原来的解决方案是怎样的，原来的解决方案存在什么样的问题；
　　新的解决方案是怎样的，新的解决方案是否能够解决上述的问题；如果不能，是否有其他的解决方案；如果没有好的解决方案，不建议操作；
　　如果确认可行，那么此功能是基于原有系统哪个流程的，这个流程是谁操作的，操作人对此的使用感受是怎样的；
　　除此之外，还关联哪些流程，所关联的流程是否涉及到其他同事操作，如果是那么他们对此的使用感受是怎样的；
　　找每一个关联人确认每一个具体的细项，如果涉及到资料、那么要确认都需要哪些资料、资料哪儿来到哪儿去，并站在整个系统的角度上来考虑此功能如何更好的实现功能；
　　同时，这里也有可能涉及公司之外的需求，就更需要确认需求在传达过程中的精准性。
　　2。确认需求后，画一个清晰的流程图
　　需求确认后，针对需求做一个清晰的流程图，有几个核心：
　　基础的全局流程图；
　　所变更的需求具体都在流程中的哪一些节点上会有体现，具体体现的内容都有哪些；
　　站在操作人的视角上再做一个基于操作人的流程图，比如我是风控，那么我的流程就是收到审批的单审批，然后流转到下一个流程；
　　流程中存在哪些潜在的异常情况，这些异常的情况出现的话要如何处理。
　　3。评审并全程跟进
　　在需求评审后，还需要重点做到以下几点：
　　产品经理与研发人员在评审之外，进行一对一的更为细节的沟通，包括每一个正常或异常的流程，以及所涉及的每一个更细微的细节，并从中确认需求及实现方案；
　　在研发周期内，每一天都需要进行一对一的沟通和确认，了解当前研发过程中存在的问题并沟通解决；
　　提测试后，产品经理在每一个测试周期均需第一时间进入体验，每个周期至少要测试3次以上；
　　上线后，第一时间在正式环境进行操作和体验，确保线下也无误；
　　提交至需求方进行体验，并收集体验过程中存在的问题；
　　在对接群里，收集所有使用者所反馈的问题，以周为单位进行输出至研发侧；
　　研发同事以周为单位对所反馈的问题进行内部的梳理，并提出后续过程中好的解决方案；
　　依次循环。
　　4。以周为单位收集并沟通存在的问题
　　在上述的基础上，进行定期的问题沟通和讨论，形成良好的正向解决途径：
　　产品经理以周为单位收集所负责的问题，所有的问题，并汇总输出至研发团队；
　　研发团队在收到汇总后，内部先进行沟通和讨论，确认后续的优化措施；
　　产品研发团队集中进行问题的沟通，确保后续产品质量的提升。
　　所述一切，均为产品经理最为基础的素养。很多人可能不屑一顾，不过正如我《瞧不起的基本功，筑不起的摩天楼》里所写的：
　　咱不过是个普通人罢了，还是做好手头上的事情。
　　最好，如何做好呢？
　　无非是数量上：日复一日的极度无聊的重复；思维上：日复一日的极度无聊的思考。
　　最后以《失控》第三章有心智的机器第三小节众愚成智中的一段话结束：
　　先做简单的事，学会准确无误地做简单的事。在简单任务的成果之上添加新的活动层次，不要改变简单事物，让新层次像简单层次那样准确无误地工作。重复以上步骤，无限类推。