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