端产品经理工作指南

　　我总是觉得对产品经理这个岗位也好，对其他职位也罢，最重要的特性在于，工作的方法、思考的维度、事件的能力。
　　在跟你坦白说我的工作指南之前，我在脑海里经过飞快的运算，在那仅有的0.1%的概率计算的基础上，我脑补了下市场上的产品经理的职能，我发现其背后的影响因素差异很大。他们无关乎就为以下几个方面：能力、素质、岗位、绩效、资历、博弈、评审问题，或者再怎么多描述都不为过。
　　大多数企业会更在意你有几年经验、大公司的、产品知名的、管人多的、学校好的、懂技术等等，会给很多新入门或未入门的产品经理很大的门槛和遐想，有些时候产品经理这个工作指南就更缺乏标准化的有效评估。如果你是按照这些去衡量和评估自己和发展自己，那我只能跟你说，麻烦了。
　　现在的产品经理会有很多类别，工作内容都是从简单到复杂，循序渐进。对产品经理来说，在不同行业、不同企业、不同阶段、不同团队认知、产品分工和工作内容都是不一样的，而且还会与多个职业相互交叉。
　　举个例子：A公司希望他的产品经理是能够将公司产品的前台、中台、后台完全抓起来，B公司希望他的产品经理是能够将前端展示，用户业务流程抓起来，C公司希望他的产品经理能够根据客户需求规划产品，并根据公司战略将该产品市场化。那你来想一想。
　　一个好的产品经理的价值大小，我觉得可用经验、智慧、平台三个维度来体现，天时地利人和或许就是成就一个好的产品经理关键要素。当然，这一点如果你懂，那么你就懂，如果不懂，那么就不懂。实际来看，对任何一个企业来说，关心的还是这个产品经理对于企业的边际贡献值。
　　这么一想，你思考一下，每个公司的产品经理的工作要求会一样吗？你认为B端产品经理有多高大上的工作吗？你理解的产品经理就是产品经理吗？那么什么才是一个好的产品经理？
　　接下来，以我自身作为产品经理的经历来讲一讲我所从事或参与的工作指南是怎么样的。
　　1. 开始市场分析调研
　　每个人都在说产品调研，每个领导也在抓市场分析，每个产品经理也都在行业深究，方式方法千奇百怪，有来自对手的，有来自公司人员的，有来自客户的，也有来自技术趋势的，也有来自产品本身发展，也有来源市场。
　　这一块我的工作指南一般会按照以下几个内容来完成：
　　1.1 搜寻现有客户或潜在客户，了解客户对产品的需求、期望
　　需求一般从哪里来，就是从客户的拜访或访谈中来，从市场前端人员的需求背景来，从对行业分析的需求问题来，从与各方为人员的间接沟通来，从产品对市场的期望来，从后台对产品的稳定性来，这些所有的需求都规整到产品需求池。
　　我自身的工作指南如下：
　　找到3-5个客户进行拜访或访谈。占比20%。
　　从核心前端市场人员（2个行业，3个前场）了解客户需求背景。占比15%。
　　针对行业的国内外需求梳理，形成客户需求问题走向。占比20%。
　　与各方人员（包括领导、产品、研发、售后、客服、市场）沟通、补充和完善访谈内容。占比10%。
　　记录客户对产品的期望、功能价值的关注（包括采购意愿、预算成本）。占比20%.
　　在后端对需求池信息进行处理，甄别市场需求，找到商业机会。占比15%。
　　2. 进行竞品分析，了解竞品的走向、优势功能、卖点等信息
　　没有什么比来自对手的分析最为可靠的需求，产品人会因为各种杂事琐事而充分没有理由去充分研究产品的市场形态走向，但对手的研究是最具备参考价值和意义的。通常，只有找准产品的定位，做好产品在行业里的差异化、市场化才会具备市场的竞争力。
　　我自身的工作指南如下：
　　网络搜索：最原始的找竞品对手资料。占比10%。
　　客户拜访：客户是实际的业务来源，他们会使用很多家的不同类型产品，跟他们打好交道，你就能获取到其他家产品的情况，当然，难度也是比较大的。占比15%。
　　前端人员交流：他们最接触一线，对竞争对手的情况最为清楚，不管是营销玩法，还是落地方式，他们都有一定的发言权。占比15%。
　　拟写竞品报告：对竞品的优劣势、客户群体细分、商业报价、市场规模等形成初步结论。占比5%。
　　不断的Review产品形态：对于技术型产品来说，如区块链技术、5G技术，如何通过技术去孵化出适用不同场景的产品形态，这个工作才是最难最多的。占比55%。
　　3. 了解行业的特性和规则（政策法规）
　　对行业政策的规则了解是做产品经理最要关心的，比如支付行业要关注行业支付的手续费规则、分账实现的规则的等，5G行业要关注各区域5G基站建设规划、各客户对5G技术落地的要求等，区块链行业要关注国家对这一块的政策和监管手段、技术落地的利好等。要行业，也要专业。当然，远远不止我说的几个点，但作为产品经理，你只有关注这些，你的产品才能站得稳，走的远。
　　我自身的工作指南如下：
　　定位产品面向的群体、群体所在的行业，剖析行业现状。占比20%
　　对客户群体进行行业方案分析。占比25%。
　　获取产品在行业中的定位以及相关的政策法规。占比20%。
　　分析行业方案，纳入产品规划。占比15%。
　　查阅相关行业报告、文章，了解市场走向。占比10%。
　　参加论坛、研讨会等。占比10%。
　　2. 进行产品设计
　　产品经理遇到最多的就是，需求池里的需求永远做不完。市场来源的需求永远是无休止尽的，产品的发展永远是有生命周期的。如何利用有限的资源做好有限的事，是每个人产品经理要必备的一个技能之一，也是要求之一。研发需要成本，市场需要成本，公司发展需要成本，所以你在设计产品的时候，投入与产出绝对是困扰自身做产品经理的一个重要因素。
　　这一块我的工作指南一般会按照以下几个内容来完成：
　　2.1 收集原始需求，优先级排序
　　最原始的需求池建立，是每个产品经理都会整理的日常任务。今天客户有一个需求，明天运营又有一个需求，后天老板又有一个需求，需求的来源无穷无尽。如果是项目制的产品，那么需求或许就会更确定的清晰和梳理。但如果是产品型的产品，那么你的需求只能用做不完来形容。所以，如果你是一个产品经理，你手里面没有需求，那只能说明你对你的产品还没有负责到底。
　　我自身的工作指南如下：
　　整理市场调研拜访需求结论。占比10%
　　整理客户对产品使用的直接反馈。占比10%。
　　从网络资源、对手获取需求点。占比5%。
　　向前端传递原始需求征询反馈。占比20%。
　　产品结构、技术、架构、性能等产品本身需求。占比25%。
　　从其他部门，如产品资质、市场宣传、产品运营获取。占比10%。
　　战略方向需求（来源于领导、战略部门）。投入占比20%。
　　2.2 对需求进行分析评审，确定产品需求
　　作为产品经理，你是产品的主导者，但所有的市场行为、迭代行为一定是所有人都认可的，投入是有价值的。比如你是为了PK对手而增加的功能，还是为了提升市场竞争力，还是为了满足售后服务需求，当然你得组织评审讨论下。当然，小团队敏捷开发的话，以实际客户需求和行业需求为主。
　　我自身的工作指南如下：
　　初步评估和记录产品原始需求点。占比25%。
　　讨论产品原始需求，定义产品需求池、产品迭代、产品开发、产品商业。占比35%。
　　对原始需求讨论，归类优先级，还有投入产出价值比。占比25%。
　　输出产品设计需求，归档。占比15%。
　　2.3 根据产品需求，定义产品原型
　　原型这个词就不陌生，需求定义清楚，就要开始原型化设计。大多数的原型都包括低保真设计、有高保真设计，甚至还需要需求文档一说。大都只归结于一点，能够很好的描述你的需求。
　　现在，行业有个怪现象，产品经理过度执着于原型的设计，过度执着于文档的书写编制，求职者也过度执着自己对原型软件的技能。产品原型可以是有纸质手画的、有直接口述的、有PPT编制的、有专业软件制作的（诸如Axure、mocplus之类）、有播放视频的方式、有对手的上线版、有行业的测试原型等等。我个人觉得，输出的方式有很多种，选择适合你的需求展示，以及开发同事认可的方式。
　　我自身的工作指南如下：
　　设计产品的输入输出，形成产品概要原型。占比35%。
　　思考原型设计的方式，最符合当前需求的原型展示。占比25%。
　　借鉴竞品或行业同类产品的交互界面。占比10%。
　　初始原型讨论，定义和完善。占比25%。
　　最终原型确认。占比15%。
　　2.4 进行产品概要和详细设计
　　这是谁的活一直都有争议，有说是产品经理的工作，有说是开发人员的工作。我个人觉得各占一半均衡一点，也不完全偏向哪一边。产品经理最好是要主导产品的概要和详细设计工作，细节内容可以由开发人员、产品经理、测试人员等共同商讨确定细节设计方案。
　　我个人就会偏向于功能、架构侧方面的参与：一是我的需求点的明细，二是我对产品迭代的要求。
　　我自身的工作指南如下：
　　拟写产品需求功能书或规格书。占比30%。
　　给开发、测试人员详细介绍产品需求点。占比25%。
　　对核心功能加深商业场景设计（目的是让开发了解功能的延展性和商业性）。占比10%。
　　主导需求功能侧的概要、详细设计评审。占比20%。
　　参与开发、测试人员评审会（包括概要设计、详细设计、测试计划等评审）。占比15%。
　　3. 产品开发管理
　　产品的开发管控有时候是项目经理或研发经理在负责，但绝大部分都是由产品经理进行主导把控的。所以我觉得，产品经理要有参与到开发过程中的耐心，要有跟开发人员、测试人员互动的过程，这就很重要了。过程的开发把控，实际开发情况的风险把控，以及需求完成的把控，这些对产品按时上线都是至关重要的。
　　这一块我的工作指南一般会按照以下几个内容来完成：
　　3.1 梳理产品Roadmap，明确迭代开发范围
　　有很多人或许会问，定义产品Roadmap的价值点是为什么，作为产品经理只需顾好当前的需求就行。但是，很多坑就是这样被产品经理埋下的，当然后面还得你自己去填坑。一个好的产品经理，首先站的角度一定是企业，其次才是用户，想歪了你就不是一个合格的产品经理。这种话不是废话官话，而是在跟你阐述你给自己在企业的定位，跟着企业发展走，你的产品才能走的更远。过度沉溺在自己的产品世界里，早晚会吃亏。
　　我自身的工作指南如下：
　　梳理产品Roadmap计划。占比15%。
　　将产品需求录入需求Backlog，定义Sprint。占比25%
　　对开发需求进行优先级排序。占比15%。
　　讨论任务细分、人员分工（不超过两天）。占比15%。
　　确定迭代计划功能，启动sprint。占比10%。
　　甘特图追踪任务进度，关键时间节点区分。占比10%。
　　明确化迭代开发内容，时间安排及发布时间。占比10%。
　　3.2 负责迭代开发的过程管理
　　整体开发的过程管理包括启动过程、计划过程、执行过程、监控过程、收尾过程等诸多方面，作为产品经理，要能在每个环节融入到开发团队去，做好开发、测试、运营的配合，才是一个合格的有产品心的团队。
　　但是，或疏于自己工作职责划分的缘故，也有产品经理会置之这一块内容。现在网上有很多人在讨论开发与产品的矛盾，还有偏激的看法，但实际你是不参与实际的开发工作，而是你的角色从主导者变成了配合者，你参与的只是开发过程中的过程管理。还有，这个过程不等同于任务进度管理，也不同等于产品开发管理。
　　我自身的工作指南如下：
　　每1周或2周按Sprint更新任务进度。占比20%
　　组织每日晨会：昨天的工作，今天的工作，遇到的问题。占比35%。
　　检查任务迭代情况。占比20%。
　　控制迭代范围的变更。占比20%。
　　其他事项管理。占比5%。
　　3.3 验收需求的实现情况
　　产品经理有验收需求的标准，是有助于大家对目标需求的一致理解、对目标需求的最终确认、对目标需求的实现验证。当然，需求实现的验证是通过测试来实现的，产品经理要最终根据预先需求定义以及给测试传递的预期结果进行划分和充分结合，验证和确认需求的完成度。必要时，还需要上线试运行，或者由客户来试运行测试和验收需求。
　　我自身的工作指南如下：
　　All tasks closed。占比20%。
　　功能演示，核对产品功能。占比40%。
　　确认功能符合预期。占比20%。
　　迭代回顾会议，总结存在的问题。占比10%。
　　下一步需求验证计划。占比10%。
　　4. 产品发布管理
　　这个对产品经理来说，是有误区的，大家都会潜意识认为开发和测试才是最重要的，在这方面投入更大的精力和时间，反而对产品发布的环节不重视。但实际上，我们可能会因为一些产品发布工作没有做好，导致产品问题的出现，严重的会导致产品不能正常使用。
　　产品的发布主要是用于指导产品到市场的过程。需要做好的事，指导发布活动，有效控制产品发布过程，继而有效的控制和追踪产品版本。
　　这一块我的工作指南一般会按照以下几个内容来完成：
　　4.1 区分对内发布和对外发布。
　　对任何一个产品来说，最激动的就是要发布了。通常会分为对内发布和对外发布两种。对内发布也分为两方面，对产品开发的发布，以及对市场运营的发布。对外发布是面向客户/用户的发布，通常是配合在试运行阶段进行发布。
　　整体发布的方式分为很多种，我们常见的发布方式有：邮件发布、培训发布、市场发布、培训发布、大规模会议发布等。
　　我自身的工作指南如下：
　　对内发布。占比40%。
　　对外发布。占比60%。
　　4.2 产品版本的发布和归档
　　发布过程中对产品经理来说，最重要的两件事是发布和归档。尤其对于B端产品来说，产品版本的控制一定是要合理区分的，大多数都包含产品开发的版本、产品内部发布的版本、产品对外发布的版本、产品多语种发布的版本、产品交付的版本、产品升级的版本等，当然相应的也得有命名规范。
　　如果是小团队敏捷开发产品，也会大概包含2-3种发布的版本。针对每个产品不同的使用场景，产品发布的版本也会明显的反映出一个产品的发展迭代历程或生命周期，做好发布和归档很重要。
　　我自身的工作指南如下：
　　发布归档。占比70%。
　　规划版本图。占比30%。
　　4.3 准备对应的发布内容
　　通常来说，发布内容不仅仅是产品的发布，也会涉及到内容的发布。要让别人理解产品发布的功能、价值、以及市场占有率等，必要的文档输出是不可少的。
　　如果是做完整的B端PGM质量管控，那么至少就会包含技术白皮书、功能清单、版本更新说明、测试报告（对内、对外）、竞品功能技术分析（目的POC测试）、产品功能演示文档（目的POC测试）、产品部署文档（对内）、产品售后问题清单、用户使用手册（多语种）、销售一指禅(商务、技术）、培训资料（对内、对外）等等一整套产品相关资料。当然，这里不包括BRD、PRD等。但实际上，每个企业的实际情况不一样，产品经理根据实际情况进行准备发布资料即可。
　　我自身的工作指南如下：
　　产品文档编写。占比70%。
　　其他文档更新。占比20%。
　　版本更新说明。占比10%。
　　4.4 对外宣布新产品或版本正式版本
　　充分Check你的产品迭代配套资料完善不完善，准备的工作做的怎么样，上线前的准备工作怎么样，当Everything is OK，那么你就可以开始对内发布。
　　我自身的工作指南如下：
　　收集产品资料归档。占比10%。
　　对内发布告知。占比90%。（邮件占比10%，会议占比45%，市场宣导发布45%）
　　4.5 沟通运维产品上线
　　一个完整的产品上线过程过程都会包括上线资源协调、上线部署、上线监控、问题处理等阶段。通常，我们为了确保产品上线的稳定性，会先开始区域化的试运行测试，再慢慢开始全局发布，这个时候产品经理和测试人员会全程参与。
　　我自身的工作指南如下：
　　整理部署需求。占比10%。
　　沟通运维上线产品。占比15%。
　　试运行测试。占比35%。
　　上线全部署、监控和问题处理。占比30%。
　　问题记录反馈。占比10%。
　　5. 产品发布培训
　　在产品发布培训阶段，会涉及到产品的释义、目标受众及应用场景、产品的原理及迭代、产品功能说明及演示、产品使用说明、功能用途展示、产品的优劣势机会威胁、产品的定位及策略分析、产品的行业趋势、产品的竞争分析、产品的卖点总结、产品的部署方式、产品体验等等多种培训角度。
　　一般来说，产品经理应该要在培训前依据受众人群进行针对性的产品培训准备，或者针对行业特性准备对应的行业宣贯培训资料。当然，不是每次迭代都需要这样，视情况而定。
　　这一块我的工作指南一般会按照以下几个内容来完成：
　　5.1 编写和更新发布材料
　　提前做好受众调研，将产品迭代的核心价值观点拟清楚，从产品发布到客户上线整个过程的使用角度，无论是商务角度，还是技术角度，都是要区分人群。
　　我自身的工作指南如下：
　　受众需求调研。占比10%。
　　确认培训对象，准备更新培训资料。占比35%。
　　对迭代功能做初步陈述。占比25%。
　　市场价值及运营指导。占比20%。
　　对培训资料的上报审核及审阅。占比5%。
　　行业培训准备（针对会议）。占比5%。
　　5.2 对内部人员进行产品培训
　　内部培训。针对市场前端人员，要更多强调此次迭代的商务优势和竞争优势。针对技术人员，要更多偏向此次迭代的技术原理、上线流程等方面。至于企业自身的属性，来充分定义。
　　我自身的工作指南如下：
　　组织全体培训。占比20%。
　　组织局部培训。占比25%。
　　组织多小团队培训。占比25%。
　　收集记录问题。占比10%。
　　反馈。占比15%。
　　5.3 对外部人员（客户）进行产品培训。
　　外部培训。依据客户现有需求点，以及定制化需求的要素进行给客户产品培训，包括新功能的使用、价值、应用方式、部署方式、以及维护方式等等。一般以收集客户意见进行培训为主。
　　我自身的工作指南如下：
　　面向客户准备培训材料。占比20%。
　　获取客户期望点，完善培训资料。占比20%。
　　收集反馈和问题。占比20%。
　　收集培训建议和问题。占比20%。
　　留给想象空间。（对客户的培训没有标准）20%。
　　5.4 对培训做总结
　　在经历一系列的内部培训和外部培训之后，产品经理要充分整理培训的反馈，及时更新及记录问题所在。这当中，会包含对产品的体验感觉、功能的差异变化、新功能的呈现方式、商业价值的市场定论、未来产品的思考、售后服务的优化等等诸多培训意见和想法。部分建议还会重新添加回到需求池，部分问题会直接加入到Backlog为下次迭代做准备。
　　我自身的工作指南如下：
　　收集多方评价。占比40%。
　　归纳和统一，并做回复。占比30%。
　　对改善项纪录和总结。占比30%。
　　6. 产品市场运营
　　在产品发布的伊始，产品经理是最懂产品的人，要想你的产品能在市场有很大的反响，就必须得充分配合前端市场人员完成定量的销售机会，建立标杆客户，促成产品推广模式，维护和有效做好运营维护。当然，这个是需要产品经理走出企业的圈子，不是坐在办公室做产品，而是深入到客户业务，这样才能有效的检验和验证功能对于市场的需求。
　　这一块我的工作指南一般会按照以下几个内容来完成：
　　6.1 促成销售机会
　　以客户经理挖掘出的销售机会为主，产品经理配合为次。现在，大多数企业还会有售前工程师的角色，这个过程就是三方联动（客户经理、售前工程师、产品经理），积极配合争取拿下客户签订合同。
　　这个过程跟每个公司销售的模式一样，就是要检验客户对此产品迭代的需求程度，对功能的满足程度。多数情况下，这也会涉及到收集客户对于该产品需求的未来期望值，以及充分了解到竞争对手在这个客户的实际产品使用情况。
　　我自身的工作指南如下：
　　关注重点销售机会。占比40%。
　　发觉潜在客户。占比20%。
　　分析竞品承担客户。占比40%。
　　6.2 建立标杆客户
　　标杆客户就是对于该产品使用各方面综合因素良好的客户，这个是检验产品成熟度的标志，也是考验产品经理能力的体现。举个例子，比如区块链的公链技术，在银行业能否建立一个核心的落地标杆，在政府行业能否建立一个核心的落地标杆。
　　我自身的工作指南如下：配合协作主导。占比100%。
　　6.3 促成产品推广
　　任何一个产品，但凡有好经验、好运营手段、好市场运作方式，产品经理都要整理成标杆产品推广案例。多数情况下，实际这个过程以实际市场运营人员主导为主，但产品经理也要配合宣贯，在后续的产品市场价值中强调产品落地实践。比如会议研讨宣贯、行业研究宣贯。
　　我自身的工作指南如下：
　　配合市场宣传和推广。占比60%。
　　会议、论坛、媒体等方式。占比40%。
　　6.4 处理产品投诉
　　这个世界上没有完美的产品，也没有完美的团队。产品在上线后遇到的问题、障碍，都要及时定位跟踪反馈结果，定期关注用户反馈才验证出产品在市场的充分反响。当然，如果你告诉我你的产品投诉率为0，很优秀，我不相信。
　　作为产品经理，要及时做好问题分析，关注重点客户问题。甚至于某些问题需要快速解决，有些问题需要放到下一步的迭代计划或Backlog继续迭代。
　　我自身的工作指南如下：
　　常见问题处理进度跟进。占比30%。
　　重点客户问题答疑。占比50%。
　　其他问题。占比20%。
　　6.5 定期完善更新
　　根据产品发布后的市场反馈，产品经理要多关注产品销售预期，关注产品的使用程度，关注行业反馈动态，关注运营手段更新等，一旦市场有变动及时做好应对策略（不包含销售定价策略）。比如行业分析不完善补充新的行业分析，竞争对手分析每个版本都要更新等等。
　　我自身的工作指南如下：
　　查看销售预期、反馈。占比70%。
　　更新竞争对手分析。占比20%。
　　找自身不足完善补充。占比10%。
　　7. 产品日常工作
　　我个人作为产品经理，有句比较信奉的话是这样说的，当你无法改变规则的时候，那你就只能遵守规则。这个不是局限于产品经理这个岗位，也包含其他岗位，都是一样的。
　　所以，当你在一家企业，日常工作该做什么还是得做什么。当然，如果你觉得这部分对你来说不占用时间，那么你可以不考虑。这部分在我的工作中总占比5%。
　　这一块我的工作指南一般会按照以下几个内容来完成：
　　7.1 公司制度
　　每个企业都有自己的公司制度，作为员工，无论是员工手册，还是企业文化，亦或是其他规章制度，更甚至是企业组织的活动培训等等，你都得去遵守它，而不是跳开它。
　　我自身的工作指南如下：
　　遵守考勤。占比50%。
　　遵守保密制度。占比20%。
　　遵守其他制度。占比20%。
　　留给企业空间。占比10%。
　　7.2 产品内部工作
　　对产品经理的管理者来说，会更希望自己能了解到每个产品经理的工作状态和内容，因为大家也需要发泄，也需要吐槽现有的工作环境，当然这更偏向于是产品总监/产品副总裁来主导的工作。作为产品经理，你也要契合自己产品部门的工作要求和内容。当然，你如果是产品总监/产品副总裁，那么我想，你关心的角度又会是另外一个维度。
　　我自身的工作指南如下：
　　产品周报（每周一篇）。占比10%。
　　产品例会（每周一次）。占比10%。
　　产品沟通会（提前约定）。占比30%。
　　产品汇报会（定期汇报，每月一次）。占比20%。
　　内部分享会（不定时）。占比5%。
　　辅导其他同事（新人）。占比10%。
　　协助其他事项。占比15%。
　　7.4 配合跨部门工作
　　在企业工作，产品经理这个岗位避免不了的是要跟跨部门的人员同事打交道，那么你对跨部门有需求，跨部门也会对你有需求，两者是相互配合协作的。比如人力资源部需要产品JD设立的要求，市场部需要产品的营销文案审阅，海外部新员工有单独培训新产品的答疑培训等等。
　　当然，我举这么多例子的目的就是要让你知道，你做产品经理，那么在公司跟你息息相关的，你要做的就是配合、遵守。
　　我自身的工作指南如下：
　　配合JD建立。占比10%。
　　配合市场营销。占比40%。
　　配合部门培训。占比15%。
　　配合海外市场拓展。占比20%。
　　其他不确定事宜。占比15%。
　　以上就是我个人在产品经理生涯中，抽出时间梳理的一些个人的实际工作指南，也算是现在对B端产品经理工作的一个解读。但由于每个企业都有自己特定的属性存在，我所列举的，所陈述的，都只能代表我个人对这个岗位工作指南的思考。
　　我最后只想说一句话，要成为一个优秀的Product Manage 不简单，那不是多看几遍人人都是产品经理就能理解的。
　　送给每一个想成为PM的人。