产品经理需要什么样的能力——一封写给产品经理的告白书

| “ 这不是一个展开讲具体方法论的文章（确定目标人群）

记得留学的时候经常听李宗盛的一曲山丘，体会着生活中的探险家们去时艰难，离时心酸。而回国的这小段日子里却发现，自己一直停留在‘望丘’阶段，固步自封。

澳洲留学的最后一学期，参加了人生的第一次的招聘会，碰了无数次的‘璧’，学到了很多。鼻子没压的扁平，志也未曾变短，止不住的对互联网产品的热情却越烧越旺。

面试期间经常被问到一个看似简单，却作为没有产品经验的人很难回答的问题，“你觉得产品经理需要哪些能力”。原型图绘制能力？数据分析能力？团队的管理能力？都对，但说的苍白到连自己都没法打动。都是自说自话，隔靴搔痒。

然而认真想想，产品经理需要什么样的能力，确实是对我一个未入门的学生来说首先要了解的。

| 问题解读：As a , I want , so that

遇到这个问题我们先要分析一下，面试官问这个问题的初衷是什么。如果当时第一时间想到把面试官的问题，转化成用人需求，继而产出方案，我猜可能就答对了一半。

与其说面试官在问产品经理需要哪些能力，不如认为他是在说我们公司需要什么样的人做产品经理，以及做好产品经理的方法论。所以，“作为一名校园招聘的面试官，我想要找一个有相关知识准备且有培养潜力的应届生，去满足公司的人才储备和用人需求“。

这就是基础的User-story需求分析模型。

因此，说到这里不难看出，挖掘和分析用户需求，是产品经理最需要的能力。然而，C、B端产品经理需求分析这一阶段又不尽相同。

| 需求分析，To C、To B的不同‘营业时间‘（这里指广义上的C、B之分）

脱口秀大会里，庞博有一个段子说的非常形象。动物园里的动物也应该三班倒、996。白天睡大觉的夜行动物晚上也应该出来上班。如果动物园晚上不营业，用户都不会发现自己还有晚上逛动物园的需求。

如果说动物园分为‘昼行观园’和‘夜行赏园’，那‘夜行赏园’的业务就可以比作To C。大部分C端产品要有超前性。走在需求之前，想在用户前面，主动的去构想需求、创造需求、挖掘需求，开发和培养用户的使用习惯，寻找新的应用场景。一个成功新概念的To C产品不仅能够撬动增长，也会影响人们的生活方式。细数互联网巨鳄的To C产品，支付宝、美团、抖音哪一个不是想在了用户的前面。

段子的内容当然是一种夸张，但未来是否成为现实也尚未可知。所以，何必循规蹈矩，让按部就班生活方式索套住了我们的无限想象。没有创新的世界，一尘不变地死气沉沉。

另一方面，To B产品，在最开始的需求分析阶段就体现出了和To C的同宗不同源。它的存在更多是帮助一个已经相对成熟的实体业务实现互联网化。这一特性决定了它一般走在需求产生的后面。通常要根据客户的现存困境和需求，提出能够帮助客户解决问题的，贴合业务的，满足操作流程的，相对稳定的解决方案。

典型的来说，医疗、教育、金融、政企等容错率较低的行业，相关互联网产品的发展就显得更为谨慎。不怕慢，就怕乱。

一个不恰当的比喻，这可能就像法律的制定一样。法律是为了解决现存的社会矛盾，约束人们的社会行为而制定，为未存在矛盾和社会行为制定法律就是画地为牢、限制发展。法律存在的目的就决定了它一定是具有滞后性的，超前的法律制定只是一场没有现实做参考的“空想”。

然而，恰巧“空想”就是点开C端产品的萌芽的那滴甘露。

| 传统与敏捷之争

其次，我认为产品经理要需要了解传统和敏捷的软件开发方法。软件开发方法对于产品经理来说就像是一份SOP操作说明手册，帮助产品经理了解一般的开发流程、任务分配。进而更深刻的掌握时间管理、风险控制、需求管理、需求变更等，高效的管理手段。

敏捷软件开发(Agile Software Development)这个概念和项目管理中的的Agile PM类似。它是国内大部分产品经理，包括B端产品的必备技能。和澳洲、欧洲等互联网产业并不是发展较快的区域相比，产品经理在国内初诞的时候，除了正确的引导互联网产品的整个开发过程，同时也自带着加速产品的升级和迭代的任务。

相比之下，澳洲大部分互联网公司由于没有迫切的迭代需求，且更多的技术是靠第三方，在公司内往往是项目经理充当了产品的驱动器。（上述观点是对一名在澳从事前端工程师的总结）

说到敏捷开发的流程，就是在每个Sprint工作周期内，不断的“收集需求-研发-测试-上线”，每一个两周左右的Sprint，期间可能要经历很多次的需求整理提交。在部分公司里，需求的提交量也是一名产品经理绩效考核的标准。

因此，这就要求产品经理要从学会写完整、漂亮的PRD，转变到能快速抓住需求核心，拎清功能框架。在最短的时间内把变更和优化需求，用“图+文”的形式表述出来。这样“图+文”的内容表现形式也更能获得技术人员的青睐，提高部门间的配合。很多产品人直接使用原型设计软件，例如Axure，设计原型的同时，通过备注和连线的方式对相应功能作出解释。

而传统的软件开发一般使用瀑布模型，举例来说，从“收集需求-定义功能结构-验证和测试-运维“完整的软件生命周期(SDLC)闭环。当然，每个公司和个人定义的瀑布模型也不尽相同，这里不做赘述。与敏捷开发相比，传统开发每一步都走的较为谨慎，需要更多的数据分析、竞品分析、PRD等报告对每一次个阶段进行合理性的验证，对频繁的项目变更也更加不友好。

如下图，是我在留学阶段的一个项目计划书作业里，设计的Gourmet线上餐饮系统的实施与开发步骤。

推荐文章：https://www.knowledgehut.com/blog/agile/agile-project-management-vs-traditional-project-management

| 通过交流、分享去提升

保持交流和分享的行为方式，也是做好一个产品人的关键。

在工作中，交流可以帮助验证自身目的的合理性。交流存在多种方式：

1. 与用户交流——通过用户访谈，调查问卷等方式了解用户的观点。同时，作为产品经理，自己也是产品的第一个用户，利用同理心也可以帮祝我们进行有效的分析；

2. 与同行交流——向有经验的人请教可以避免掉很多初期会踩的雷，掉的坑；

3. 与上级交流——引用一句话，“事事有回应，件件有着落，凡事有交代”，产品经理必须自己先成为任务管理中的执行人，按时按需按量的交付；

4. 与数据交流——作为产品人需要对产品的数据需求有清楚的认知。产品内，提前设计好的数据埋点会帮助你建立用户画像，更准确的知道用户的想法。有时候用户可能自己也不知道想要些什么，但数据是客观的。行业内，整体数据的挖掘和分析也能够让你更清楚产品未来发展的方向。

说到分享，是因为从业之前，一位大佬和我说的话让我感触颇深，“互联网时代不能做‘老师傅’，要成为一个知识分享型的人”。

想到我自己平时也是通过阅读书籍和文章来充能，这句话让我体会到了分享的必要性。要有传递火炬的精神，施我与木瓜报之以琼琚的一种态度。

同样，分享也是自我总结、提升与进步的有效方式。就像另一种需求获取的手段，通过发布Test version或者Pilot version的软件，拿到初期的用户使用数据和Feedback，继而在正式产品上线前做进一步的调整。通俗点说就是，产品好不好，放到市场上先跑跑。毕竟，即使是未来之星的AI，也必须通过反复的模型训练和试错才能成长。

| 总结

产品经理需要的能力，当然不是这洋洋洒洒几千字能够说的完的。但写到这里时我也在反思，那么多的知识一篇短文说不完，也绝非短期内能够学习的完。强让自己什么都要明白反而徒增焦虑，相反夯实基础能力、深耕从事行业才最为重要。

总结的出最核心的，拎的清基本的，去掉那些花哨的，至少一个步子已经迈过了产品的门槛，产品的大门已经向你打开。

| 自评

想我以后可能也不是个高产的作者，尽量在每次阶段性的成长后，小述一下自己的心得体会，认的下批评，更欢迎交流。

有想法从事B端产品经理，需要推荐书单的可以留言，我总结后会私信发给你们。

本文由 @野兽凶猛 疯狂生长 原创发布于CDSN，转载请务必保留此出处
知乎主页：@Pinocchio