作为一个初入产品行业的新人，要怎样才能快速入行，并且实现健康地成长？或许你需要避开一些错误的工作方法。这篇文章里，作者就总结了产品经理应该避开的“坑”与职场环境中可用的一些工作方法，一起来看。

最近在做产品新人成长的复盘和思考，发现不管是校招生还是工作一两年的初级产品经理，在做产品的过程中或多或少会有一些错误的成长路径。

有些人比较“幸运”，能够通过他人的引导或自我的调整，快速从错误的道路上切换回来，但还有些人可能并不自知，仍旧在错误的道路上前行。这其实也可以解释清楚为什么当下互联网圈存在了大量的初级/低阶产品经理，日复一日的做着执行的工作。

回到这个问题的根源，可能是因为产品经理这个行业并非一个标准化的学科，所有进入这个行业的人可能都是基于古早时期产品前辈们分享的经验和入行后在行业里的“摸爬滚打”。

优秀的产品经理有很多，但如果仔细研究优秀的产品经理的成长会发现，每个人成功的方法千差万别，每个成功的产品经理都有自己的“方法论”（“成功”的产品经理都喜欢写书，当然有些书值得读，有些书需要去辩证的看待）。

方法论不可100%复制，究其原因，每个产品经理的成长经历和操盘产品的时期是不一样的，作为一个初入产品行业的人，你很难直接对齐行业内的大佬，比如百度的第一个产品经理俞军、比如微信的第一个产品经理张小龙。

那么如何能够快速入行，并且能够在相对健康的成长路径上成长？

在笔者看来，借鉴查理芒格的一个思维方式：逆向思维。“如果我能知道我将在哪里死去，那么我就永远不去那个地方”。

在过往一段时间的工作过程中，接触到了很多产品新人（应届毕业生或刚入职场一两年的产品新人甚至包括一些年限比较长的产品老人），在产品实践中发现了一些错误的工作方法。

也许没有办法穷举出来所有优秀产品经理必须具备的品质，但是通过不断穷举产品经理不应该做以及应该如何做，或许就不会成长的太差。

一、执行力不是“你说我干”

产品新人往往在加入一个团队后做的产品工作都是偏执行的工作，说到执行第一个感官可能就是按照他人吩咐去做就好了，不需要动脑子，无外乎是按照既定的内容变现就好了。

但是往往带有这样的思维方式，都不一定能把事情“执行好”。从执行力的落地上来拆解，可能会分为几个环节：是什么？为什么？怎么做？结果如何？

是什么？

第一步很关键，可能你是一个新人不懂产品，也可能你刚去一家新的公司不懂业务。这个时候你的上级可能会交给你一些事情去做，能不能做明白关键就在这一步。不要怕问，要问明白需要你执行的是什么事情，尽可能对要做的事情了解清楚前因后果，这样才能真的理解要执行什么？

很多时候，一个事情不达预期都源于没有理解要执行什么。为什么会出现这样的情况？因为不敢问，怕问的太多让别人觉得自己不懂影响别人的评价。

也许向你下发任务的人因为各种各样的原因没有和你介绍清楚背景，但是作为执行者要主动去问，要敢问，直到自己真的明白事情的背景，明白要做一个什么样的事情。

为什么？

知道要做什么了之后，就要再继续去问下一个问题，为什么要做这件事情。为什么背后一般都会是不做会怎样，会有什么样的后果。了解了为什么才能知道这件事情的紧急重要程度，以及会影响后面的怎么做。

怎么做？

一般情况下，对于新人来说都不需要自己去思考怎么做，更多的是在拿到一个任务的时候就对应了一个做的方法、步骤或者流程，只需要按照上述的内容去做就好了。但是这样真的是对的么？

上述的结论成立的前提假设是分配给你任务的人的方法一定是正确的，否则你按照既定的方式去执行就会出现问题。这个前提假设一定一直成立么？不一定，所以这就需要你具备一定的思考能力，甚至一定程度上，在了解了是什么、为什么之后，能够结合自己的理解去思考怎么做。

结果如何？

所谓结果如何会分两个部分，一个部分是你执行过程中遇到了卡点，执行不下去了，要快速反馈执行过程中遇到的问题，通过借助外部的理解保证事情的推进。另一个部分是执行完成之后，需要收集结果，并对结果进行反馈，并能够结合结果对当次的执行进行效果评估，甚至知道下一次怎么做。

执行不是单纯的你说我干，学会提问、学会思考、学会反馈。

二、不做需求的传递者

很多时候，在互联网圈里说产品经理是在做什么，都会比喻产品经理就是需求的搬运工，把用户（可能是C端用户也可能是B端用户）的需求搬运给研发，让研发通过代码的方式满足。

搬运工这个词在笔者看来并不恰当，甚至有点贬义的含义在其中。作为产品经理，无论是C端产品还是B端产品，都是挖掘用户的痛点并设计通用化的产品解决方案，交由研发团队进行实现。

我们以中台产品经理的需求变现为例，中台产品经理往往会对接外部业务团队/业务团队产品经理的需求，错误的做法或者说方式是，外部团队提交了一个A需求，需要实现一个什么样的功能。那么承接这个需求的产品就把A需求整理成一个需求文档参与需求评审，但是在需求评审上被其他产品、研发问到一些细节问题的时候变成了一问三不知。

究其背后的本质原因就是在做需求的传递者，单纯做信息的传递而不是信息的理解、再加工。这种场景在日常的需求评审过程中非常常见，尤其容易出现在一些初级产品经理身上。

借用麦肯锡内部常用的分析框架，也是芭芭拉的金字塔原理一书中的一个万能框架SCQA；在产品需求变现上也同样适用：现状是什么？冲突是什么（如果这个需求无法满足会有什么后果？）？要解决什么样的问题？解决方案是什么？

现状是什么？

这个问题要问的是提出需求的人对于现状的理解（当然也包括你自己，如果这个需求是你自己发现并提出的，也要想别人解答这个问题，讲清楚现状）。也可以理解为需求的背景是什么。

同时，现状是什么还要回答一个问题，例如一个外部团队向你提了一个需求，说你当前负责的产品模块不满足一个场景，那么你也要清楚并了解你负责的产品模块的现状，这有助于你去理解为什么不满足。

冲突是什么？

简单来说，所谓的冲突就是面对一个需求，如果你什么都不做会有什么问题？冲突能够帮助产品判断一个需求的真伪。当了解完现状之后，再去评估这个需求不做，会有什么结果。对于一些可有可无的需求或者不是需求的需求，那么冲突可能就是没有冲突。同时评估冲突的过程也是对需求优先级和重要程度的评估。

要解决什么样的问题？

到了这一步，其实就是对背景、问题的深度剖析，找到需求背后的本质问题是什么。也是最近必要热的概念：第一性原理。做事情要挖掘到事物的本质，从本质出发去找到问题是什么，从而才能更好的找到解决方案。

解决方案是什么？

挖掘到本质问题之后，就能够结合问题去设计产品方案了，具体的方案设计就不是本文重点探讨的问题了。

这套万能框架可以应用的场景非常多，可以在需求沟通上应用、可以在需求评审上应用、可以在分析问题上应用，学会使用SCQA这个框架可以很大效率上提升你的能力。

三、带着“答案”提问题

作为一个新人，经常会遇到一些自己不知道如何决策的问题。这很正常，因为做决策这件事本身就是一个高阶产品经理才需要具备的能力之一，对于新人来说是有一定难度的。那么在遇到一个问题不知道如何解决的时候，往往会求助于其他人。

在求助的过程中，不是单纯的把问题抛出来等着别人给你答案，这可能是最初级的方式，这个方式可以解决你的问题，但是没有办法帮助你成长。

更好的一种方式是带着答案题问题，什么叫带着答案提问题？这里给出一个相同通用化的提问方式：

问题是什么？我的答案是什么？你有什么更好的答案？

例如：

我现在遇到一个问题，这个问题是XXXXX；

针对这个问题，我的思考是XXXXX，我觉得应该通过XXXXX来解决，但是我不确定我的这个方案对不对；

你帮我看看我的方案，或者有没有什么其他更好的解决方案呢？

我们都知道一个谚语：授人以鱼不如授人以渔。在提问题这个场景下也是如此，带着答案去提问题，不是单纯的要鱼，而是学渔。因为在你给出答案的过程中，已经在思考了。同时在别人提供新的或者说更好的答案的时候，你可以和你的答案进行比较，找到你的不足。在思考、比较的过程中，就是学渔的过程。

鱼可以解决问题，渔可以帮助你成长！

四、搭建你自己的方法论

方法论可以说是一个玄学，由于产品经理这个职业并非标准化的学科，所以每个产品经理都会有自己的方法论。

在笔者面试的过程中，每当看到有面试者在简历中提到自己具备产品经理方法论的时候，都会好奇的问一个问题：你的产品方法论是什么？

这个问题没有标准的答案，不能说谁说的一定对谁说的一定错。在笔者看来，所谓的产品方法论，更接地气的定义是你有一套可以复用的做产品的流程。这个流程能够帮助你做不同的需求、不同的产品、甚至不同业务/不同领域。

方法论超脱了你所做的业务，超过了你所在的领域。比如你现在做的是电商业务，你做的是订单产品。但是方法论能够帮助你快速切换到内容业务，切换到前端产品。

如果这么一比喻，方法论好像又变得抽象了，变得形而上了。那么我们还是回归到接地气上，简单说几点笔者自己的理解，在方法论的搭建上，其实更多是在你将日常的产品实践中做事情屡试不爽的方法找出来，并将它变成你在操盘一个产品全生命周期过程中的各个环节。

举个例子来说，我们上面提到的执行的方法（是什么？为什么？怎么做？结果如何？）、提问题的方法（问题是什么？我的答案是什么？你有什么更好的答案？）、做需求的方法（SCQA）。

这些就是我的方法论中的一部分，这些方法能够帮助我解决我在做产品过程中某一个环节的某一个问题，同时在使用这个方法的过程中还能够通过实践反向帮助我成长。当我具备操盘一个产品全生命周期各个环节的解决问题的方法的时候，我的方法论也就初步建成了。

方法论不是一个固定不变的东西，它是通用的、是可以不断成长的。最快速学习方法论的过程就是不断学习，可以和你身边有经验的人学、可以和成功产品经理写的书中学。但是谨记，别人的方法永远是别人的方法，只有理解并通过自己亲自实践，才能真正转化成你自己的。

写在最后，回归到本文开头提到的一个观点，产品经理的门槛很低，但天花板很高。笔者有一个开玩笑但是也很真实的观点：《人人都是产品经理》这本书让很多人入了行，也害了很多人入了行。与其说人人都是产品经理，不如说人人都可以是产品经理。“可以”解释了为什么目前行业内存在大量的初级产品经理，而高阶产品经理还是凤毛麟角。

产品经理需要不断的成长，这个成长更多是从自身发起的主动成长。实践的复盘与思考，通过外部知识的获取，可以是读书、学案例和高阶产品经理交流等等。

入行仅仅是开始，甚至说你认为的入行并不是真的入行。如何成为优秀的产品经理，有很长的路要走，对于年轻的产品新人：请保持一颗虔诚的心，打好产品的基本功。不是日常的工作就是在成长，要学会主动成长，才能在这个行业走的更高、更远。