编辑导语：职场产品新人在刚进入公司时，会遇到很多问题，刚刚脱离学校完全进入社会，心态还没有完全转变，对于工作的方法论也没有建立；本文作者分享了关于产品新人入职的三要素，我们一起来学习一下。

很多学弟学妹由于缺乏前期的大量实习经验，在校招进入公司成为产品岗的一员后会出现诸多的不适应，感觉自己的想法被约束、感觉自己的行为被约束、感觉大家都很难说话、感觉人情味比较淡；而这一些情况其实的我们的社会角色定位上没有及时的进行扭转，也就是还保持在所谓的“学生思维”。

说到底，所谓的“学生思维”和“职场思维”最大的区别在于对待事情的导向性上，学校里多为“兴趣导向”，公司里多为“利益导向”。

可能有的人会说：“我在学校里也见过很多唯利是图的人啊？”其实这和利益导向是两个概念，学校里的利益多是因为你本身对某件事物感兴趣；而在不断接触和发展这件事物的过程中发现其中的利益点或利益链条，从而想方设法的在这个过程中获得其中的利益；而在企业的利益导向多为KPI导向，也就是被迫的以完成某项或某些任务为目的的导向，刨根究底是一种“基本生存”的需要。

总结下来就是：学校——因为兴趣去争夺；社会——因为生存去抢夺。

一、执行力

上面区分完学校和社会导向性的不同后，我们就很容易理解“执行力”为什么对于新人产品来说的重中之重。

学校里的产品团队或工作室之类的，其实更像是兴趣小组的存在，大家进行思维碰撞的前提是你们这拨人都自发性的对这个共同的目标感兴趣，而自发性目标不同的人很难融入一个团队里。

而在企业中的团队里，虽然看上去一个小组、一个部门的目标也是一样的；但是其实大家的自发性目标都是钱，kpi的目标只是获得钱的一个途径罢了。

而对小组、部门领导来说目标也是一样的，保证整个小组、部门的kpi完成情况是保证团队和自己利益的最有效途径；所以一旦你开始参与计算整个团队的kpi时，你的一切执行情况都会影响整个团队的“基本生存”。

于是执行力在我看来是新人产品想要生存下来的最基本能力，而这项基本能力的“水准”高低其实决定了你前期的“同事印象”和“领导印象”。

为什么我这里会用到打双引号的“水准”，后面我会解释。

对于执行力，以我以前的学校里的团队管理经验和现在作为企业基层员工的执行经验来看，可以分为几层次：

1）一块皮癣

这一类是属于因为心态、思维等多方面调整不合理，而导致执行效果差强人意，甚至有时候还会出现“帮倒忙”的情况。

虽然这么说可能不太人性化，但是这类人在执行力方面确实对团队是有害的，如果在团队有足够“人情味”和“资源”的情况下可能会去帮助和引导这块“皮癣”慢慢治愈，但是也有很大的可能性是被“快刀斩乱麻”的结束在试用期。

2）一条死鱼

为什么说是一条死鱼呢？因为水里的死鱼——戳一下动一下。

这一类执行力的人一般是领导有任务布置下来了就去做，按照时间、质量要求做完就完事，不会去主动寻求接触新的工作任务，相对来说提升很慢。

这一类人其实对于很多公司来说是中坚力量，或者换句话说就是不争不抢的老油条，精通各种摸鱼技巧但是安排的工作做出来产出是很不错的，只不过因为某些原因没有了拼搏动力。

3）一愣头青

这一类在普通的执行层来说是属于执行力很强的一类人，对于安排下的工作能够高效完成，并且喜欢“没事找事”去寻求额外的工作；而这一类人比较容易被一些老油条冠上一个不太好的名词“奋斗逼”，但是对于新人来说这一类的执行力是能够帮助你快速融入公司、快速融入业务、快速获得成长、快速获得领导青睐的最好途径。

哪怕你在新人期的产出质量不是太高、不太稳定，但是新人嘛，都能理解和包容，更看重的是你努力学习的热情和旺盛精力。

4）急人之急

这一类一般需要多年行业、职业经验的积累，能达到这个程度执行力的人；一般在处理问题上都有自己的一套方法论，来指导自己某个问题的处理能够尽善尽美的做到闭环。

举个例子：领导需要你设计一个弹窗，你应该考虑到这个弹窗它需要承载的内容是什么？和原页面有没有关联？内容量太大会不会触及使用者的恐惧边界？是否需要触及这个边界来逼迫使用者快速结束窗体？是否需要屏蔽两侧点击来减少误触？是否需要考虑内容填写与提交的交互方式？是否需要考虑考虑颜色导引和提示？弹窗的大小和位置是否能改变使用者的心理状态？应该的弹窗、新页面还是有其他更好的呈现方式？等等…对于产品来说，你能在执行的时候想到愈发多的场景并进行对比分析从而获得一个较好的结果产出，就能做到这个层次的执行力了。

5）大预言家

能够通过一个眼神、一个细微的动作，甚至凭借经验和直接就能想到领导需要什么。

这一类人一般具有很强的同理心和细节观察能力以及非常深厚的行业、岗位经验；这是极少数的一类人，他们总会让自己处于有利的位置，因为这种执行力的存在只有去做事情成果都不会差；一般如果兼具管理能力的话多数是中层管理，没有管理能力的话也会是董秘、总监助理之类的高端执行岗。

而作为应届新人产品来说，在刚刚入职的时候都会有一段皮癣阶段，这段时间的长短全看公司舍不舍得投入资源去引导和培养，只靠新人自己的话短时间很难转变。

所以现在很多公司愿意招收有较长实习经历的毕业生就是因为实习过的毕业生一定程度上已经有了学校到职场的转变，引导培养起来成本低；而真正舍得投入的公司一般来说会给到校招生4-6个月的新人期，甚至是不占部门hc的那种，其中前2个月多以课程培训、团队建设、企业文化、融入感、能力发掘为主。

过早的把应届生作为工具人使用的公司，在新鲜血液的培养上会落后于整个行业，容易出现劝退新人或者直接把新人培养成老油条的情况。

这一类的公司其实对于应届生的友好度比较差，导致应届生离职率偏高、成长速度慢、融入感差、负能量多等情况——这一些负反馈会导致新人产出不达预期，于是容易被部门误以为应届新人难带所以更想要要有经验的短时间能上手并产出的社招成员。

而这样的部门反馈情况在公司看来或许是新人质量较差，从而不断的提升招聘要求希望能获得更优质的应届生源，而这导致的就是与其它公司发生更多的竞争造成招聘成本和用人成本的持续飙升；但是得来的生源还很有可能是一些更舍得投入的公司在评估后放弃的生源，说句不好听的就是美玉的边角料，可能存在着这样那样的隐形瑕疵；但是最根本的问题其实是缺在了对于新人的培养投入上。

对于应届新人产品来说，其实最需要的就是结合以及落地的实际项目为例子，进行系统化高强度的培训，让应届产品活跃的思维、丰富的想象力与前辈的经验和方法论有机的结合形成自己独立体系的种子，在有了这个种子之后再去投入到实际的工作土壤中去孵化去生长。

但是如果真的缺少培养环境的话就只能是靠自己的“计划”能力来不断给自己正反馈来刺激自己的持续学习能力，从而慢慢形成足够强大的自驱力和抗压能力，从而在不断试错中去汲取知识，在亡羊补牢中去寻求突破。

这种摸石头过河成长起来的产品在前期成长速度可能会比较慢，但是在后期会有比系统培训体系下出来的产品有更强的能力与人格魅力；但是半路夭折或者提早形成思维定式而长成歪脖子树的风险也很高。

所以，请各位在毕业选择第一家公司的时候一定要注意了解它对新人培养投入的时间情况，这直接关系到你们度过执行力的皮癣期的时间和体验。

而在度过皮癣期后我建议直接进入愣头青期，这个时期的执行力其实全靠自己憋一口气多熬熬就能达到。

当然，在面对不熟悉的业务的时候由于自身认识范围的原因可能会滑入死鱼期，这个就需要每周复盘来判断自己的产出和kpi对比起来到底是个什么程度。

记住，高投入一定要有高产出，愣头青并不是说一味的去投入去执行，而是可以不必太过掩饰自己的缺点甚至主动暴露出自己的缺陷来让领导发现让同事发现；并且以较长时间的“虚心接受屡教不改”来而起到吸纳足够的改进意见，或者在成为“奋斗逼”的过程中预留出可控的薄弱口来保护自己。

执行力的“水准”高低不止在于“执行”，还在于自我保护；因为你的奋斗其实是在不断侵犯别人的“基本生存”，特别是对于很多存在强制绩效排名的公司来说，所以新人在加强执行力的同时保护号自己非常重要。

至于急人之急这个阶段，当你作为愣头青一两年后突然某天不愣了，就自然而然会达到；至于大预言家的话…看天分吧。

总之，执行力就说这么多。

二、沟通

沟通可以说是产品经理的基础能力之一，其实在我看来对于应届新人产品来说，特别是对于B端产品来说专业沟通可以分为：业务沟通、开发沟通、协调沟通、汇报沟通。

1. 业务沟通

业务沟通算是B端产品经理非常核心的一项沟通能力，要能够以业务方的思维去带入业务中，思考业务流程的合理性，评估流程中可能存在的风险。

在和业务交流过程中要多听取业务方的意见，但是又要能保持主见，否则会被业务方牵着鼻子走，沦为传话筒。

在业务沟通中需要能够把控好合适的度，把控这个度的前提是你对业务的足够熟悉；至少要了解主要流程当初的设计目的、要解决的问题、流程逻辑，这样才能够搭建出大体的业务模型框架，才能够对业务上有整体认知，才能在沟通中听懂业务方说的是什么；最后才能够带入自己的思考与想法，进而保持作为产品经理最基本的“自私自我”。

2. 开发沟通

开发沟通对于有技术背景的同学来说初期沟通是比较顺利的，能够以开发的思维开发的术语去和开发人员进行沟通。但是这也有一个弊端，在不断的沟通中可能会被顺理成章的强化开发属性，过多的去考虑一项功能用什么方式去做才能最节省开发资源，哪些功能做到什么情况的实现就可以用了…这就会导致你慢慢从产品经理的角色上脱离，反而更靠向于项目经理或开发助理，变为了需求的前期处理者，变为了降低开发了解需求成本的工具。而这样就背离了产品经理这个角色“做好产品”的初衷。
对于非技术科班出生的B端应届产品，前期被开发人员特别是主管、项目经理怼的体无完肤是非常正常的一件事。因为你的眼界具有局限性，技术性知识范围与开发的技术性知识范围交集很小，所以容易出现违背原有开发逻辑、没有考虑规避风险、写的需求开发看不懂、面对面沟通完全不在一个频道…而这些情况的出现非常正常，你需要保持住自己的本心，学会调节情绪压力，在被怼时能积极的追问原因或影响，甚至还能反驳出不同的见地。慢慢的积累自己在开发沟通上的专业能力，然后做出一次次趋近无异议的需求，渐渐通过自信和积累培养起自己的话语权后，我相信开发沟通不会再是问题。

3. 协调沟通

协调沟通方面主要用于协调内部矛盾和外部矛盾。

内部矛盾多是因为产品之间相互挤占开发资源而导致的矛盾，如在开发资源有限的前提下，我有一个A需求周三需要上线，而你有一个B需求突然需要加塞，而这个加塞可能导致我的A需求上线时间被延期；那么我肯定想保证我的需求如期上线，你也想要紧急加塞的需求能够快速上线，于是矛盾就此产生。

而对内的协调沟通则能够让我提前的告知部门我的需求紧急程度以及其中存在的风险，当你有需求需要加塞的时候首先会避开我的开发资源；如果实在没有办法需要挤占资源的时候，内部协调沟通也能够通过同事的帮助来快速的简化需求实现复杂度和明确描述明确度，甚至于在评估你的需求紧急性与必要性后大家帮助你挤出一部分开发资源或寻找到外部资源。

外部矛盾多是因为与开发的沟通、领导的沟通、业务部门的沟通等造成的。

与开发的沟通上面说过了，但是有时候产品是需要临时性充当项目经理角色的，所以协调前、后端、app等开发任务和跟进开发进度的事情也会落到产品头上；而这种沟通协调除了前期做好需求评估和任务拆分外，剩下的就只能因地制宜的去熟悉经常沟通的开发组的习惯，慢慢积累经验。

和领导沟通主要会在接受任务、索要资源、工作汇报三个方面。

接受任务前应该先同步好背景，减少因为信息差带来的接受程度差甚至完全听不懂的情况；接受任务时记录好关键的信息节点（如：时间节点，完成目标，达成目的，相关方等），然后根据信息节点快速粗略推测出整个任务框架，然后就可以通过框架找出其中的模糊点和残缺点，及时反问领导获得信息节点补充。

索要资源时一定要拿出一套甚至是多套相对完善的执行方案，阐述方案预期效果及时间、需要什么资源能够达成预期、存在的风险有哪些、打算如何规避风险、需要哪些额外帮助；而这就需要在对产品和业务有一定熟悉度的情况下去尽可能的“穷举”用户场景、业务场景，通过“脑内跑通”来推测出合理性方案和存在的风险。

工作汇报可以说是非常重要的一环，公司都是以成果为导向的，很少关心你在过程中做了什么，更多的是关心你完成了什么、完成质量如何；所以在汇报已完成的任务时应该先说结果，再说结果可以带来什么，再说这个结果规避了哪些风险，再说如果有什么资源的投入可以带来超过多少预期的结果；汇报未能完成的项目时应该先说项目进度情况，再说原定进度，再说什么原因导致的，再说后续补救措施，最后说如果再来一次会通过什么方式去避开现在未完成的风险。

与业务沟通其实是最蛋疼的，对业务流程非常熟悉的专家其实会非常轻松的给你递上罗列好的改进点和改进方案，甚至对一些需要的新功能直接给出成套的解决方案；这就导致产品经理会完全被业务方牵着鼻子走，最后以业务的思维做出了其实并不是太好但是可以适应当时的产品；但是这样做出来的产品局限性强适用性差，可能没两个月市场发生一点波动，甚至仅仅只是因为业务方换了一个领导或使用者就可能导致产品没办法用需要修改或新增功能，最后不断的修改和增量导致臃肿不堪。

而一部分对自己业务逻辑都不清晰的业务方则会带跑偏产品经理，导致以伪需求做出可用性极差或者业务方其实根本不需要的产品；所以和业务部门的沟通最好能够找到一个归口，在多次沟通中找到一个业务熟悉度高且逻辑清晰但是又不是太强势的人作为与你对接的中间人。

业务方的需求首先对接到他那里，他在分析了真实的业务场景和业务需要后再与你对接，这样的对接成本大大降低，做伪需求的可能性也大大降低。

4. 汇报沟通

汇报沟通可以分为对上汇报、对下汇报、交流性汇报等。

对上汇报的话主要就是向领导汇报，上面与领导沟通时的工作汇报已经说过了。

对下汇报简单带过，主要用于思想传达、任务安排、工作总结，根据交流对象和实际场景的不同以强硬、专业、温柔、中肯等方式来表达出想要传递的核心信息、需要达成的目的和周期、能给团队个人带来的利益、需要各位的什么赋能等等。

交流性汇报主要用于团队内部信息同步和可行性、方案评审等；信息同步主要是在每日晨会、周例会上，用于同步需求、项目进度、同步风险、同步需要的支持、分享心得和学习他人案例等。

可行性评审一般是在需求初期来对需求进行可信性的分析，主要从需求真实性、目的达成性、与现在业务/系统冲突性来做考虑，具体可不可行那就得具体情况具体分析了。

方案评审则是对某一需求已经完成了方案，让产品内部或连同开发、UI、业务方等多方一起对该方案进行可落地性、资源消耗、达成预期、可改进点、验收交付标准等进行交流评价审核。

独立的主持一场评审会对应届新人产品的整体能力是一个挑战，前期最好现在内部进行评审后拉着产品同事或领导在评审会上“站台”帮助心理放松、思路引导和必要时候的救场。

三、计划

制定计划主要是基于两个目的：秩序化、阶段化工作任务；缩短反馈周期。

先说秩序化、阶段化工作任务——对于产品经理来说，分析获得的需求多种多样，思考成本、规模大小、紧急程度各不相同；就像我作为泛OA的产品经理有时候同一天会被不同的业务方给到十多个需求，有些需求甚至是一套全新的系统；而像这样的情况我不可能说一次性把所有需求都整理好，哪怕我能整理好开发也不可能说一次就全做出来。

那应该怎么办呢？这时候排期计划就派上用场了——拿到这堆需求后，先进行一个大体上的浏览，判断出各个需求分属于那个业务模块，有没有需求是影响线上主体流程需要紧急处理的，有没有压根就不合理的需求，有没有很小但是不着急的需求，有没有很大但是很着急的需求……然后根据这些判断做一个粗分类和排序后再去找业务方核对具体的方向、边界、细节、周期等等。

如果不能确定的先沟通业务方获得业务方给的优先级后再做评估；如果涉及很庞大或重构或涉及主体流程的需求，我建议转领导进行评估，不要自作主张以避免因为业务不熟悉、产品能力欠缺、经验不足等原因而导致后期崩盘甚至影响线上。

而在评估完成的需求想要对它进行计划就比较容易了，又小又急的需求优先搞它，根据紧急程度甚至可以加塞；较大又紧急的需求优先排期，根据开发量和开发资源的情况来看可以捎带上几个小但是不太着急的需求；又大有急的需求需要仔细和业务方讨论并分析出其中真正紧急的关键节点，然后拆成几个任务甚至几个阶段来做；其他不太着急的需求就先压着，如果真着急的需求业务方是一定会多次催促的，如果过了“冷静期”业务方还没有催促的可能就是当时头脑一热提的伪需求，需要再去找业务方评估是不是真的要做。

当你把需求按照上面的方式梳理出一张带有时间周期的表的时候，你就得到了一张简单的排期计划；根据这个计划再去详细的扩充每个需求的细节，然后评估优先级合理性，最后再去用这个计划去和开发沟通；而优先级对于我来说一般是影响线上业务第一位，涉及到钱的第二位，影响业务方的功能性需求第三位，不是特别急的数据报表第四位，优化和其他第五位。

有计划的处理需求和排期带来最明显的好处就是工作进度可视化，做的大多数事情都可以量化出来，以便评估自己的工作饱和度是否合理并就存在的问题与领导及时沟通；在涉及汇报沟通的时候也可以及时和领导同时同步进度，对后续的晋升加薪也有很大好处。

而缩短反馈周期这个对于不同人有不同的阶段性计划；对于我来说专心的做一件事情是一个正反馈，所以我给自己定的反馈周期较长，基本是以月来算的。

但是我也知道周期定的比较短的同事，甚至会以两三天为一个周期；但是只要能激励自己继续努力学习工作的都是好的周期计划，不存在绝对的优劣；而计划中的正反馈可以是按计划完成就去大吃一顿、看场电影、多玩会手机、请天假出去溜达溜达、上班摸摸鱼等等，不论是哪种只要能给自己带来爽感并保持后续动力的都是好的正反馈。

而以上的这些按计划工作、目标明确、效率增高的方式其实都可以归纳为“定位速效法”，一旦你摸清楚自己的“命门”能够给自己科学的制定计划，你的效率就能有效提高。

但是还有一个关键点要注意，就是自我奖励时一定要注意避免德西效应的出现，有时候内在报酬与外在报酬兼得的情况下，非但不会增强你的工作动力，反而会降低工作动机。

贪心不足蛇吞象，重赏之下有时也会适得其反。

四、总结

产品新人最在入职后应该做的事情就是融入团队、熟悉业务，能力够强的可以以转正时升职加薪为目标，能力一般的就以安安稳稳度过试用期为目标就好；过高的期望会非常严重的损害自身动力和自身形象。

最后记住三个要素：执行、沟通、计划——做好这三点安稳度过试用期不成问题。

作者：萌新世纪，一只初入职场的B端产品小萌新。

本文由 @萌新世纪 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash, 基于CC0协议。