产品经理这一角色承载着将创意转化为现实的重任，从需求的洞察到产品的推出，他们是如何平衡用户需求与商业目标的？本文深入探讨了产品经理的核心职责、挑战和成长路径，带你一窥这个被误解但又至关重要的角色。
那在内容开始之前，先问大家一个问题。
产品经理是谁？
who？
在日常工作中，大家是不是经常被问到类似的问题？
每当被问到类似问题时，我常常陷入沉思。
这似乎也变成了一个「永恒的问题」。
每当逢年过节，与亲朋好友聚会时，总会遇到这样的对话：
亲友：“你是做什么工作的呢？”
我：“互联网行业。”
亲友：“哦，那你一定很会用电脑吧！”
我：“… 我是产品经理 … ”
亲友：“不错啊，都当上经理了！”
我：“不是，产品经理并非传统意义上的‘经理’。”
亲友：“那是什么？”
我：“… …”
每当被外行问及，我总是自嘲地回应：“产品经理嘛，其实就是个‘全能打杂的，或者救火队长，总之哪里需要去哪里’！”
在日常工作中，产品经理这个角色需要涉猎广泛，但又不可能做到样样精通，行业里也常常流传着一句话，“产品经理什么都要懂但什么都不精通”。
除了每天各种撕逼外，似乎并没有一项真正擅长且独一无二的技能。
而且每个团队对产品经理的期望和要求也不尽相同。
就导致了一种普遍观念，认为产品经理无非是链接业务和开发的工具人。
–但是
事情并没有那么简单。
因为产品经理被要求需要同时具备广度和深度。
那这个角色就注定了在很长一段时间内都会被人误解。
先给大家分享一个小故事。
也是一个比较典型的案例。
100多年前，福特公司的创始人亨利·福特先生到处跑去问客户：“您需要一个什么样的更好的交通工具？”几乎所有人的答案都是：“我要一匹更快的马”。很多人听到这个答案，于是立马跑到马场去选马配种，以满足客户的需求。
— 但
客户是真的想要一匹很快的马吗？
或许吧。
但福特先生却没有立马往马场跑，而是接着往下问。
福特：“你为什么需要一匹更快的马？”
客户：“因为可以跑得更快！”
福特：“你为什么需要跑得更快？”
客户：“因为这样我就可以更早的到达目的地。”
福特：“所以，你要一匹更快的马的真正用意是？”
客户：“用更短的时间、更快地到达目的地！”
然后福特就发明了汽车，很好的满足了的客户的需求。
嗯！
这个可能是一个很好的满足了这个客户以及一群客户的需求。
如果我们停留在现有客户所说事物的表面，傻傻去找一匹很快的「马」，那现在可能就没有汽车了。
好的，这期内容正式开始。
产品经理「PM,Product manager」，在公司主要负责规划和管理某一项或某一类产品，主要涉及产品的研发、制造、营销、渠道等工作。
2009 年360红衣教主周鸿祎，在媒体上强调自己是产品经理，后来，⻢化腾也说⾃⼰是产品经理，乔布斯也在媒体上被强调为产品经理，这三个⼈重新定义了⼤众理解的产品经理;
⼤家⼀想起产品经理就是CEO们的形象，大众会有认知误区：⼀⽅⾯，雷军、张⼀鸣、王兴、张小龙、乔布斯、 PeterDeng等多个知名企业创始⼈也强调过⾃⼰的产品经理⻆⾊。
产品经理需要具备产品思维，以用户的需求为导向，输出有用户价值、商业价值的产品。
同时，包括市场调研、产品定义及设计、项目管理、产品宣介、产品市场和产品生命周期管理等。
Marty Cagan 在他的《Inspired》书中将产品经理的工作描述为“发现有价值、可用和可行的产品”。同样，我一直将产品管理定义为业务、技术和用户体验之间的交集，一个好的产品经理必须至少在一个方面有经验，对这三个方面都充满热情，并且熟悉所有方面的从业者。
从上图角度出发，定义这三个概念以及三者之间的关系。
用户体验「UE/UX,User Experience」是许多人挂在嘴边的名词。
但这是一个多维度、相对主观的概念，它涉及的是用户对我们提供的服务的整体感知，而非仅限于产品、应用、网站或设备等物理接触点。
真正的用户体验关注的是服务的整体流程，包括但不限于APP页面之间跳转逻辑、界面的框架设计和布局、更要从全局思考整体业务流程。
之所以说用户体验是相对的、主观的、片面的，是因为它依赖于个体用户的独特感受和认知。
举个例子。
你去一家西餐厅吃牛排，牛排能不能吃，好不好吃是餐厅所能提供服务的核心，但当朋友们问起这次吃饭的体验如何时间，你脑中浮现的绝不仅仅是牛排的味道，可能还包括餐厅的门面，店内布置，桌椅摆放，服务人员的态度、响应时间，菜单设计，看单点单流程，上菜的时间和顺序，其他客人的用餐状态，以及买单和离开时的服务等一系列的体验，构成了你对朋友的回答：好，或不好。
这一系列影响用户体验的因素，都存在于用户脑中，而不仅只在我们作为餐厅运营和管理者的脑中。作为产品经理，你如何定义这项服务中的每个关键因素，并围绕着关键点提升 UE ，就体现了你在这方面的专业素养。
产品经理用不用懂技术「Echnology」？
这个话题一直存在比较大的争议。
普遍的共识是：理解技术对于产品经理来说是至关重要的，这不仅有助于更好地定义产品的构建方向，还能在与开发人员沟通时建立更深的信任关系。
其中最重要的帮助就是信任。
产品经理对计算机知识的了解程度和迭代频率，就像“水”的质量和流动性，了解的越多，越能帮助彼此理解双方的需求，互相认同。
对于产品经理而言，商业「Business」洞察力可能经常被放在“重要但不紧急”的象限中，这在互联网行业尤为明显。
商业的本质在于追求资金增长，通过资本运作和建立关系网络来规避风险，其深度和广度往往使得许多人对其保持敬畏，进而不愿或难以深入探讨。
要提升在商业方面的认知和能力，最直接的方法便是亲身参与商业实践，通过实际操作来学习和领悟。
除了这些，还可以努力将自己塑造成一个具有商业价值的人，以便在商业环境中更容易被发现和认可。
在日常工作中，将关注点从“业务”或“业务逻辑”提升至更宏观的“商业”层面，了解自己在公司整体战略中的位置和贡献，也是提升商业认知的重要一步。
前不久阅读了Josh Elman的文章《Let’s talk about Product Management》，其中一句话让我豁然开朗——“产品经理是帮助团队发布正确产品的关键角色”。这句话精准地阐述了产品经理的核心职责和价值所在。
从产品的角度来看，产品流程主要涵盖了从项目启动到项目收尾的各个环节。
但一个项目从启动到收尾是由多方共同协作的结果。产品经理在其中扮演着“将idea/需求转化为产品”的角色，十分关键，优秀的产品经理在项目中不仅仅着眼于产品本身，还包括与产品相关的人和事儿，因此让我们从产品经理工作职责内去看看产品经理视角下的工作流程。
常见的产品经理的工作流程，基本是需求管理、产品规划、项目管理。
实际上，产品经理一上来不是做产品规划，也不是做需求分析，而是做需求管理。
因为要为用户服务，为商业服务，就得了解他们的需求和诉求。
收集需求和诉求的过程，需要面对的第一个问题就是沟通。
沟通能力是产品经理需要具备能力中比较重要的能力之一。
沟通前，要想清楚沟通时主要想解决的问题，有一点思考并能够陈述出来，随后与相关人发邀请「邮件、微信等方式」；
沟通中，沟通前先闲聊几句进入正题，围绕目标进行沟通，做好记录，并在会议结束时确认沟通的内容，有条理的确认一遍「对方提出问题，要听清对方的问题，作出有条理的回答」；
沟通后，总结访谈内容/会议纪要，添加微信、组群、组织交流学习等。
沟通不仅仅是为了解用户的痛点、痒点、嗨点，也需要了解用户的期待和目标，也许用户已经为了解决问题尝试了一些办法，也许这些办法是很可笑的，但还是需要尊重用户，作为产品经理只是帮助用户解决问题、更好的解决问题、规模化的解决问题，在做到这些的同时考虑商业化的解决问题。
产品经理必备的文件“需求池”，需求池是在收集需求中产生的，非常有必要做的一个表格，可以帮助你追踪、溯源、管理，具体内容如下图。
可以根据自己的需要建立自己需求池，这个非常重要，希望各位产品人能够养成使用的习惯
需求池字段包含需求来源、获取日期、沟通人及联系方式、需求价值、需求类型、需求描述、问题点、需求优先级、备注等。
将收集到的需求尽可能详细的记录在内，尽可能的收集一手需求，刨根问底找到提出需求的那个人，让需求尽可能的接近原始。
需求的初步的筛选和分类可先按以下方式进行分类，再通过内部需求评审具体的商议定性「类型和优先级」。
根据马斯洛需求层次理论，产品需求可以划分为生理需求、安全需求、社交需求、尊重需求和自我实现需求。
这种分类方式有助于理解用户在不同层次上的需求，从而设计出更符合用户心理和行为的产品。
明确需求的背景，用户的画像，用户的目标，根据5W2H的结构化思考方法，用Y理论进行分析。
进行成本评估需要综合考虑多个方面，包括直接成本，如人力成本「开发、测试、运维等人员的工资和福利」、硬件和软件成本「服务器、开发工具、第三方服务等」、培训成本等；以及间接成本，如项目管理成本、沟通成本、风险控制成本等。此外，还需要考虑时间成本，即完成需求所需的时间周期，以及由此产生的延期风险和其他潜在成本。
在评估过程中，可以采用多种方法和技术，例如，用工作量评估法来估算开发团队完成需求所需的工作量，从而推算出人力成本。还可以使用类比评估法，参考类似项目的成本数据来预测当前项目的成本。
同时，为了更准确地评估成本，还需要考虑一些关键因素。如技术的复杂性和新颖性，这可能会影响开发难度和所需时间；团队的技能和经验，这决定了工作效率和质量；市场的竞争状况和需求变化，这可能对产品的定位和功能需求产生影响。
每一个需求，围绕我们前面说的，都有其紧急重要程度，依次排优先级。
紧急度主要看风险或者损失量，重要度主要看影响和波及面。
重要且紧急的，那我们就要往前排，反之则往后；
如果两个需求都同样紧急且重要，那我们就要参考需求处理周期和人力资源成本因素。
不管是产品规划，还是开发上线，都需要周期，也需要资源配置。
如果周期太长，而用户需求又迫切，我们就需要找到暂时可替代的方案，或者某个权益之计，或者迭代个小版本，解决最核心问题；
当然，这个过程也不是产品经理一个人决定，往往需要业务「可能包含管理层」、产品、技术一起三方会议。
首先要搞清楚，排需求优先级的目标是为了做好产品版本规划，版本规划「迭代计划」的目的是为了更好的平衡用户利益和商业利益。
产品需求文档「PRD，Product Requirement Document」是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，用来承载当前版本的需求背景、产品方案、原型界面等内容的产品说明文档，通过文字描述每一个功能点每一个要素的数据来源，整个业务流程和逻辑，每一个页面模块按钮的交互效果，方便告诉前端和后端开发人员，最终要达到的根本效果。
写需求文档的过程，其实是检查遗漏或考虑不周的过程。
因为原型图并不能将所有内容全部呈现，需要文档进行补全。
同样，需求文档中的某些可行性存疑时，也要与开发人员沟通确认。
文档详细描述了一个产品的所有面向用户的功能需求、非功能性需求、性能要求等，为开发团队提供了明确的开发目标和方向，以供软件工程师正确地实现所有的用户需求。
对于商业性和业务性导向的产品，如赋能型产品，需要输出MRD，因为需要将市场、用户、业务、商业、竞争的情况说明。
Demo原型设计包括产品界面设计、交互设计等，很少有人知道产品经理还有另一个称呼「PD，Product Designer」产品设计师，从字面上可以窥见端倪，PD和PM 并不相同，PD更为纯粹，PM 则像是在 PD的基础上多增加了一管理的含义。
这要求不仅能设计好产品，还要管理好产品，为产品负责。
我相信很多人都想成为PD而非PM，梦想着自己设计的产品能够改变世界，而不是因为管理执行取得成功。
在我看来，产品的设计能力和管理运营能力都同等重要。
孰优孰略是一件很难有定论的事情，所以踏上产品经理这条道路那一刻就需要思考来来是想成为 PD 还是 PM，这决定了应该积累哪些能力以及发展的路径。
如果没有做好产品定义，不要轻易开始原型设计，因为会被自己设计的原型图框住思维，继而忘了本该做什么，或者加入了过多繁杂的体验设计，而没有解决真正的问题。
这也是很多产品经理在刚入行时容易犯的错，当然，也不乏这样的同行，所以很多小老板会将产品经理描述为“画图的”。
Demo需要考虑如何有效传达给项目相关同学、客户。
为了让关键页面有冲击力，使用高保真方式传达，可请设计师帮忙；
为了尽快的输出Demo，选择更适合的工具「AXURE、墨刀…」，用静态页面+规范美观的交互说明+生动的口述的方式传达；
为了让产品更加生动的展示，制作简短的视频，介绍产品的核心价值。
原型设计可分为线框图、原型图、高保真。
可以把线框图理解为设计图的骨干与核心，它承载着最终产品所有重要的部分。
绘制线框图，重点是「快」，可以使用手绘稿或用相关原型工具进行制作。
主要用于产品前期头脑风暴或需求沟通讨论阶段，非正式场合的团队内部交流等。用来激发思考和讨论，收集需求反馈等。
但是原型背后的逻辑不要依赖交互形式。
减少制作原型的成本，加快开发速度。
常用于做潜在用户测试。
在正式介入开发阶段前，以最接近最终产品的形式考量产品可用性。原型的直观和易懂倒使它成为最高效的设计文档。
通常来说，视觉稿就是视觉设计的草稿或终稿。在视觉稿定稿前，应与团队成员进行多方沟通和确认，以免造成沟通不足造成后期的返工。
视觉稿主要用于开发阶段收集用户反馈，同时帮助团队成员以视觉的角度审阅项目。
无论哪一种，都可以与设计师多交流，如设计规范、历史项目设计文档，可以从设计师那里获取到，是原型设计灵感的来源之一，并且在参考后可以避免一部分设计规范性问题，保证了用户体验。
根据产品设计的复杂度和团队资源情况，制定详细的项目计划，组织协调各方资源，确保项目按计划进行，确定项目的关键里程碑、交付物、时间节点等。
常见的项目关键里程碑包括项目审批、项目启动、关键项目交付物的完成、重要项目阶段的开始或结束日期，以及为项目开绿灯的重要事件等。这些里程碑事件不仅与项目的具体任务和工作内容紧密相关，还体现了项目的整体进展和关键决策点。
需求评审与确认，首先，将准备好的原型图和需求文档同步给相关设计、前端、后端、客户端开发、测试等人员，并开会将主要效果呈现，确保本次产品设计符合业务需求或用户需求，并具备可行性。
在评审会中，各方人员会就产品需求的各个方面进行讨论和评审，提出意见和建议，以确保产品需求的准确性、完整性和可行性。
然后沟通确认每个环节人员的开发排期时间。并将该时间与相关方同步，协调计划。
一般公司产品经理兼任项目经理的角色，因此UI设计图的交付、开发进度、上线的安排，都由产品经理把控。
与开发团队紧密合作，确保产品按照需求进行开发，可在测试环境体验产品，对与原型设计不符的地方提出修改意见。
监控开发进度，及时沟通开发人员的问题反馈，并及时给予明确信息和解决方案。
如果开发进度慢下来，需要找到原因，通过沟通或者协调资源，达成既定目标。
如果不及预期，需及时与相关方沟通，尤其是上线时间延后，可能带来某些业务的计划不能如期进行。
那在这个环节内，经常会衍生出一个问题。
产品经理需要懂技术吗？
我想听一下你们的答案，给大家三秒钟的时间，可以打在下方评论区我看一下。
3、2、1
OK。
这个问题在开篇提了一句。
现在咱么深入一下这个话题。
产品经理需要懂技术吗？懂到什么程度？
在公司里程序员是互联网产品经理在工作中打交道最多的人之一。
产品经理提需求给程序员，程序员将需求用代码实现。
通俗点来说呢。
就是一个提供菜单，一个负责做菜。
互联网的产品经理基本都是转行过来的，各个专业背景的都有，大部分产品经理是没有技术背景的。
也就是说提供菜单的人，很多却没有做过菜，更别说提供一份靠谱的菜谱了。
在实际工作中经常会看到产品经理提需求给程序员，程序员却告诉产品经理做不了或者要换方案。
然后双方就开启了Battle模式。
所以业内流传一句话说产品经理和程序员是相爱相杀。
会发生这样的原因，其实是产品经理和程序员考虑问题的角度不同。
一个从用户和业务角度出发。
一个从技术角度出发。
作为产品经理，为了让需求更容易推进、更容易落地，其实还是要懂点技术，并且学会理解技术。
当然，懂技术不是让产品经理去写代码。
而是了解互联网的一些基本技术和原理，如接口、MQ、多线程、实时请求、延时加载、异步导出等。
了解技术实现原理是为了评估出所采用的技术方案对用户或业务是否有感知，是否会影响到用户体验。
如异步导出，技术上实现的方式是将导出文件写入到临时文件，临时文件上传到OSS获取上传文件URL路径，记录URL文件到数据库中并删除临时文件，再通过单独页面查询导出文件列表，进行下载。
这样做的好处是避免导出数据量过大时，请求超时。
对于用户的影响是，用户进行导出操作后，不会将文件立即导出，可能需要等待一段时间，让用户去下载中心进行下载。
那么产品经理就要综合考虑技术和用户体验最终权衡利弊，决策出一个最优解决方案。
学会理解技术要求产品经理有时要站在技术角度了解不能实现原因和难度。
而不是一味地和技术说我就要这么做。
其实，很多需求可能只是产品经理自己YY出来的，需求不做或者进行一定妥协，对用户、对业务没有影响，反而能减少开发成本。
所以产品经理要懂点技术，并学会理解技术。
协调测试团队进行产品测试，确保产品质量符合预期，产品开发过程中，测试需要完成：「TC，测试用例」、「TC，评审」。
产品不必完成全部开发后才进行测试，可基于需求优先级，对完成的部分进行相关测试，如前端的功能和交互。
产品上线前需要进行完整的产品测试「包括黑白盒压力测试等」，并输出产品测试报告。
当产品通过测试后，产品经理和设计师需要对产品进行验收，确保最终效果和产品方案一致。
以上是产品经理大概的日常工作流程。
除此之外产品经理还需要具备
那这些能力其实并不是一朝一夕就能完全掌握的，需要产品经理在日常工作中通过持续的发展、深化、实践和积累来逐步培养和完善，同时在解决问题的过程中总结经验，优化自己的能力体系。
在实践、积累的过程中也可以适当学习并了解一些数据分析中所使用到的一些方法论，这块往往很容易被刚入行的产品经理忽视，他们往往觉得产品经理只需要会写需求，会画图就行，但其实很重要，例如swot分析法、5W2H、商业画布、北极星指数、用户生命周期、用户增长模型、AARRR、RFM模型等等
需要保持对行业领域的敏锐观察，了解当前行业的发展态势、结构性问题以及市场机会，通过深入分析，判断企业能否弥补行业中的不足或抓住新兴机会，评估资源供给是否足够，市场是否需要进一步教育，以及用户习惯和需求的变化，在此基础上，调整产品策略，确保产品既不过于老套，也不过于超前，而是能够与时俱进，紧跟市场潮流，从而保持产品的竞争力。
并充分考虑法律法规、人文风俗、公司需求、团队需求以及时空势，以确保产品既符合外部环境的要求，又能满足内部的需求。
同时还需要具备主人翁意识，即对自己所从事的工作充满热情与责任感，能够积极面对挑战，享受创造和协作的过程，对产品的整个生命周期负责。
这种意识源于个人的热情、开放心态和对提升自我的追求。
不仅能够提升个人的工作动力和效率，还能够带来用户的喜悦、同事的认可和职业发展的正反馈。
这期内容到这里就已经接近尾声，给大家介绍一些产品经理常用的软件工具，涵盖项目管理、团队协作、原型设计以及数据分析等多个方面。
另外，近些年出现的AI工具，也非常适合做调研分析。
写在最后
产品经理的工作，很累。
且不说过程中，收到各种各样来自不同岗位不同职位的质疑和挑战，特别是被设计师、被程序员、被运营人员怼到哑口无言，对一些相对玻璃心的人来说打击可能会比较大。
日常被很多不重要的事情，浪费自己的时间精力，忙忙碌碌但是不知道忙些什么？
关键事项的进度条却一直不推进，干着急，却毫无办法。
某个时刻，开始怀疑自己的产品能力，明明做了很多工作，也付出了很多努力。
但得到的回报很少，产品评价依然很差，不理解为什么？
我在工作时，早就发现这样或是那样的问题，解决办法是希望找一个方法或者工具帮我解决这些问题。
曾经研究过各种时间管理的方法，也尝试了很多，但效果甚微。
时间根本不可能管理，时间管理本质是一个投资游戏。
一个人每天只有24小时，如何合理分配时间才是关键。
道理谁都懂。
但是，什么工作是可以舍的或者推迟的？
一些只需要你参与但没有决策权的会议，就可以舍弃无效会议，让会议组织者把会议结论同步你即可。
又或者是对你来说没什么挑战性的工作内容，而且优先级没有那么高的事情，可以选择延期或者寻求产品助理的帮助。
… …
在工作的时候，发现很多牛逼的同事，他们每天会抽空1-2个小时去独自会议室办公，或者直接去楼下咖啡厅办公，当时，我认为他们又去偷懒摸鱼了。
但这是一个提高工作效率的高级做法。
可以留给你自己一些思考的时间，也可以减少思考被其他琐事打断的概率。
当然，这个方法最好用在氛围比较宽松的职场环境。
产品经理们都有一个执念「曾经我也有」，那就是希望自己的产品无限趋近于完美理想状态。
但是，现实却是一次次的失望。
这时候，你就会产生巨大的落差，最终产生内耗自责的问题。
但是，需要认识到产品或者项目永远是在范围、进度和成本这个三角形里跳舞。
每项资源都是有限的，追求满意即可。
世界上没有完美的事情，我们应该追求满足需求的完成，而不是无时无刻的完美，底线是完成可用，其他都是加分项。产品不可能一下子就达到完美的状态，需要一步一步来。
而这个一步一步可能比你想象的要长，要琐碎，迭代的次数要多。
但，这是正常的，只能慢慢的逐渐逼近。
到现在为止，我时不时还是有过度完美主义和责任感的毛病，只能逐步劝说自己放下。
有些产品经理有个臭毛病，喜欢指导别人的工作，随意的提出自己毫无验证的想法。
说实话，这个毛病非常吃力不讨好，费自己脑子，还不被别人认可。
但是，有的人就是控制不住自己，怎么办？
《被讨厌的勇气》这本书中指出：一切人际关系矛盾都起因于对别人的课题妄加干涉或者自己的课题被别人妄加干涉。
简单来说，别人的事情，少管，管好自己就行了。
工作上，辨别究竟是谁的工作方法非常简单，只需要考虑“这个选择所带来的结果最终要由谁来承担？”
对于别人的工作，不要随便干涉或给建议，避免和别人的事情过多纠缠。
但是，所有人都只关心自己，这个团队难免有点冷漠和无情。
有两个场景是可以提出自己意见的：
人家真心希望得到你的建议，这个时候建议的价值是最大的。
如果你看见非常明显的错误，或者存在明显的大坑。
但是，你也需要知道，你只是建议，采不采纳那是别人的事情，和你没有关系。
不要过多的在这个事情上浪费脑子。
随着工作经验的积累，我也在不断反思自己的职业道路和未来规划，开始思考自己真正想做的事情、能够做的事情以及自己的职业目标，选择一个适合自己的方向并为之付出努力，正如那句老话所说：“在时代的浪潮下，选择重于改变。”
最后，送一句话给产品经理们。
很多产品经理都经历过这个阶段，最终锻炼出强大的内心。
于是，我们恢复心情，微笑面对，继续完善产品方案。
我热爱产品经理的工作，
但是我更热爱生活。
本文由 @PM大明同学 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。