产品经理入门指南
最近有一个同事正好转岗成为产品经理，导师正好是我，也恰好有一位开发同事找我到底要怎么去做一个产品经理。虽然一直以来大家都在说人人都是产品经理，我其实不是特别认同这句话，逻辑就好像是产品经理是人，所以人人都是产品经理。但是会做饭并不代表就是厨师，会提需求也并不代表就是产品经理。当同事问我什么才是一个合格的产品经理时，我突然意识到我其实并没有认真的去思考过这个问题。我最初是做 UI 设计兼职前端开发，到后来做 UX 再到现在做产品。一切似乎都是那么自然而然，没有觉得转岗会有什么难处，似乎是因为从我做设计的时候就一次操着一颗产品经理的心。
我觉得要回答什么是好的产品经理，需要先回答为什么需要产品经理。我个人的看法是，我们之所以需要产品经理，是因为我们需要有个人告诉开发，什么时候该做什么功能。简单来说就是拍优先级，写用户故事，准备好各种基础工作，让开发拿到任务就可以直接上手去做。看起来就是拍个优先级似乎很简单，但是其背后的逻辑在于对于产品价值和公司战略的理解，对用户的理解，对于开发成本的理解，以及对于数据指标的理解。
理解战略
对公司战略的理解决定了产品经理对产品目标的理解，对用户的理解决定了产品经理对产品价值的理解，对于技术的理解则是对成本的理解，有明确的数据指标，才能衡量这个「需求」的价值。那么产品经理需要通过性价比，来判断某个需求的优先级，同时需要有一个可以量化的指标来向外界证明自己的价值是对还是错的。
我理解的产品经理一个沟通的媒介，产品经理将大佬们制定的公司战略，转化为产品战略，并将这种战略传达给执行团队（开发和设计师）。写文档、用户故事或者是画原型图，都是作为与团队沟通的手段。在复杂的产品架构中可能有会有不同的产品层级，例如产品总监将公司的战略传达给组长，组长在根据自己组的情况将战略拆分到自己的小组，导致的一个问题是最底层的写文档的那部分产品经理没有宏观上的产品战略的意识，只是做自己该做的事情。
对于一个企业来说，其最终目的无非是为了盈利，获取更多的利润。企业和产品所处的阶段不同，具体的目标也会有所差异。例如初创公司通常不怎么关心收入，反而更在乎用户量和 DAU，因为投资人会更看重这些数据。当产品逐渐成熟，用户量也很难有大的增长时，利润率又会变成公司的目标。而产品经理要做的，就是配合公司的这些目标给出产品上的方案。
产品的方案通常需要去综合考虑三个因素：商业、技术和用户。商业想要的未必是用户想要的，用户想要的，未必是技术能够提供的，技术能够提供的未必能够满足商业诉求。那么对于产品经理来说，第一个基本的要求就是能够理解公司的战略。「理解」的意思就是能够从的自己角度去解释公司的战略，为什么要这么做，价值在哪里，风险在哪里。这样才能在向团队解释为什么要做某个故事时，可以站在公司战略来解释。
理解技术
公司的战略对于产品来说算是一种需求范围的限定，意味着我们只能在某个方向上去探索产品的未来。在这个范围内，产品经理要继续寻找哪些是有真实的用户需求的。找到用户需求之后才去确认技术是否可行，稍微有点技术理解能力的产品都可以自己判断出技术能否实现。但是能否实现并不代表容易实现，在软件公司， 特别是 SaaS 公司，因为没有大量像传统公司的固定成本，做某个功能是很大程度上只需要考虑技术难度，很多时候技术难度就代表了这个用户故事的成本，所以在众多可选择的方案中，产品经理需要判断出「性价比」最高的方案，意味着更少的技术成本以及对公司目标最有帮助的方案。
成本往往可以比较直观的计算出来，开发通常会说三天或者五天，或者一个月，时间就是成本，但是最终的效果确实难以估算的，在真正做出来上线之前没有人可以预估这个方案的效果会有多大。虽然没有直观的统计方案，但是我们可以通过很多间接的方法来预估，例如是否竞争对手有对应的功能，网络上用户对该功能的评价等。
需求文档或者用户故事实际上是帮助开发去估算成本的参照。需求写的越详细，开发的估算就越可信。所以需求文档的撰写是产品经理的基本要求，需求文档决定了开发估算的成本的可信度，如果可信度越高，那么能够帮助产品更有效的决策产品的方向，如果文档残缺不堪，没有明确功能的边界，那么开发过程的需求蠕变就不可避免，需求蠕变导致功能的成本无限制的增加，那么「性价比」这个词就不存在了。
对于技术的理解并不代表要会写代码，而是要知道技术的限制和难度。我尚未发现在这方面有不错的内容可以推荐，之后发现才做更新吧。
理解用户
对与初级的产品经理来说，可能老板说是什么就做什么，这个似乎是一个绕不过去的坎。对于初级用户来说就不需要从业务上去理解用户，可以单从人的角度去理解用户。意味着你可以不理解在某个领域，例如银行或者快递行业某类具体用户的痛点和业务流程，但是作为一个人，你可以感受到用户在使用你的 App 或者网站时的感受，也就从关注用户体验开始。
用户体验时锻炼同理心的一个出发点，但是有个建议，如果产品经理不是特别了解用户体验，那么很多时候把决策权交给设计师，因为他们更专业。
之所以把用户放在商业的后面并非用户不重要，相反用户才是最重要的，但是对于用户的理解并非一朝一夕可以了解透彻，很多时候需要一个人在行业内的经验积累。对商业的理解可以说是对行业的理解，多数时候你可以不去深入思考，跟着老板的需求做就是了。但是产品想要提升自己一定要去理解用户，理解用户的方法有很多，有时候条件限制导致我们真的无法直面用户，也可以通过很多间接的方式去理解用户。例如去做竞品分析，去 Reddit 上看看这些人都在聊些什么。
另外就是对于需求的理解，用户的问题不是需求，用户想要的功能也不是需求。一个需求对于产品经理来说都是一个「假设」。假设我们做的某个功能就是用户想要的，且通过这个功能可以在某种程度上达成帮助公司达成目标。
理解指标
我们在写用户故事的时候都需要写一份验收标准，通常软件的验收标准是通过 BDD 来描述的。验收标准可以理解为对用户行为的描述，通过描述用户行为，我们预期软件应该如何回应用户。这就是一个很直观的指标。
除此之外，公司的目标通常会通过一系列的数字反映出来，例如收入或者是新增用户数量，那么需求作为一种假设，所验证的也是对某个具体指标的影响。通常不存在某个功能，上线之后就可以直接帮助公司的目标，例如公司的目标是赚个 1000 万，产品不可能说我就开发个付款 1000 万的功能，万一有一个付费呢？
产品通常是将这个目标通过其他的公式，例如如果电商公司，那么收入 = 客户量 x 客单价。那么产品的目标可能是提升客户量也可能是提升客单价，有些产品也会双管齐下，不过不 focus 通常也很难达成目标。比如客户量可以继续细化，不同渠道的新增用户不同，产品可以继续聚焦于某个具体的渠道，然后计算一个转化漏斗，那么客户量 = 渠道的流量 x 转化率。此时也可以选择聚焦于提升渠道的流量还是转化率。所以虽然公司的目标是收入，但是到产品策略上，需要关注的数量可能变成了渠道的流量了。找到正确的测量指标也是产品经理需要具备的基础能力。
以上几点并不会帮助你写出好的需求文档或者用户故事，但是能够帮助你确定一个大概的方向，现有方向才不至于在些需求的过程中迷失自己。但是只有方向依然不能做好产品经理，我见过一些产品能够理解商业和技术，但就是不会写文档。我对此的理解是，不会写文档的人通常不理解用户。原因很简单，文档也是有用户的，这个用户就是开发人员或者设计师。写不好文档意味着产品经理无法站在开发和设计的角度去理解需求，也就是没有同理心。所以写文档和 BDD 是产品的基本功，虽然很枯燥无聊，但却是帮助整个 team 的必经之路。
我有时候在面试的时候会问面试者一个问题「把我当作一个投资人/用户，向我推销你的产品」，虽然产品经理不是销售或者老板，但是产品经理一定理解产品的特点以及用户痛点，其实这里就是要描述产品到底解决了用户的哪些问题，以及与竞争对手的差异在哪里。但是很多产品经理往往只会说我们是行业第一之类，而根本不理解自己的产品到底是为了什么而存在。
最后再聊聊产品经理对于技术和设计的了解，产品经理了解越多的技术和设计对自己是有优势，我是从设计师转的产品，做设计师的时候又会写前端，后来也自己学了点 Python，实际使用中跟开发和设计师的沟通都会很流畅。但是自己理解并不代表自己是专业的，在于设计师与技术的沟通中还是要尊重对方的专业知识。
以上是根据我们最近在招聘产品经理的过程中自己的感受，深圳多不胜数的产品经理，但是真正理解产品和对产品有热情的人却太少了，大多数人不过是把产品经理作为一门混口饭吃的职业，但即便是混口饭吃，也要提升自己去努力吃点好的吧。
在跟同事的聊天中，提到对于用户痛点的发掘，有些人觉得很难。其实我们每个人每天都会遇到各种各样的问题，只是很多时候我们都习惯了，习惯有时候确实是一个好东西，但是对于各种不便利的习惯和问题的习惯，反而会扼杀产品经理对于问题的发掘，所以不要习惯，不要习以为常，不要遇到什么事情都觉得理所当然，记录这种不愉快，然后尝试改变它，即使现在改变不了也不要变成了习得的无助，一旦有机会的时候一定要尝试去改变你觉得不爽的地方。另外一定要有同理心，不仅仅是用于感知用户的想法，同时也是用于感知团队中其他人的感受。