在产品的小白阶段，必须经过——产品之坑、业务之坑、开发之坑、被甩之坑,的四个坑，可谓是致命坑！那么，我们该如何自救呢？
新人刚进入产品线或者公司的时候，接手别人的产品是很常见的。很少有产品给你从头开始的机会，所以难免要做一些系统运维，对接零工，上下跑腿。突然，产品经理走了。这个时候，机会来了，激动的时候忍不住叹气。作为新手，我要承担整个产品线。难度简直就是空手拿白刃！
刚开始是偶然听说产品经理这个职位的。我一工作就能成为经理。多么吸引人的职位啊！
所以来吧
我在一家S厂工作，和老员工Q一起做一些产品工作，突然老Q换了工作，他搭建的产品线落在我头上。只是学习如何使用产品就要对产品线负责。在你手里有两把刷子之前，你会在生产线上被烤熟。前人留坑，后人填坑。一会儿着急，一会儿踮着脚，一不留神就掉坑里了！
“一旦进入一个产品，它就像大海一样深，从此你的生活充满了坑”。自从你进入产品经理领域，你的职业生涯就一直处于危险之中，尤其是接手上一个产品传下来的产品线。
从我个人的角度来说，产品小白必须通过——产品之坑、业务之坑、开发之坑、被甩之坑,的四个坑，可以说是致命的！
除此之外，产品小白还有一个很大的尴尬——被喷丢脸，躲不过！如果看产品经理能走多远，就看你填坑的能力了！
# #四个“坑”，一个“屈辱”
### 1\.产品坑
在你完全熟悉一个产品之前，对产品进行改造和设计绝对是一件有风险的事情。在填你个人认为的坑的过程中，你在悄悄地给自己挖一个坑。
当你来到一家新公司，接手一条产品线时，大多数产品经理作为第一步所做的基础工作就是对原有产品进行修补，修复可见的漏洞、bug和设计缺陷。基本上需要一两个月的时间来填补前辈留下的漏洞。
但是，在开始优化这条产品线之前，我们必须区分主要的流程业务功能和非主流的流程业务功能。对于非主流的流程功能，我们可以大胆优化，因为功能关联点和重要性都比较低，基本上优化每个逻辑都不会有很大的业务影响。
如果是主流程的业务功能节点的优化，就要格外小心了。主流程的业务功能节点的逻辑基本上和其他很多关键节点都有关系，不言而喻。如果在优化过程中出现更大的漏洞，就会造成重大事故。
对于产品来说，保证现有产品的稳定性和准确性也是产品所有者的重要责任。因此，在设计主流程业务功能的优化和修改时，必须对产品主流程和检查逻辑有深刻的熟悉。我们可以依靠visio和mindmaner来梳理自己的逻辑，并通过前人留下的产品文档来找出产品线中的漏洞。
另外，从产品业务出发，产品成了现状，肯定有原因。熟悉业务可以帮助你更好地了解产品的问题，优化主干道也要遵循小优化。有些产品在新官上任时会进行大幅度优化，往往会导致无法挽回的产品故障。记住，不要轻易改变和调整自己不熟悉的逻辑和产品解决方案；
### 2\.商业陷阱
它是产品的直接需求端，这里的产品业务分为两类：B端用户和C端用户。他们之间业务需求的沟通方式会有所不同。对于C端用户来说，他们是面向消费者的，需要通过研究分析了解用户需求。b端是面向业务的，比较直接。找一些商业人士，直接面对面的谈他们的需求。
这里主要说一下B端产品的业务坑。我们只是接手产品，按照正常的思维去做对业务有深刻理解的产品会更方便。但是，在与商家沟通的过程中，商家似乎对目前的产品了如指掌。其实我自己的需求也只是局限于目前的业务，并没有从发展的角度去看待需求的合理性。我现在只需要满足我想要的。
产品经理的职责是检查和整理业务需求，并整理出产品应该优化的领域。当然，对于业务来说，需求是大是小，只要是功能点和优化，都会被认为是对自身最重要的。
从业务人员的角度来看，最紧急的事情才是最重要的事情。但是，从产品的角度来看，从产品开发的长远角度来看，产品开发的前瞻性功能才是最重要的。所以要结合产品的发展来满足业务的需求，满足业务的迫切需求，不要忘记作为产品经理对产品的掌控，不要被眼前的迫切需求蒙蔽了双眼。
这是一个商业坑。学会在业务沟通过程中积极引导业务思维，从产品的长远角度优化产品。
有时，在与业务沟通的过程中，有时业务无法清晰地描述自己的需求。业务一黑，产品就会从黑中找出业务的真正需求。这个时候坑就出来了，业务口径有时候和开发商、设计师不一样。
举个简单的例子，价格分为三种：净价(不含定期扣分和税率)、底价(不含定期扣分)和报价(不含税率)。
商家真正的需求是底价，商家会说：我要的价格是去掉一切后的价格，是净价，是根据对产品的了解，定期扣点，税率。
全去掉，然后再三确认后，产品认定就是净价，然后产品方案设计、开发、测试，上线使用。这时候，业务大叫：这根本不是我想要的价格，产品经理就很迷茫，你明明说的就是净价呀，就对产品需求到开发进行复盘，核对价格明细的时候才发现，业务口中的原来是底价呀！
所以此为二坑，和业务谈需求的时候，一定要对每一个口径名词进行核实，不然，做出来的产品和业务的真正需求会有很大的差异的。
### 3\. 开发之坑
产品经理是业务和开发之间的翻译机，一边用业务的语言和业务沟通需求，然后将需求翻译成产品文档，另一边再用开发听得懂的方式和技术人员沟通对接，产品文档翻译的好不好，就要看产品经理对需求的理解程度深不深，对现有的产品逻辑熟不熟。
作为新的产品经理，产品文档方面经常吃亏。
* 一方面开发测试总能针对文字描述、功能逻辑等提出各种各样的漏洞，受益于中华文化博大精深，也是因为产品经验不足，导致同一个产品文档在产品、开发和测试产生了三种不同版本的产品实现逻辑；
* 另一方面，产品方案要落地于技术开发，产品方案总会出现和技术方案相矛盾的地方，这就需要产品或多或少的了解下技术方案的实现。
特别是面对多系统技术人员开发对接，更要稳重心细，系统做到端到端技术开发的无缝对接，比如：产品方案设计到两个不同的系统时，如从A系统下发B系统的对接接口，由于下发系统不熟悉被下发的系统的数据表结构，数据表中一个字段的字段名有差异，两个系统之间的开发人员也没有对双方的数据结构进行仔细的对接，直接导致上线后数据下发失败，产品无法使用。
因此，产品对接多系统开发，一定要对接细化到每一个字段这样粒度的细节。
每一次产品的上线，产品经理最怕的就是技术人员写BUG，有事没事写俩BUG，迎之而来的就是产品经理陪着技术进行通宵的紧急发布，上线前一定要多祈祷，千万别写BUG，要是影响到主流程的BUG，估计就要定责重大事故的。
### 4\. 被甩之坑
产品经常自黑“CAO”，这是什么岗位？
首席行政官、首席算法官还是会计总监，错！是Chief Apologize Officer-
首席背锅官，产品经常被甩锅，因此，背锅是常事，除了要学会接锅，还要能给顺势把锅甩出去。
记得初做产品经理，一位老前辈就告诉我，产品经理第一能力就是撕逼，自从做了产品经理后，不是在被甩锅的路上，就是锅已经在自己头上了。
* 这方面吃了不少亏，和技术对接，产品文档写的不专业；
* 和测试对接，被吐槽根本看不懂逻辑，测试案例都没办法写；
* 被业务吐槽，这根本不是我想要的需求；
* 和其他系统对接，莫名其妙的产品需求被甩了的很多杂七杂八的功能点，实现不了就被其他系统报了风险点，只能默默的吞下。
人在江湖飘，哪能不接锅，接顺手了就习惯了。
### 5\. 被喷之辱
作为一个产品小白，在刚进入一家新公司里，最尴尬的事情还是面对开发和测试，开发和测试对系统的每一段逻辑，每一个细节都了如指掌，新产品经理对产品的优化总会被开发和测试狂喷，本来产品是技术和开发的上游，结果变成了技术和测试指导产品进行产品设计和优化。
这是新产品的必经之路，经过半年的磨合，产品经理就能慢慢避免被技术测试吐槽。
## 入坑后如何自救？
产品经理是一群理想主义者，但是要站在现实的土地上，面对大坑，求生欲望强烈下的产品小白又该如何自救？
### 1\. 找直属领导求救
产品经理在产品部门里，自己的领导一般不直接负责产品工作，而是负责部门内外协调。刚入职，对内分工，对外沟通，总会遇到各种槛，各种各样的坑，自己解决不了，领导就是你的护盾，总能帮你挡着。
所以在刚进入产品工作，搬领导救兵是一件常事，我们一起看看领导的作用吧：
* 重大产品方案拍板： 涉及到产品改动范围和影响范围巨大，产品因为视角问题，无法顾及周全，有时候涉及到外系统，关键产品方案更需要领导来拍板，领导拍板之后，就可以放心大胆的去做，产品风险领导就会给自己承担一部分的。
* 产品全生命周期协调： 产品需求由产品经理沟通，但是涉及部门内部排期、开发及测试，产品经理和相关人进行沟通，由于本身非项目经理，很多问题在产品经理层面难以协调，这就要上升到领导层面去协调，领导出面往往比自己去沟通协调更有力度。
* 帮忙“撕逼”： 产品方案确定之前，特别是大的产品项目，涉及范围广、参与人数多，职责分工、产品架构等问题，就要和很多项目干系人进行周旋，尽可能争取更多的资源和更核心的产品功能，领导毕竟是领导，首先经验足，然后在公司资历老，周旋起来那是有文化的老流氓，新人根本不是对手。
说到这，作为新的产品经理，学会向上管理，学会求助领导，用好你的领导也能帮你省很多力气；
### 2\. 学会拒绝
面对业务提需求，作为产品经理对需求的态度肯定是抱着怀疑的态度去谈，这是不是业务的需求呢，是伪需求还是真需求，需求是否合理，产品经理把好这一关，可以选择接和不接。不是自己的需求不要接，不是业务真正的需求不要接，伪需求不要接，不要为业务考虑，要站在业务的角度思考这个需求到底要不要做。
通过合理的拒绝，不但能够投入资源做真正的需求，而且也不会给自己增加徒劳的工作量。如果说自己手上产品工作多，可以拒绝一部分需求，交给别人来做，把有限的时间放在已经在做的产品工作上。另外无法拒绝的工作，可以选择把需求接下来，短期内不考虑做产品方案，等有时间了再去为这个需求做产品方案。
学会拒绝首先能让自己有时间思考事情的优先级，另外，也可以集中精力让产品方案考虑的更周到。因此，作为产品新人，不要怕拒绝，拒绝是更好的资源利用，要学会拒绝。
### 3\. 提升工作效率
都说做技术的天天熬夜加班，但是自从当了产品经理，发现每天走的最晚的是产品经理，会开的最多的还是产品经理，和同事打交道最多的还是产品经理，可不比技术熬夜熬的少，还容易被各种琐事打断，想安安心心的写份PRD都难，如何提升自己的效率呢？
刚入职的新人面对不同的角色肯定是忙的手忙脚乱，一天下来，累死累活，仔细想一下，啥都没干，时间都去哪了？还没好好写需求就不见了。
因此提升效率的方式首要方法就是将碎片化时间尽量整合成完整时间块，然后对手上的工作进行优先级的排序。优先处理重要而有紧急的事情，然后找个空闲的时间集中处理下林散的琐事。
最后，我们在看一下，作为产品经理，输出的最终成果就是产品文档，看似主要工作就是写产品文档。
我本人一开始也是这么认为的，天天望着电脑屏幕，“需求文档”四个大字挂在屏幕上，每一句话就像蹦豆子似的，一个个往外蹦，比写作文还难，几乎60%的时间放在了写文字上面。
后来，慢慢明白了写文档只会占到工作的10%，磨刀不误砍柴功，先梳理逻辑，然后进行PRD编写，写只是把前期理出来的思绪表达出来。
因此，后面的就开始愁是怎么设计方案，对我来说，这是一个很大的改变，提高效率的同时也把质量提升了。
### 4\. 主动沟通请教
产品经理在很多人眼里被恨之入骨，打死产品经理的调侃已经习以为常了。
在如此恶劣的生存环境下，产品经理的求生欲也是很强的，产品小白在一头雾水下，要多向老员工请教经验，包括产品经验和工作经验，梳理现有产品的逻辑思路也离不开老员工的指导。但是要是问到更细节的产品时，这个时候就要请教技术和测试了，特别是测试，他们会对你的产品逻辑从内到外理的清清楚楚，测试用例那是明明白白的，虚心求教会让你更快的掌握现有的产品。
多找一下现有的业务人员，沟通一下他们的业务现状和需求，产品逻辑可能会有很多无法理解的逻辑，但是配合业务的需求进行理解的话，会很快明白梳理出产品的业务逻辑，业务是产品的原始需求方。
在沟通的过程中，你也会发现现有产品的问题，并支持你一步步进行优化和调整，让产品更符合业务需求，是一位产品经理的直接追求。
做好自己的工作之余，多对自己现有的方案上线后进行
不断的复盘，并和领导（部门经理、产品总监）进行汇报产品上线效果，收集在使用过程中发现的问题，自己往往会因为思维局限性无法发现问题所在。这个时候邀请领导进行复盘，他们站在比自己层面更高的角度看产品，会提出更有建设性的意见和方法；
### 5\. 撕逼能力真的很重要
在公司做产品一段时间后，会发现一个有趣的现象，那些性格温和的产品经理大多发展比较稳定的，一直待在一线做基础产品工作，而那些懂撕逼会撕逼的产品经理，会迎来跨越式发展，不断的提升自己的产品地位。
无论是在与其他产品进行撕逼还是与技术测试撕逼，其实是产品经理的决策和思维论点的表达，在撕逼混战中，不仅展现一个人的能力，还展现一个产品经理本身的价值。代表产品的利益，通过撕逼，不断得到反馈，为自己的成长和未来更有关键决策的撕逼做准备，并在产品关键发展期得到自己方案的落地和实现。
因此，产品的成功与失败和产品经理的思维与能力也有很大的关系。产品经为了实现项目成功和更好的目标，撕逼能力变得越来越重要。
在遇到重大产品事故或者矛盾纠纷时，通过几回合的撕逼，也可以让责任鉴定更加清晰明了，在保护好自己的基础上，让领导及同事认清问题的关键点。否则，产品经理就是“CAO”，无论是不是产品经理的责任，都会被别人甩锅。产品经理就是所有人员和产品的连接器，出了任何问题都脱不了干系，只有在认清问题的基础上，理性撕逼，才能避免背黑锅。
### 6\. 产品文档之重
产品经理干啥呢，天天写PRD，去掉后面两个字母，就是天天写个“P”。
调侃一下，但是丝毫影响不了产品文档的地位，产品文档是产品经理的重要凭证，一切以产品文档为主，产品文档是产品落地的重要依据，产品方案逻辑是否清晰，文字内容是否简介有条理，产品方案是否符合业务需求，所有的业务需求汇成一份最重要的精华就是产品文档，技术、测试的开发源泉也是这份产品文档。
产品经理承载着很重要的责任，但是正是这份产品文档，也造成了很多产品背锅的负担。技术开发错了，文档有问题，没写明白，开发看不懂……测试没测出来，文档逻辑混乱，读不懂……这可谓是成也萧何，败也萧何。
因此，产品经理对文档的要求也是对自己的要求要极高，任何问题皆以此份文档为准，也就是传说中的一切解释权归文档所有。
## 个人总结
产品小白面对白刃不用怕，最多被砍几刀就能接得住了，在被坑的路上不断的爬出来，用产品的思维对产品工作进行复盘，总结经验和教训，以下是我的一点点经验：
* 优先级：事情排优先级，通过重要性和紧急性安排自己的工作；事情排优先级，通过重要性和紧急性安排自己的工作；
* 项目管理：产品经理也要懂得项目管理，具有项目管理意识；
* 习惯：养成通过思维导图、visio图及文档梳理产品逻辑的习惯；
* 时间：注重时间碎片整合，提升工作效率；
* 姿态：放低姿态，多与产品、技术、测试和业务请教沟通；
* 记录：方案及会议沟通结果留有底档，包括邮件、纪要及文件等，关键时刻可以派上用场，此处只可意会，不可言传。
本文由 @产品包工头 原创发布于人人都是产品经理，未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
