最近公司陷入了一些怪圈，每个人都在谈论公司的未来，都在关注公司的战略。有的同事刚入职公司，有的同事刚毕业，好像每个人都在指点江山一样，都在伸张正义。工作氛围也在这些低声细语中慢慢变得诡异起来，大家都开始焦虑了，可惜焦虑的对象不是自己，而是公司。
如果你是公司元老，又或者是行业资深前辈，这倒合乎情理。但如果你刚毕业，或者刚转行转岗从事一个新职业，我倒觉得这些担忧与抱怨真的多虑了。原因有很多，这里我不赘述。相反，对于职业初期的0-2岁，我更倾向于感恩你目前所在的这家公司，要坚信现在经历的一切，于将来都是宝贵的经验。如果要有一个可行性的建议的话，我想应该是：沉下心，锻造自己的核心能力。
产品经理的前2年，我认为核心能力需要聚焦在产品功能、技术素养、软实力这3个方面，它们可以为以后的职业深度打下坚实的基础。
一个好的产品是由很多个好功能的叠加组合，头2年一定要把绝大部分时间聚焦在的产品功能上。
这里我提到的是产品功能，而不是需求，我们会习惯性的认为别人提过来的才叫需求，如果没有人提了，那是不是就代表可以不去做功能优化了。所以我会认为前期应该关注一个产品功能的本身，你认为它还有没有提升的空间，如果有，那何不尝试一下去梳理它的优化思路，做个脑图，画一个原型。没有任何人给你安排这个任务，你只是在为自己而做。
优化一个功能的另一面，是挖掘新的需求，创造出新的功能，这是在优化的基础上更上升一个层次。如果说优化只是在原有功能的基础上，从用户体验的角度出发，去提出一些改进意见，那打造一个新功能就需要有强大的洞察力。你需要将自己完全站在用户的角度的去不断试用这个产品，你需要不断想象用户可能的使用场景，又或者用户可能会遇到的问题，反复揣摩后才能提出一个用户到现在还没有被满足的需求以及解决方案。
我在做产品的第2年就大量的在干需求挖掘这个事情，我把它称之为“储备功能”。即便在没有开发资源的情况下，也没有领导安排，我根据自己对产品和业务的理解，规划了很多以后可能会用到的功能，画好了原型，做好了流程。其中几个功能甚至是我离开这家公司之后才开始被纳入到开发计划中。
功能的优化与创新，实际上是训练我们对用户的洞察，能不能找到用户的痛点、用户的恐惧以及用户的愉悦。我认为在产品的初期，需要有那么一段时间，让自己沉浸其中，习惯从用户的视角思考问题，做那些单纯为用户着想的事情。
产品功能之外，产品经理打交道最多的便是开发人员，“技术素养”对一个产品人的影响也是至关重要。
我们经常能看到一些提问，说产品经理是否需要懂技术，又或者产品经理应该怎么和程序员沟通。我也遇到了这个问题，甚至因为不懂技术术语直接被一家公司拒之门外，当时面试我的面试官给了我一个名词，叫“技术素养”。
此后我开始花时间去了解技术，去理解到底什么是技术素养。我将所有我可能在工作中和程序员沟通到的技术名词在百度上查了一遍，然后自己再用脑图整理成文反复学习，这确实对我后面和开发人员的沟通起到了一定的作用，我开始能听懂他们在说什么，并可以参与他们对实现方案的讨论。但技术素养不该就此结束，它还有更深层的意义。
和程序员沟通，就应该首先站在他们的视角，这是我从程序员沟通的角度理解的不一样的技术素养。我们在和程序员沟通的时候，他们又何不是我们的用户，听懂用户在说什么，不一定非要懂他们的语言，而是要回到他们的角度，感受他们此刻的情绪，这是从共情和同理心的角度训练自己和程序员之间的沟通。很多时候程序员和我们说这个需求无法实现，大家争的面红耳赤，难道真的是这个需求无法实现吗？你可以试着先去理解他们的难处，可能是目前系统架构的原因，又或者是他们顾及到对性能的影响，把他们当成自己的用户，去倾听和关心，他们会主动告诉你问题在哪，并给出他们觉得更完善的方案。
我理解的另一个层面的技术素养是关于对最新技术的把握。技术在不断发展，一个新的技术的产生，它会不会帮助我们优化当前的产品，甚至有没有可能在当前产品的技术上带来新的突破，要做到这一点，产品经理需要持续关注那些核心技术的进展。
比如当年微信小程序的能力就是逐步开放的，一开始小程序只能支持APP以小程序的形式分享到微信群，使用场景非常单一，但后来微信开放了微信群打开小程序可以回跳到APP，这就实现了“小程序-微信群-APP”的低成本流量闭环。那段时间我每天都会关注腾讯的公众号和小程序开发者中心发布的新功能说明，然后和开发人员一起讨论那些更新的功能能否使用在我们的产品功能上。长此以往，它可以训练我们对技术发展的预判能力，在设计一个产品功能的时候，如果提前预判到它未来的发展方向，就可以为其搭建一个迭代的框架，一旦时机成熟，机会只留给有准备的人。
技术素养不仅是技术本身，还有如何从程序员的角度去解决沟通问题，以及对技术发展的预判。相比起技术本身，后两者更是产品经理更应该着重关注的。
最后我想聊聊软实力，在职业的初期，可以着重训练自己的数据分析能力和报告呈现能力。
数据分析能力应该首先得到关注。身边一些产品同事嘴上说想要学习数据分析却迟迟不见动静，真正想做数据分析的人是会自己去找一些数据，通过Excel研究，尝试着去分析并得到一些结论。每个公司都有或多或少的数据，想要做到这一点并不难。数据分析的底层抽象出来，其实不在于数据本身，而是你对数据维度的拆解能力。
比如客单价，你是否能联想到客单价可以进一步拆解为低客单和高客单；又比如消费频次，你是否同样能将其拆解成低频和高频，这样拆解后是否还可以进行组合，将高客单和高频两组数据组合在一起，那就是我们的核心用户，将低客单和低频组合在一起，有可能就是薅羊毛的用户。这是一种先拆再合的思路，先把数据揉碎，然后按照一定的逻辑重新组合，这种能力需要花时间训练，同时也需要不同的数据进行训练。
这种数据维度的拆解能力之所以重要，我认为它还可以反向帮助我们进行产品设计和功能规划。在产品设计的过程中，这个功能要不要，就可以从最终的数据维度的角度进行思考，看这个功能会不会出现在数据维度中，同时它的影响因素会有多大。
比如我最近的一个电商项目，同样是关于“差评”，低价商品的购买率不受差评影响，相反如果靠前的评价中有差评的话，高价商品的购买率就受差评的影响。如果我们在设计评价功能的时候就能将评价至少拆解成好评和差评两个维度，同时预判到差评对转化率的影响，那就可以在评价的排序逻辑上做一些优化，尽量使差评不要出现在靠前的位置从而影响了转化率。比起事后再根据各项数据分析来找原因，如果能在事前就通过数据维度的拆解，进行合理的功能设计，这将是一个产品经理走向成熟的标志。
关于报告的呈现能力也是我们容易忽略的重要环节。很多人做PPT都在找模板，把自己要讲的内容往模板里一塞，还要抱怨格式调整好麻烦，最后听报告的人云里雾里，根本找不到重点。同样，我们把报告的呈现能力抽象出来，实际上是对内容的精简能力和连接信息的逻辑能力。
内容的精简主要在于观点，或者说是要点，一个报告会议会有一个要点，呈现出来的PPT的每一页会有一个要点，信息的连接体现在要点与要点之间的连接方式以及要点内部信息的连接方式。它们要么是平行的关系，要么是纵向的因果关系，就像物理中的并联和串联。了解这个逻辑后，你就会理解为什么模板实际上解决不了问题。如果想要依靠一个固定的模板就能完成一次汇报的话，除非你的呈现信息的逻辑与这个模板的表达逻辑一致，否则就会就会发现模板根本帮不了你。
我们把这种串并联关系再进行抽象总结，最终其实是一种结构化的思维。工作中有太多零散的数据，业务方提过来的各种各样的优化需求，一个功能有很多个优化指标，到底应该怎么处理。而结构化思维要求你必须将它们进行归类总结，提炼共性，找到核心点，然后再由核心点出发向下进行一层一层的拆解，直至提供一套合理的解决方案。这是一个先倒金字塔再正金字塔的过程，用倒金字塔的方式来做分析，用正金字塔的方式来做呈现。
软实力究其本质还是对底层思维能力的训练，一个是数据的敏锐度，一个是一套最底层的分析框架，但它们都没有离开一个关键词：以终为始。先确立终点，才能一层一层推演到起点。
职业的前2年，有那么多的事情需要去做，有那么多的基本功需要去练就，我想看完这段你应该没有时间再去为公司的发展殚心竭虑了。把更多的时间放在自身底层能力的搭建上，每一家公司，注定都只是这一生中短暂的过客，只有自己成长了，才不会枉过一生。
