产品经理的核心就是提出一个好的想法+把这个想法实施，分别对应了道和术，因此本文作者从这两个角度谈一下自己的收获。

2018年是我开始做产品经理相关工作的第一年，也是成长飞速的一年。前六个月和朋友一起到腾创业公司，在做区块链游戏产品，有了从0到1的产品落地经验。后半年在LinkedIn做PM实习，在growth team做用户增长相关的产品功能，系统输入了很多方法论，也从各位前辈身上学到了很多。希望把第一年的一些感受写下来，也算是有始有终，当然毕竟新人才疏学浅，如果有说的不合理的地方还请各位前辈指点啦~

产品经理的核心就是提出一个好的想法+把这个想法实施，分别对应了道和术，因此想从这两个角度谈一下我的收获。作为一个PM，我们应该怎么思考问题，日常工作中又有哪些技巧可以促进工作。

产品经理之道

1. 定义衡量产品的效果要能从CEO的角度出发

• 做一个feature是一定需要衡量其成功指标的，需要回答的问题是成功会是什么样子的。而从CEO的角度出发要求我们首先思考，这个feature和整个公司的战略目标之间有什么关系。一个产品可以有很多成功指标，思考单独的产品和公司的联系可以给诸多成功指标排列优先级和重要程度。
• 第二，从CEO的角度出发要求我们在定义产品成功的时候除了关注自己的数据增长，也关注是否给别人的指标带来了负面的影响。一个用户一个时间段也许只能干一件事，因此你做的一个新功能可能影响别人的功能，这也是我们理解tradeoff 的一个角度。
• 与之相类似，从CEO的角度出发要求我们从“投入回报率”的角度去衡量产品效果，因为同样的一个工程师一个时间段也只能干一件事。也许这个产品功能在A/B test的效果很好，但是带来的数据将增长整体可能不如另一个你没有测试的idea，因此不是单纯的数据增长就是我们最想达到的状态的。
• 最后关于衡量效果要求我们不断深入问“为什么”，你可以说这里做这个事儿可以提高用户体验，可以拉动某个数据，可是为什么要拉动这个数据呢？这个拉动/优化是一次性的还是可持续的呢？反复地，不断地深入挖掘原因才可以理解产品，从而提高决策的准确率。

2. 产品迭代中最重要的是学到一些可以复用的经验

迭代这个概念应该已经是老生常谈了，记得我刚开始做功能的时候，会和老板讨论，哎呀我这个点击率不高是不是因为这个卡片的视觉效果不好，如果更新一下设计是不是会好一点。感觉这也是新人产品经理的通病，天天抓住一个UI设计不放，执着研究各种交互细节。这其实不是所谓的迭代。

迭代的核心除了拉动数据更重要的是“学到一点新东西”，通过这个迭代不仅数据变好，PM的决策能力应该也相应的提高。为了学到新东西，我们在做迭代的时候就应该有一些假设，从假设出发然后通过迭代去验证假设，从而收获新的关于用户，关于产品的理解。

更新UI设计等应该是在MVP的时候就应该做到尽善尽美的，尤其是一些“你明明知道可以拉动一些数据”的UI更新，比如颜色更鲜明，大小更大。这些事既然知道一定可以提升效果，那为什么最开始不做呢？因此迭代的时候需要迭代的是一些你觉得可能会有效果的东西，而不是你觉得肯定有效果的东西。

迭代的三个步骤应该分别是定义问题，验证假设，功能优化。首先就应该明白我现在做一个优化需要回答的商业问题/战略问题/产品问题是什么，然后对这个问题有哪些可能的答案，如何设计实验去验证，再基于这些结果优化。

3. 数据驱动思维更关注你能对这个数据做什么

好像所有的PM面试中，都会问你做这个功能需要看哪些数据或者你之前做过的功能数据上效果怎么样，数据驱动基本上快变成一句正确的废话了。确实在写需求文档的阶段，我们就需要明确成功指标，上线以后也会去看数据反馈。

大家最喜欢的就是看PV/UV/CTR(点击率）这些“行为指标”。行为指标确实可以直接反应用户的行为，可看了以后呢？你知道PV不行，CTR很低，然后呢？你并不能做什么，也并不能知道真正的原因。

因此所谓的数据驱动是要让数据能够指导决策，或者说actionable numbers.

比如：日活跌了，应该先想有哪些渠道可以促进日活，再去分析。数据驱动不是有一个数据就够了，应该能够向前&向后思考，向前思考这个数据会由哪些行为影响，向后思考这个数据的涨跌意味着什么，我应该做点什么。所以PV这样的指标通常是用来反馈用户行为的，而非我们用来定义产品效果，或者驱动产品决策的指标。

为了做到数据驱动，我们首先要对数据有一个基本的预期，比如你猜到做这个功能可能促进日活，那能够促进百分之几呢？越明确的预期越可以便于后续的衡量决策等。其次我们要对可能影响用户行为的控件进行足够的埋点，比如：这个页面上某个按钮点击率低可能是因为用户觉得另一个图形看起来也可以点击，就去点另一个了。

埋点的时候不能只考虑直接相关的，也要把一些扰乱因素融入进来，这样当数据出了问题时才可以有理有据找理由，想解决办法。最后数据驱动还要求我们在设计功能时就知道如何能用数据验证，去思考一些量化指标以及如何获得相关的信息。

4.  对产品负责意味着要有明确的观点和作出决策的能力

都说产品经理是产品的第一负责人，但这个负责到底是指什么呢？

我刚开始的误区就是在最初定义了产品功能以后，与各方沟通，监督整个开发全过程就好了。但后来才发现产品经理的负责不是随叫随到，有什么问题都去解决，而是在每一个出现问题的时候都可以作出明确的决策。

为什么需要有明确的观点和决策？

因为很多时候产品开发过程中面临的问题是妥协（tradeoff），工程师资源不够时间不够，设计师觉得你这个方案不好看等等。太多的小问题会影响最终的产品形态和开发进度，在这个过程中谁来做决定想办法呢？

毫无疑问是产品经理，而他如果没有明确的立场就会被各个利益相关者牵着鼻子走，最后做出来的产品可能就完全不是最初设想的样子。记得我刚开始实习的时候面对各方的质疑就毫无还击能力，很容易松口。但产品经理是最了解产品的人，有义务有资格也必须去拍版。

那如何拥有这样明确而果断的决策力呢？

有句话我很喜欢：

fell in love with your problem rather than solution.

决策力需要建立在明确的立场上，需要你明确你要的是什么。大部分时候你要的不是某个方案，而是去解决用户的问题，满足用户的需求。因此一直关注你要解决的产品问题/用户问题，能够让PM在繁杂的大小决策中保持态度和观点。思考问题这个过程本身也比最后呈现出来的方案有意义。

产品经理之术

1. 好的需求文档需要有清晰的故事和完整的记录

产品经理不用写代码也不用画设计图，好像只能写个需求文档。这个文档确实不如代码/设计稿有直接的生产力，但是质量好坏直接决定了产品开发的进度和效率。好的需求文档应该完成两件事儿，首先讲好一个故事/愿景，其次说明白你要怎么做到。而衡量的标准就是别人不用问问题，也可以知道你在做什么，甚至是觉得“嗯，我在帮这个PM完成一项好伟大的事业！”

讲一个好故事也就是常规的写作套路，说明白要解决的问题，如何衡量等，也就不再赘述。而如何解释清楚你要做什么则是一门艺术了，我认为需要针对产品计划和开发进度分类。

比如：产品上不能只写你现在要做什么，需要有一个roadmap告诉大家以后可能还要做什么，因此可以在首次开发的时候就plan ahead。其次开发进度中要记录timeline，去督促大家在时间节点前完成，同时也记录没有完成的理由，用于反思等等。

需求文档最大的特点应该是“变化”，它需要根据开发的具体情况不断的变动，因此最好的文档不是最初去写一份完整的文档，而是记录了产品开发过程中的大小事件，这样对于整个团队都能降低沟通成本，提高效率，也便于日后反思回顾。

2. 最好的沟通永远需要超额沟通，over-communicate

产品经理除了写文档还在做的事儿大概就是开会以及与各方沟通了，因为经常和美国的同事打交道，老板第一天就跟我说要overcommunicate。沟通的技巧有很多，为什么沟通对PM格外重要，可以通过沟通达到什么效果呢？

首先是保证项目不延期，不出错。大型的产品涉及太多部门的太多人，misunderstanding太常见了，因此需要我们时刻记住通知/同步所有人。其次沟通包括逼迫别人作出决策，比如：要开发一个功能，工程师可能要先去调研一下可行性等等，每当有这种pending issue的时候，产品经理需要push别人去得到结论。

不可能事必躬亲只有保证他人也也能做出合理决策才能最大化产品效果，所以我觉得产品经理沟通的终极目标就是在没有了你的情况下，你的团队也能完成产品的开发。让大家都理解产品的前因后果，不要让别人就像给你干活的，应该让大家觉得我们是在一起完成一项伟大的事业~

最后，对于我而言产品经理最酷的一点就是这份工作似乎让我变成了一个更好的人，这个好与精英/完美无关，纯粹是通过与不同人一起协作解决用户问题，加深了我对世界，对自己的理解。也许产品经理的出发点是去解决用户的问题，但具体工作则更是每个PM关于自己的一场修行。

Product that stands at the intersection of humanity and science makes me a better person. 共勉

本文由 @Shixian 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议