什么是产品经理？

那在内容开始之前，先问大家一个问题。

产品经理是谁？

who？

在日常事情中，大家是不是常常被问到类似的问题？

每当被问到类似问题时，我常常陷入沉思。

这彷佛也变成了一个「永恒的问题」。

每当逢年过节，与亲朋好友聚会时，总会碰着这样的对话：

亲友：“你是做什么事情的呢？”

我：“互联网行业。
”

亲友：“哦，那你一定很会用电脑吧！
”

我：“… 我是产品经理 … ”

亲友：“不错啊，都当上经理了！
”

我：“不是，产品经理并非传统意义上的‘经理’。
”

亲友：“那是什么？”

我：“… …”

每当被生手问及，我总是自嘲地回应：“产品经理嘛，实在便是个‘全能打杂的，或者救火队长，总之哪里须要去哪里’！
”

在日常事情中，产品经理这个角色须要阅读广泛，但又不可能做到样样精通，行业里也常常流传着一句话，“产品经理什么都要懂但什么都不精通”。

除了每天各种撕逼外，彷佛并没有一项真正善于且独一无二的技能。

而且每个团队对产品经理的期望和哀求也不尽相同。

就导致了一种普遍不雅观念，认为产品经理无非是链接业务和开拓的工具人。

–但是

事情并没有那么大略。

由于产品经理被哀求须要同时具备广度和深度。

那这个角色就注定了在很长一段韶光内都会被人误解。

先给大家分享一个小故事。

也是一个比较范例的案例。

100多年前，福特公司的创始人亨利福特师长西席到处跑去问客户：“您须要一个什么样的更好的交通工具？”险些所有人的答案都是：“我要一匹更快的马”。
很多人听到这个答案，于是立马跑到马场去选马配种，以知足客户的需求。

— 但

客户是真的想要一匹很快的马吗？

或许吧。

但福特师长西席却没有立马往马场跑，而是接着往下问。

福特：“你为什么须要一匹更快的马？”

客户：“由于可以跑得更快！
”

福特：“你为什么须要跑得更快？”

客户：“由于这样我就可以更早的到达目的地。
”

福特：“以是，你要一匹更快的马的真正用意是？”

客户：“用更短的韶光、更快地到达目的地！
”

然后福特就发明了汽车，很好的知足了的客户的需求。

嗯！

这个可能是一个很好的知足了这个客户以及一群客户的需求。

如果我们勾留在现有客户所说事物的表面，傻傻去找一匹很快的「马」，那现在可能就没有汽车了。

好的，这期内容正式开始。

产品经理「PM,Product manager」，在公司紧张卖力方案和管理某一项或某一类产品，紧张涉及产品的研发、制造、营销、渠道等事情。

2009 年360红衣教主周鸿祎，在媒体上强调自己是产品经理，后来，⻢化腾也说⾃⼰是产品经理，乔布斯也在媒体上被强调为产品经理，这三个⼈重新定义了⼤众理解的产品经理;

⼤家⼀想起产品经理便是CEO们的形象，大众会有认知误区：⼀⽅⾯，雷军、张⼀鸣、王兴、张小龙、乔布斯、 PeterDeng等多个有名企业创始⼈也强调过⾃⼰的产品经理⻆⾊。

产品经理须要具备产品思维，以用户的需求为导向，输出有用户代价、商业代价的产品。

同时，包括市场调研、产品定义及设计、项目管理、产品宣介、产品市场和产品生命周期管理等。

Marty Cagan 在他的《Inspired》书中将产品经理的事情描述为“创造有代价、可用和可行的产品”。
同样，我一贯将产品管理定义为业务、技能和用户体验之间的交集，一个好的产品经理必须至少在一个方面有履历，对这三个方面都充满激情亲切，并且熟习所有方面的从业者。

从上图角度出发，定义这三个观点以及三者之间的关系。

用户体验「UE/UX,User Experience」是许多人挂在嘴边的名词。

但这是一个多维度、相对主不雅观的观点，它涉及的是用户对我们供应的做事的整体感知，而非仅限于产品、运用、网站或设备等物理打仗点。

真正的用户体验关注的是做事的整体流程，包括但不限于APP页面之间跳转逻辑、界面的框架设计和布局、更要从全局思考整体业务流程。

之以是说用户体验是相对的、主不雅观的、片面的，是由于它依赖于个体用户的独特感想熏染和认知。

举个例子。

你去一家西餐厅吃牛排，牛排能不能吃，好不好吃是餐厅所能供应做事的核心，但当朋友们问起这次用饭的体验如何韶光，你脑中浮现的绝不仅仅是牛排的味道，可能还包括餐厅的门面，店内支配，桌椅摆放，做事职员的态度、相应韶光，菜单设计，看单点单流程，上菜的韶光和顺序，其他客人的用餐状态，以及买单和离开时的做事等一系列的体验，构成了你对朋友的回答：好，或不好。

这一系列影响用户体验的成分，都存在于用户脑中，而不仅只在我们作为餐厅运营和管理者的脑中。
作为产品经理，你如何定义这项做事中的每个关键成分，并环绕着关键点提升 UE ，就表示了你在这方面的专业素养。

产品经理用不用懂技能「E01 chnology」？？

这个话题一贯存在比较大的争议。

普遍的共识是：理解技能对付产品经理来说是至关主要的，这不仅有助于更好地定义产品的构建方向，还能在与开拓职员沟通时建立更深的信赖关系。

个中最主要的帮助便是信赖。

产品经理对打算机知识的理解程度和迭代频率，就像“水”的质量和流动性，理解的越多，越能帮助彼此理解双方的需求，相互认同。

对付产品经理而言，商业「Business」洞察力可能常常被放在“主要但不紧急”的象限中，这在互联网行业尤为明显。

商业的实质在于追求资金增长，通过成本运作和建立关系网络来规避风险，其深度和广度每每使得许多人对其保持敬畏，进而不愿或难以深入磋商。

要提升在商业方面的认知和能力，最直接的方法便是亲自参与商业实践，通过实际操作来学习和领悟。

除了这些，还可以努力将自己塑造成一个具有商业代价的人，以便在商业环境中更随意马虎被创造和认可。

在日常事情中，将关注点从“业务”或“业务逻辑”提升至更宏不雅观的“商业”层面，理解自己在公司整体计策中的位置和贡献，也是提升商业认知的主要一步。

前不久阅读了Josh Elman的文章《Let’s talk about Product Management》，个中一句话让我豁然开朗——“产品经理是帮助团队发布精确产品的关键角色”。
这句话精准地阐述了产品经理的核心职责和代价所在。

从产品的角度来看，产品流程紧张涵盖了从项目启动到项目扫尾的各个环节。

但一个项目从启动到扫尾是由多方共同协作的结果。
产品经理在个中扮演着“将idea/需求转化为产品”的角色，十分关键，精良的产品经理在项目中不仅仅着眼于产品本身，还包括与产品干系的人和事儿，因此让我们从产品经理事情职责内去看看产品经理视角下的事情流程。

常见的产品经理的事情流程，基本是需求管理、产品方案、项目管理。

实际上，产品经理一上来不是做产品方案，也不是做需求剖析，而是做需求管理。

由于要为用户做事，为商业做事，就得理解他们的需求和诉求。

网络需求和诉求的过程，须要面对的第一个问题便是沟通。

沟通能力是产品经理须要具备能力中比较主要的能力之一。

对内沟通：与部门领导、业务方领导和同事、运营等各侧沟通，网络需求；对外沟通：与客户、用户沟通，分产品阶段理解用户在用户体验流程方面的机会和痛点；线上沟通：通过问卷、社群、社区、线上会议等办法都可以是沟通渠道「有代价的内容每每不易获取，隐蔽在一句话中，捉住重点深挖到底“人性层面”，是有讲究的」。

沟通前，要想清楚沟通时紧张想办理的问题，有一点思考并能够陈述出来，随后与干系人发约请「邮件、微信等办法」；

沟通中，沟通前先闲聊几句进入正题，环绕目标进行沟通，做好记录，并在会议结束时确认沟通的内容，有条理的确认一遍「对方提出问题，要听清对方的问题，作出有条理的回答」；

沟通后，总结访谈内容/会议纪要，添加微信、组群、组织互换学习等。

沟通不仅仅是为理解用户的痛点、痒点、嗨点，也须要理解用户的期待和目标，大概用户已经为理解决问题考试测验了一些办法，大概这些办法是很可笑的，但还是须要尊重用户，作为产品经理只是帮助用户办理问题、更好的办理问题、规模化的办理问题，在做到这些的同时考虑商业化的办理问题。

产品经理必备的文件“需求池”，需求池是在网络需求中产生的，非常有必要做的一个表格，可以帮助你追踪、溯源、管理，详细内容如下图。

可以根据自己的须要建立自己需求池，这个非常主要，希望各位产品人能够养成利用的习气

需求池字段包含需求来源、获取日期、沟通人及联系办法、需求代价、需求类型、需求描述、问题点、需求优先级、备注等。

将网络到的需求尽可能详细的记录在内，尽可能的网络一手需求，刨根问底找到提出需求的那个人，让需求尽可能的靠近原始。

需求的初步的筛选和分类可先按以下办法进行分类，再通过内部需求评审详细的切磋定性「类型和优先级」。

1. 按产品属性划分新想法「Idea」：创新性的观点或不雅观点，为产品带来新的方向或可能性；新增「New Feature」：在现有产品根本上增加的新功能或特性；优化「Optimization」：对现有功能或流程进行改进，以提升用户体验或产品性能；Bugfix：修复产品中的缺点或毛病，确保产品稳定运行。

2. 按产品职能划分功能类需求：与产品核心功能直接干系的需求，是产品实现其目标所必需的；运营类需求：与产品运营和推广干系的需求，如数据剖析、用户增长等；数据类需求：涉及产品数据网络、剖析和运用的需求，用于辅导产品决策和优化；设计类需求：与产品界面、交互和用户体验设计干系的需求。

3. 按产品代价划分用户需求：终极用户对产品的期望和需求，关注办理用户问题和知足用户期望；商业需求：企业或组织对产品的需求，关注商业模式、市场需求等，以实现商业目标。

4. 按产品性子划分显性需求：用户直接表达出来的需求，可以通过市场调研、用户反馈等办法获取；隐性需求：用户未明确表达但潜在存在的需求，须要产品经理通过深入剖析和洞察来创造。

5. 按需求层次划分

根据马斯洛需求层次理论，产品需求可以划分为生理需求、安全需求、社交需求、尊重需求和自我实现需求。

这种分类办法有助于理解用户在不同层次上的需求，从而设计出更符合用户生理和行为的产品。

6. 按功能性和非功能性划分功能性需求：产品必须实现的详细功能或业务逻辑；非功能性需求：对产品的性能、可靠性、易用性等方面的哀求，如相应韶光、安全性等。

明确需求的背景，用户的画像，用户的目标，根据5W2H的构造化思考方法，用Y理论进行剖析。

7. 评估新需求对现有功能的影响用户体验：新需求的引入需细致剖析其对现有功能操作流程的影响，确保不增加用户操作繁芜度，同时评估其是否能提升用户体验，如界面直不雅观性和操作流畅性，并坚持与现有功能在界面设计和交互逻辑上的同等性，避免用户困惑。
技能实现：技能实现的难度、对现有技能架构的影响、开拓团队的技能能力和资源，以及新需求与现有功能在技能上的兼容性和可扩展性。
产品稳定性风险评估：引入后是否可能增加故障率、降落系统稳定性，评估必要的测试以确保其稳定可靠，并考虑其对现有功能性能的影响。
商业化：对产品市场竞争力、用户粘性和付费行为的提升浸染，评估其对长期商业代价的贡献，并考虑与现有功能在定价策略和市场推广上的协同效果。
对现有功能的优化与整合：是否能提升产品效能、拓宽利用范围，并考虑在数据、流程等方面的协同整合，以提升产品整体代价。

进行本钱评估须要综合考虑多个方面，包括直接本钱，如人力本钱「开拓、测试、运维等职员的人为和福利」、硬件和软件本钱「做事器、开拓工具、第三方做事等」、培训本钱等；以及间接本钱，如项目管理本钱、沟通本钱、风险掌握本钱等。
此外，还须要考虑韶光本钱，即完成需求所需的韶光周期，以及由此产生的延期风险和其他潜在本钱。

在评估过程中，可以采取多种方法和技能，例如，用事情量评估法来估算开拓团队完成需求所需的事情量，从而推算出人力本钱。
还可以利用类比评估法，参考类似项目的本钱数据来预测当前项目的本钱。

同时，为了更准确地评估本钱，还须要考虑一些关键成分。
如技能的繁芜性和新颖性，这可能会影响开拓难度和所需韶光；团队的技能和履历，这决定了事情效率和质量；市场的竞争状况和需求变革，这可能对产品的定位和功能需求产生影响。

每一个需求，环绕我们前面说的，都有其紧急主要程度，依次排优先级。

紧急度紧张看风险或者丢失量，主要度紧张看影响和波及面。

主要且紧急的，那我们就要往前排，反之则今后；

如果两个需求都同样紧急且主要，那我们就要参考需求处理周期和人力资源本钱成分。

不管是产品方案，还是开拓上线，都须要周期，也须要资源配置。

如果周期太长，而用户需求又急迫，我们就须要找莅临时可替代的方案，或者某个权柄之计，或者迭代个小版本，办理最核心问题；

当然，这个过程也不是产品经理一个人决定，每每须要业务「可能包含管理层」、产品、技能一起三方会议。

首先要搞清楚，排需求优先级的目标是为了做好产品版本方案，版本方案「迭代操持」的目的是为了更好的平衡用户利益和商业利益。

产品需求文档「PRD，Product Requirement Document」是产品项目由“观点化”阶段进入到“图纸化”阶段的最紧张的一个文档，用来承载当前版本的需求背景、产品方案、原型界面等内容的产品解释文档，通过笔墨描述每一个功能点每一个要素的数据来源，全体业务流程和逻辑，每一个页面模块按钮的交互效果，方便见告前端和后端开拓职员，终极要达到的根本效果。

写需求文档的过程，实在是检讨遗漏或考虑不周的过程。

由于原型图并不能将所有内容全部呈现，须要文档进行补全。

同样，需求文档中的某些可行性存疑时，也要与开拓职员沟通确认。

文档详细描述了一个产品的所有面向用户的功能需求、非功能性需求、性能哀求等，为开拓团队供应了明确的开拓目标和方向，以供软件工程师精确地实现所有的用户需求。

对付商业性和业务性导向的产品，如赋能型产品，须要输出MRD，由于须要将市场、用户、业务、商业、竞争的情形解释。

Demo原型设计包括产品界面设计、交互设计等，很少有人知道产品经理还有另一个称呼「PD，Product Designer」产品设计师，从字面上可以窥见端倪，PD和PM 并不相同，PD更为纯粹，PM 则像是在PD的根本上多增加了一管理的含义。

这哀求不仅能设计好产品，还要管理好产品，为产品卖力。

我相信很多人都想成为PD而非PM，梦想着自己设计的产品能够改变天下，而不是由于管理实行取获胜利。

02

在我看来，产品的设计能力和管理运营能力都同等主要。

孰优孰略是一件很难有定论的事情，以是踏上产品经理这条道路那一刻就须要思考来来是想成为 PD还是PM，这决定了该当积累哪些能力以及发展的路径。

如果没有做好产品定义，不要轻易开始原型设计，由于会被自己设计的原型图框住思维，继而忘了本该做什么，或者加入了过多繁杂的体验设计，而没有办理真正的问题。

这也是很多产品经理在刚入行时随意马虎犯的错，当然，也不乏这样的同行，以是很多小老板会将产品经理描述为“画图的”。

Demo须要考虑如何有效传达给项目干系同学、客户。

为了让关键页面有冲击力，利用高保真办法传达，可请设计师帮忙；

为了尽快的输出Demo，选择更适宜的工具「AXURE、墨刀…」，用静态页面+规范都雅的交互解释+生动的口述的办法传达；

为了让产品更加生动的展示，制作简短的视频，先容产品的核心代价。

原型设计可分为线框图、原型图、高保真。

1. 线框图紧张特点呈现主体信息群；勾勒出构造和布局；用户交互界面的主视觉和描述；线框图是一种低保真的静态图形，它勾勒出布局轮廓，但是短缺细节。

可以把线框图理解为设计图的骨干与核心，它承载着终极产品所有主要的部分。

绘制线框图，重点是「快」，可以利用手绘稿或用干系原型工具进行制作。

紧张用于产品前期头脑风暴或需求沟通谈论阶段，非正式场合的团队内部互换等。
用来引发思考和谈论，网络需求反馈等。

2. 原型图紧张特点包含完全的产品功能与交互流程；能够仿照终极产品的功能和交互；用于产品开拓前期进行用户体验测试；原型该当尽可能仿照终极产品，交互则该当精心模块化，只管即便在体验上和终极产品保持同等。

但是原型背后的逻辑不要依赖交互形式。

减少制作原型的本钱，加快开拓速率。

常用于做潜在用户测试。

在正式参与开拓阶段前，以最靠近终极产品的形式考量产品可用性。
原型的直不雅观和易懂倒使它成为最高效的设计文档。

3. 高保真紧张特点表达信息框架，静态演示内容和功能；帮助团队成员以视觉的角度审阅项目；视觉稿是高保真的静态设计图。

常日来说，视觉稿便是视觉设计的草稿或终稿。
在视觉稿定稿前，应与团队成员进行多方沟通和确认，以免造成沟通不敷造成后期的返工。

视觉稿紧张用于开拓阶段网络用户反馈，同时帮助团队成员以视觉的角度审阅项目。

无论哪一种，都可以与设计师多互换，如设计规范、历史项目设计文档，可以从设计师那里获取到，是原型设计灵感的来源之一，并且在参考后可以避免一部分设计规范性问题，担保了用户体验。

根据产品设计的繁芜度和团队资源情形，制订详细的项目操持，组织折衷各方资源，确保项目按操持进行，确定项目的关键里程碑、交付物、韶光节点等。

常见的项目关键里程碑包括项目审批、项目启动、关键项目交付物的完成、主要项目阶段的开始或结束日期，以及为项目开绿灯的主要事宜等。
这些里程碑事宜不仅与项目的详细任务和事情内容紧密干系，还表示了项目的整体进展和关键决策点。

4. 交付物「以软件产品的交付物为例」软件产品本身：这是最紧张的交付物，须要是一个完全、可用且功能完好的软件产品，知足客户的所有需求，并确保其稳定可靠；用户文档和操作手册：须要详细描述软件产品的利用方法、操作流程，以及常见问题的解答等内容，旨在帮助用户更好地理解和利用软件产品；源代码和编译环境：供应软件开拓过程中的源代码以及编译环境，这样客户就能根据须要对软件进行二次开拓、修正和扩展；技能文档息争释书：包括软件架构、设计思路、技能实现、测试记录等干系文档，为软件的后续掩护和升级供应了主要的支持；培训和支持：供应必要的培训和技能支持，确保用户能够顺利地利用软件产品，并办理在利用过程中可能碰着的问题；保修和掩护：对软件产品的质量和稳定性进行担保，供应一定期限内的免费掩护和更新做事。
知识产权和授权：明确软件产品的知识产权归属和利用授权范围，确保项目交付符合干系法律法规的哀求。

需求评审与确认，首先，将准备好的原型图和需求文档同步给干系设计、前端、后端、客户端开拓、测试等职员，并开会将紧张效果呈现，确保本次产品设计符合业务需求或用户需求，并具备可行性。

在评审会中，各方职员会就产品需求的各个方面进行谈论和评审，提出见地和建议，以确保产品需求的准确性、完全性和可行性。

然后沟通确认每个环节职员的开拓排期韶光。
并将该韶光与干系方同步，折衷操持。

一样平常公司产品经理兼任项目经理的角色，因此UI设计图的交付、开拓进度、上线的安排，都由产品经理把控。

与开拓团队紧密互助，确保产品按照需求进行开拓，可在测试环境体验产品，对与原型设计不符的地方提出修正见地。

监控开拓进度，及时沟通开拓职员的问题反馈，并及时给予明确信息和解决方案。

如果开拓进度慢下来，须要找到缘故原由，通过沟通或者折衷资源，达成既定目标。

如果不及预期，需及时与干系方沟通，尤其是上线韶光延后，可能带来某些业务的操持不能准期进行。

那在这个环节内，常常会衍生出一个问题。

03 产品经理须要懂技能吗？

我想听一下你们的答案，给大家三秒钟的韶光，可以打不才方评论区我看一下。

3、2、1

OK。

这个问题在开篇提了一句。

现在咱么深入一下这个话题。

产品经理须要懂技能吗？懂到什么程度？

在公司里程序员是互联网产品经理在事情中打交道最多的人之一。

产品经理提需求给程序员，程序员将需求用代码实现。

普通点来说呢。

便是一个供应菜单，一个卖力做菜。

互联网的产品经理基本都是转行过来的，各个专业背景的都有，大部分产品经理是没有技能背景的。

也便是说供应菜单的人，很多却没有做过菜，更别说供应一份靠谱的菜谱了。

在实际事情中常常会看到产品经理提需求给程序员，程序员却见告产品经理做不了或者要换方案。

然后双方就开启了Battle模式。

以是业内流传一句话说产品经理和程序员是相爱相杀。

会发生这样的缘故原由，实在是产品经理和程序员考虑问题的角度不同。

一个从用户和业务角度出发。

一个从技能角度出发。

作为产品经理，为了让需求更随意马虎推进、更随意马虎落地，实在还是要懂点技能，并且学会理解技能。

当然，懂技能不是让产品经理去写代码。

而是理解互联网的一些基本技能和事理，如接口、MQ、多线程、实时要求、延时加载、异步导出等。

理解技能实现事理是为了评估出所采取的技能方案对用户或业务是否有感知，是否会影响到用户体验。

如异步导出，技能上实现的办法是将导出文件写入到临时文件，临时文件上传到OSS获取上传文件URL路径，记录URL文件到数据库中并删除临时文件，再通过单独页面查询导出文件列表，进行下载。

这样做的好处是避免导出数据量过大时，要求超时。

对付用户的影响是，用户进行导出操作后，不会将文件立即导出，可能须要等待一段韶光，让用户去下载中央进行下载。

那么产品经理就要综合考虑技能和用户体验终极权衡利弊，决策出一个最优办理方案。

学会理解技能哀求产品经理有时要站在技能角度理解不能实现缘故原由和难度。

而不是一味地和技能说我就要这么做。

实在，很多需求可能只是产品经理自己YY出来的，需求不做或者进行一定妥协，对用户、对业务没有影响，反而能减少开拓本钱。

以是产品经理要懂点技能，并学会理解技能。

折衷测试团队进行产品测试，确保产品质量符合预期，产品开拓过程中，测试须要完成：「TC，测试用例」、「TC，评审」。

产品不必完玉成体开拓后才进行测试，可基于需求优先级，对完成的部分进行干系测试，如前真个功能和交互。

产品上线前须要进行完全的产品测试「包括黑白盒压力测试等」，并输出产品测试报告。

当产品通过测试后，产品经理和设计师须要对产品进行验收，确保终极效果和产品方案同等。

上线前，须要做好相应准备，比如上线的韶光选在用户不常用的时段，避免涌现问题；比如选择灰度发布，比如选择A/B测试，比如数据的洗濯、迁移，或者培植。
其余，可能涉及与业务或运营团队的合营，进行产品推广和营销活动。
末了上线后，不雅观测产品运行情形，有问题要及时处理，如果不能处理，就只能回滚版本，网络用户反馈，对产品进行持续优化和改进。
项目结束后，对全体项目进行总结，剖析成功成分和不敷之处，持续搜集用户利用情形，将需求和问题，搜集到需求池，产品不是一步到位、一挥而就的，而是不断在实践中完善的。
推向市场必定会收到用户反馈，无论是差评，还是建议，或者市场发生变革，都可以让我们开启新一轮产品方案，对产品进行持续优化和迭代。
其余，我们也须要故意识地管理产品的生命周期，确保产品始终保持竞争力。
方案产品的未来发展方向和新技能运用。
剖析产品的用户数据和市场表现，关键指标的数据是否提升。
识别产品的上风和潜在改进点，为产品决策供应数据支持。
尤其是做某个垂直领域或者某个模块的产品经理，在事情中会有特殊明确的数据指标，这些是过去长期积累下来对月业务增长具有关键浸染的指标，常日将数据的增长，当做申报请示古迹的详细成果和呈现。
外界也更随意马虎在短韶光内理解我们的代价和结果。

以上是产品经理大概的日常事情流程。

除此之外产品经理还须要具备

逻辑能力：具备清晰的思维，能够理解并运用产品、技能、业务和商业逻辑，高效地办理问题和提高协作效率；沟通能力：善于人际交往，能够理解并应对个体差异，通过聆听、不雅观察、提问和勉励来推动事情进展；剖析能力：能够客不雅观地搜集和剖析信息，具备独立判断力，能够从不同角度和角色进行思考，创造问题的关键点；创造能力：具有创新思维，能够抽象和归纳问题，快速找到办理方案，并乐意不断考试测验和验证新想法；方案能力：能够清晰地呈现业务和数据逻辑，编写详尽的需求文档和原型图，以及进行有效的版本方案，确保产品迭代知足用户和商业需求；学习能力：保持开放心态，不断学习新知识和技能，适应新环境和寻衅，以促进个人和产品的持续发展。

那这些能力实在并不是一朝一夕就能完备节制的，须要产品经理在日常事情中通过持续的发展、深化、实践和积累来逐步培养和完善，同时在办理问题的过程中总结履历，优化自己的能力体系。

在实践、积累的过程中也可以适当学习并理解一些数据剖析中所利用到的一些方法论，这块每每很随意马虎被刚入行的产品经理忽略，他们每每以为产品经理只须要会写需求，会画图就行，但实在很主要，例如swot剖析法、5W2H、商业画布、北极星指数、用户生命周期、用户增长模型、AARRR、RFM模型等等

须要保持对行业领域的敏锐不雅观察，理解当前行业的发展态势、构造性问题以及市场机会，通过深入剖析，判断企业能否填补行业中的不敷或捉住新兴机会，评估资源供给是否足够，市场是否须要进一步教诲，以及用户习气和需求的变革，在此根本上，调度产品策略，确保产品既不过于老套，也不过于超前，而是能够与时俱进，紧跟市场潮流，从而保持产品的竞争力。

并充分考虑法律法规、人文风尚、公司需求、团队需求以及时空势，以确保产品既符合外部环境的哀求，又能知足内部的需求。

同时还须要具备主人翁意识，即对自己所从事的事情充满激情亲切与任务感，能够积极面对寻衅，享受创造和协作的过程，对产品的全体生命周期卖力。

这种意识源于个人的激情亲切、开放心态和对提升自我的追求。

不仅能够提升个人的事情动力和效率，还能够带来用户的喜悦、同事的认可和职业发展的正反馈。

这期内容到这里就已经靠近尾声，给大家先容一些产品经理常用的软件工具，涵盖项目管理、团队协作、原型设计以及数据剖析等多个方面。

⾏业报告：CNbeta、易不雅观智库、艾瑞咨询、亿邦动⼒⽹、天下⽹商、InfoQ、36⼤数据、App Annie、百度指数项⽬管理⼯具：TAPD、Tower、Teambition、Worktile、Workflow、禅道、Project、SVN在线⽂档协作：⽯墨⽂档、腾讯⽂档、Notion、语雀、幕布、OneNote、Quip、Trello脑图 & 流程图：MindMaster、Xmind、Mindjet、MindNode、ProcessOn、BullMind、百度脑图原型⼯具：Axure、Sketch、墨⼑、Mockplus、xiaopiu素材⽹站：iconfont、堆糖、花瓣、Pixabay、汤不热、昵图⽹、Pexels、视觉中国PPT素材：OfficePLUS、PPTMind、PPT设计教程⽹、presentationload、变⾊⻰、优品、51PPT问卷调查：腾扣问卷、问卷星、调查派、问卷网麦克、番茄表单第三⽅数据剖析：神策数据、诸葛iO、友盟、growingIO、⽹易⼤数据、GA、极光⼤数据、百度统计、Talkingdata指数：百度指数、阿⾥指数、艾瑞咨询、友盟指数、爱奇艺指数、猫眼专业版、易不雅观千帆、CNbetaApp数据：七⻨数据、易不雅观数据、腾讯移动剖析

其余，近些年涌现的AI工具，也非常适宜做调研剖析。

写在末了

产品经理的事情，很累。

且不说过程中，收到各种各样来自不同岗位不同职位的质疑和寻衅，特殊是被设计师、被程序员、被运营职员怼到哑口无言，对一些相对玻璃心的人来说打击可能会比较大。

日常被很多不主要的事情，摧残浪费蹂躏自己的韶光精力，忙劳碌碌但是不知道忙些什么？

关键事变的进度条却一贯不推进，干焦急，却毫无办法。

某个时候，开始疑惑自己的产品能力，明明做了很多事情，也付出了很多努力。

但得到的回报很少，产品评价依然很差，不理解为什么？

我在事情时，早就创造这样或是那样的问题，办理办法是希望找一个方法或者工具帮我办理这些问题。

曾经研究过各种韶光管理的方法，也考试测验了很多，但效果甚微。

韶光根本不可能管理，韶光管理实质是一个投资游戏。

一个人每天只有24小时，如何合理分配韶光才是关键。

道理谁都懂。

但是，什么事情是可以舍的或者推迟的？

一些只须要你参与但没有决策权的会议，就可以舍弃无效会议，让会议组织者把会议结论同步你即可。

又或者是对你来说没什么寻衅性的事情内容，而且优先级没有那么高的事情，可以选择延期或者寻求产品助理的帮助。

… …

在事情的时候，创造很多牛逼的同事，他们每天会抽空1-2个小时去独自会议室办公，或者直接去楼下咖啡厅办公，当时，我认为他们又去偷

但这是一个提高事情效率的高等做法。

可以留给你自己一些思考的韶光，也可以减少思考被其他琐事打断的概率。

当然，这个方法最好用在氛围比较宽松的职场环境。

产品经理们都有一个执念「曾经我也有」，那便是希望自己的产品无限趋近于完美空想状态。

但是，现实却是一次次的失落望。

这时候，你就会产生巨大的落差，终极产生内耗自责的问题。

但是，须要认识到产品或者项目永久是在范围、进度和本钱这个三角形里舞蹈。

每项资源都是有限的，追求满意即可。

天下上没有完美的事情，我们该当追求知足需求的完成，而不是无时无刻的完美，底线是完成可用，其他都是加分项。
产品不可能一下子就达到完美的状态，须要一步一步来。

而这个一步一步可能比你想象的要长，要噜苏，迭代的次数要多。

但，这是正常的，只能逐步的逐渐逼近。

到现在为止，我时时时还是有过度完美主义和任务感的毛病，只能逐步奉劝自己放下。

有些产品经理有个臭毛病，喜好辅导别人的事情，随意的提出自己毫无验证的想法。

说实话，这个毛病非常吃力不谄媚，费自己脑筋，还不被别人认可。

但是，有的人便是掌握不住自己，怎么办？

《被讨厌的勇气》这本书中指出：统统人际关系抵牾都起因于对别人的课题妄加干涉或者自己的课题被别人妄加干涉。

大略来说，别人的事情，少管，管好自己就行了。

事情上，辨别究竟是谁的事情方法非常大略，只须要考虑“这个选择所带来的结果终极要由谁来承担？”

对付别人的事情，不要随便干涉或给建议，避免和别人的事情过多纠缠。

但是，所有人都只关心自己，这个团队难免有点冷漠和无情。

有两个场景是可以提出自己见地的：

人家至心希望得到你的建议，这个时候建议的代价是最大的。

如果你瞥见非常明显的缺点，或者存在明显的大坑。

但是，你也须要知道，你只是建议，采不采纳那是别人的事情，和你没有关系。

不要过多的在这个事情上摧残浪费蹂躏脑筋。

随着事情履历的积累，我也在不断反思自己的职业道路和未来方案，开始思考自己真正想做的事情、能够做的事情以及自己的职业目标，选择一个适宜自己的方向并为之付出努力，正如那句老话所说：“在时期的浪潮下，选择重于改变。
”

末了，送一句话给产品经理们。

很多产品经理都经历过这个阶段，终极磨炼出强大的内心。

于是，我们规复心情，微笑面对，连续完善产品方案。

我热爱产品经理的事情，

但是我更热爱生活。

本文由 @PM大明同学 原创发布于大家都是产品经理。
未经作者容许，禁止转载

题图来自Unsplash，基于CC0协议

该文不雅观点仅代表作者本人，大家都是产品经理平台仅供应信息存储空间做事